ModuleManager: patch in ModuleUPFMEvents during LAST pass instead of AFTER.
#94
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… of `AFTER`. Some mods modify existing nodes/modules in parts, others replace them; sometimes this happens in a chained manner. Not all parts fail the same way, too, so OhCrap adds different `*FailureModule`s across many files, often with rules on ordering, depending on which compatible mod is addressed. In the touched ModuleManager patch, all parts that already have a `*FailureModule` also get a `ModuleUPFMEvents`. Before this commit, RemoteTech antennas would get a `RTAntennaFailureModule` after the `ModuleUPFMEvents` patch has already run (and you don't get a second pass). This was because RemoteTech parts would only get their `*FailureModule` after getting a `ModuleRTAntenna`, different from antennas untouched by RT, which get a `*FailureModule` based on having a `ModuleDataTransmitter`, itself different from a custom `ModuleRTDataTransmitter`... After this commit, parts having a `*FailureModule` are guaranteed to have a `ModuleUPFMEvents`. We do get a second pass! This commit may also activate warranty and immediately expire it on all parts that were supposed to fail long ago, but were unable to communicate their intent to OhScrap. More on ModuleManager patch ordering: https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering
|
Testing - no display issues so far, no NREs...
|
zer0Kerbal
added
bug 🐛
zer0Kerbal
added
the
hacktoberfest-accepted
|
No new bugs or new NREs on "live" save so far.
(Pic: One new booster in tandem with four old ones.) IMO worth mentioning on next release that some parts that "never used to fail" now "perform as advertised". |
just plain deviously worded😂. I will mention that. 😁 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #46 as fixed.
Closes #91 as duplicate (might have comments that are different issues?..).
Some mods modify existing nodes/modules in parts, others replace them; sometimes this happens in a chained manner.
Not all parts fail the same way, too, so OhScrap adds different
*FailureModules across many files, often with rules on ordering, depending on which compatible mod is addressed.In the touched ModuleManager patch, all parts that already have a
*FailureModulealso get aModuleUPFMEvents.Before this commit, RemoteTech antennas would get a
RTAntennaFailureModuleafter theModuleUPFMEventspatch has already run (and you don't get a second pass). This was because RemoteTech parts would only get their*FailureModuleafter getting aModuleRTAntenna, different from antennas untouched by RT, which get a*FailureModulebased on having aModuleDataTransmitter, itself different from a customModuleRTDataTransmitter...After this commit, parts having a
*FailureModuleare guaranteed to have aModuleUPFMEvents. We do get a second pass!This commit may also activate warranty and immediately expire it on all parts that were supposed to fail long ago, but were unable to communicate their intent to OhScrap.
More on ModuleManager patch ordering:
https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering