search

BattletechModders / ModTek

Mod system for HBS's PC game BattleTech.
GNU Lesser General Public License v2.1
121 stars 34 forks source link

Allow mod to get mod list #75

Closed Sheep-y closed 5 years ago

Sheep-y commented 6 years ago

I have a mod that is doing lots of little things, some simpler than others and some more flexible than others.

Example: my mod can tune roll correction strength, and by default half its correction. It is flexible but conflicts with a mod that specifically disables roll correction.

So what I would like to do is if I can get a list of mods, when it is my turn to load, I can selectively disable features if I see a known mod. I can actually skip patching those methods.

Maybe a base mod class can be created for mods to extends from, who can then use methods to talk to MotTek? Existing mods does not need to be modified, and new methods can be added in future without breaking mods.

CptMoore commented 6 years ago

An "optional dependsOn" that would allow a mod to be loaded after another mod but if it doesnt exists still loads the mod with the optional dependency.

Alternatively a second callback method thats called after the loadorder has been executed, and everything is loaded up.

Sheep-y commented 6 years ago

I don't mind the load orders. It sometimes helps, but not always a good solution. Harmony priority seems to give finer control anyway.

If I know whether some specific mods would be loaded too on Init, my mod can change its settings and behaviour.

I haven't tried yet, but the alternative seems to be to defer my patching and then use reflection or harmony to test those mods. Doable, and I already defer some non-patch code so I am half way there, but if we have that list then I don't need to defer or reflect.

mpstark commented 5 years ago

Is this something that we still would want? We could change modLoadOrder accessibility to public, but mods that used this would have to have a reference to ModTek, which I personally don't think is a great idea.

CptMoore commented 5 years ago

I think with optional dependencies, the issue here is resolved.

Whats left is now not any issues with mod to ModTek communication, but mod to mod communication.

If mod A specifies an optional dependency B, it will be loaded after B, and A can now manipulate B (checking if a dll was loaded should be simple). For that B has to be manipulable.