Read scenario and merge with it before saving, that way adding compatibility for multiplayer shared scenarios

[Neouni]

Currently the trick in Dark Multiplayer is symlinking scenario files to share kethane data between players, but this would work more flawlessly if the mods actually read back the scenario data before saving so they append to it instead of just wiping it clean with their copy

[Majiir]

I don't see how this could be done. Kethane doesn't do any change-tracking, so it doesn't make any sense to "merge" different scenario states. Presumably the issue here is that if two multiplayer clients modify state (i.e. by scanning) then only one of the new states is preserved. My stance on this remains unchanged from when the KMP folks asked me about it: the multiplayer mod should provide a proper API. Merging scan states could work, but merging deposit states doesn't unless you're willing to accept overextraction of deposits. The whole thing breaks if any individual user uses the debug tools, although that's a fairly minor issue.

However, the fundamental problem I see here is that DMP is treating scenarios as deltas from one saved state to another, and that's not how the game models them. How should I treat deltas from a quicksave to a present time? There's no good way for the ScenarioModule to find a prior state from which to anchor a merge.

[Neouni]

Presumably the issue here is that if two multiplayer clients modify state (i.e. by scanning) then only one of the new states is preserved. That is true, but I have the impression that if kethane would read back what was in the file before writing to it, you wouldn't have the problem when player A and B are scanning a different planet, and player B writes to save last, only the results from player B would get saved. And player A loses all progress, and player B never saw players A progress unless he quit and joined the server.

There is offcourse also a plugin for dmp being developed, where other mods can piggyback on the server communication to the other players, but that requires a lot more code. https://github.com/godarklight/DMPPluginTest

Overextraction of deposits, it could happen with different subspaces etc just not from the same ship. Since you have "this vessel changed in the future", which basically disallows control till you sync up to the one further along. That's a tricky one unless you know more about the state of the players.