Add API for mods to interact with other mods' preloads #147
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.
TL;DR: This is the cleanest way to fix what is ostensibly a bug in Custom Knight.
The rationale for this PR is as follows. Custom Knight has a feature where objects not associated with the knight can get skinned - for example, a skin might want to replace all copies of a grub with a custom sprite.
For base game items, the way this works is that the skin author declares that hash
568482B2D16BF50AE18B394EC15B290048B75DCD
is associated with the grub skin, and then CustomKnight looks up in a precomputed lookup here which scenes/objects need to be skinned.Obviously this approach doesn't work if another mod has preloaded and instantiated grubs, because they won't be found in any of the listed scenes/paths.
The best approach we could come up with was for Custom Knight to add a component to preloaded objects to indicate where they originally came from, so for example if a mod preloaded a grub like this then the data could be added as a component on the preloaded object to indicate the source of the preload (or similar). This method is added as an alternative to CK having to IL-Hook internal MAPI methods in the mod constructor.
Note - the new API is added as a virtual method rather than an event because the event would have to be subscribed before mod.Initialize, which is not ideal.
ETA: This approach does feel a bit awkward and I'd be much happier with an approach that didn't involve adding a niche function to the mod class.