Fire on_configuration_changed when a save's lua scripts are modified

[Hornwitser]

Clusterio is moving over to using save patching in order to put code into the game. This means adding lua scripts to the save zip file and rewriting control.lua to load those scripts. Unfortunately because this can happen to an already existing save game the patched code cannot rely on the on_init event to setup it's variables. It also cannot rely on on_configuration_changed as this event is not triggered when only the lua code of a save is modified.

I haven't been able to think of a multiplayer safe way to emulate the on_configuration_changed event that works with the event_handler lib and also doesn't have the possibility of having other events fired before it. So it would be nice if the on_configuration_changed event is fired when the lua code in the save is modified.

Interesting side note: if you patch a save that was previously a scenario that doesn't load the silo-script into one that does, like the freeplay scenario and you add an item to the tracked items list, launch said item with a rocked and you log out and log in of the server the game will desync when logging in because the silo-script never stored its script_data into the global table.

[Bilka]

I'd recommend to just put the scenario into a mod, and update the script in the save by calling reload script in a migration script while also increasing the mod version, afaik that should raise on config changed.

[Hornwitser]

So what you're saying is that we should drop support for running non-modded Clusterio games entirely? We kind of want to be more flexible than that. Also we don't have one "scenario" that can be put into a mod, Clusterio uses a plugin based system for selecting which features use in the cluster, for example there's a statistics exporter plugin that adds code exporting the production/fluid/pollution/kill statistics of the game, and these plugins can be independently updated for different clusters. It sounds like this approach would force every cluster to upload its own version of this mod.

[Bilka]

So what you're saying is that we should drop support for running non-modded Clusterio games entirely?

Huh? What does updating a save file have to do with hosting servers? To update the save file you have to take down the server anyway, so you can as well do that update with a mod instead of modifying the code directly in the save.

I think you didn't understand what I meant: Currently it sounds like you take the code and copy paste it into the save file. I propose that instead of copypasting it into the save file, copy paste it into a mod, increase the mod version, add migration file to reload script, enable mod, load save file, save the file, disable mod, host server again. All of that should be possible to automate via script. You don't need to distribute that mod, or use it between clusters or anything like that, just how you don't share save files. Disclaimer: I did not check if on config changed is called, but my intuition says yes.

In fact, thinking about this further, having a mod forces the on config changed call just by existing, so you might as well do your current process with a "load save with empty mod" in-between that forces a config changed call.

[Hornwitser]

That was not at all logical from what you first said but okay. The documentation for script_reload says "Forces a reload of the scenario script from the original scenario location." how do I know what the original scenario location of an arbitrary save is? And what happens if this is a freeplay scenario and the original location is base/scenarios/freeplay?

Edit: adding/changing a mod to the game makes on_configuration_change be called in the level script. So that might be a viable workaround. But still annoying.

[Bilka]

how do I know what the original scenario location of an arbitrary save is?

It's saved in the file:

And what happens if this is a freeplay scenario and the original location is base/scenarios/freeplay?

Then the code should never change, because it's freeplay. If it does change, then you modified game files instead of making your own scenario and screwed yourself over in the process.

Edit: adding/changing a mod to the game makes on_configuration_change be called in the level script. So that might be a viable workaround.

Indeed, as per my last post.

[Hornwitser]

This feels to me to be worse than not using on_configuration_changed/on_init at all.

Edit: This also doubles the start up time. Which when running large mod-packs is no fun at all.

[Hornwitser]

An alternative to this proposal would be having an on_start event that is triggered when the server (or single player game) is started, and happens after on_load/on_init/on_configuraiton_changed but before any other event. My patched in scenario code could then use that event to initialize variables. I suppose another silly use case for it would be to show a timer that shows time since the game was loaded.

Another option would be a --yes-i-know-what-i-am-doing flag that allows modifications to the global table and game state in the on_load event during server startup.