Competing background simulations that share resources are fundamentally incompatible

[ShotgunNinja]

Note: This example use TAC, but any other mod that simulate resources on unloaded vessels in some way will trigger the same behaviour.

On unloaded vessels, the Kerbalism simulation will proceed as usual. Meanwhile the post-facto TAC simulation will proceed too, independently. If the two simulations don't share resources (meaning, all resources are simulated either by Kerbalism, or TAC, but not both) nor the related production chains share any resource, then there is no issue. If, instead, there are shared resources (let's say, Water) then these resource levels, and the levels of all resources linked in production chains and the like, will be fundamentally wrong on both simulations. The consequences may range from subtle to catastrophic for the poor Kerbals.

[PiezPiedPy]

Is there a way for two mods to pass information to each other? I have not coded with unity/KSP or C# but have extensive knowledge of coding the firmware and software for communication device protocols using C++, MS Net framework managed code and Asm. I'm thinking a couple flags, a timestamp etc. passed between mods should be sufficient but I have no idea if a KSP plugin dll can see another mods plugin dll namespace->global/public methods or variables.

[gotmachine]

I think this isn't really an issue but as you said, it is a fundamental problem that has no solution. When two plugin are providing the same features, they can't work well together. You are already providing a background resource simulation for stock modules and some modded ones and provide a complete resource chain with the default profile.

I think the only viable solution is to add a switch for every supported module in the profile to enable/disable its background processing. Then provide a profile where background processing is disabled for stock/modded modules (beside solar panels and the basic converter used for RTG) and with only the features that doesn't need any resources (beside EC) : science, signal, radiation, reliability. This profile would be the default one for people who want to use another life-support plugin, like snacks, TAC, USI-LS, or plugins that implement their own resource chain like MKS.

The other option is too much work. I don't know if it is really doable, but maybe the default profile could disable identified competing assemblies, I'm thinking about TAC-LS mainly but this could be done for others. Then MM patch their part if needed with equivalent Kerbalism modules/resources. I think most people that want to use TAC-LS are doing so for the parts. But this would probably lead to a MM nightmare for parts mods like KPBS since both plugins would be detected in NEEDS section, and represent a colossal work and care.

[ShotgunNinja]

@PiezPiedPy It is definitively possible, and already happening between many mods. To give you an example, this mod has a public API (albeit minimal), use some public APIs of other mods, and make widespread use of dirty reflection hacks to emulate stock and third-party modules for unloaded vessels.

However that is not going to help in this case. @gotmachine is right, this is a fundamental issue. A solution could be done for TAC (however elaborate and messy its implementation would be), but then you will have the same issue with all other mods, present and future, that try to do some background simulation of resources.

Worth noting that TAC can be fully emulated by the rule framework included in this mod.

[ShotgunNinja]

I think the only viable solution is to add a switch for every supported module in the profile to enable/disable its background processing. Then provide a profile where background processing is disabled for stock/modded modules (beside solar panels and the basic converter used for RTG) and with only the features that doesn't need any resources (beside EC) : science, signal, radiation, reliability. This profile would be the default one for people who want to use another life-support plugin, like snacks, TAC, USI-LS, or plugins that implement their own resource chain like MKS.

This idea is interesting, and could work to some extent, given that virtually all mods that have background resource simulation of some sort ignore EC consumption (because they don't simulate EC production either). But, not knowing the details of what a third-party mod is doing with EC, the issue remain even with this solution.

Dropping EC simulation too would definitely solve it: in that case essentially this mod disable its own background resource simulation, and so there is no competition.