Factorio Forums

The motivation to do this is the possible mess that can be done when using these methods. The biggest problem is changing the game state in any way, as the game is rendered while the game is being saved and it also results into determinism problems sometimes.

Other solution would be to check and disallow any game changing method while this event is being invoked, but it would require a lot of extra ifs in the Factorio internals and the solution doesn't seem to be clean enough to me.

So the changes would be:

• on_load/on_save completely removed
• on_init would be called not only when the game is started but also when the mod was added to an existing game and the game.
• new event on_mod_configuration_changed would be called whenever the game was loaded and some of the existing mods is missing, some mod was removed or version of some was mod changed.
• There could also be added event something like my_version_changed. It would be called whenever version of the mod was changed (the user upgraded your mod, and you might need to migrate some structures), the event could even contain the previous version of your mod as parameter.

The question is: Is there any good reason why this couldn't be done?

So if this were implemented, any data that a mod needs to preserve would have to stay in the global table rather than being copied to local variables, I'm assuming.That's about the only thing I've ever used on_load/on_save for, personally.

the potential of events that don't allow game change (or only allow limited game changes) would create more thread and multiplayer friendliness for the modding API.

For example an event to populate a gui that only runs on the client that is showing the gui.

Or an event that modifies only a single entity would allow a parallelized update of multiple entities. This can then move to a more entity-based message-passing style of API instead of the "god script" style API is it is now.

Personally, these sound like good changes. I never used on_load or on_save, and the change to on_init sounds good (I was actually rather annoyed on_init did not work the way the proposed changes will make it work).

Extra new events are always welcome, so no complaints there.

I use on_load to update a global table containing fluid properties, which is used many times in my script. If on_init is called every time the savegame is reloaded, then removing on_load would not effect me negatively. It is not clear to me that the new on_init will function in this manner.

on_save should be removed but on_load is quite useful. One reason is that metatables are not serialised to disk so on_load can be used to re-create them. I'm not sure if there is a workaround for this if you remove on_load.

I personally have never seen a mod that needed to use on_save - that could be deleted right now from the game without a loss of functionality.

As for on_load:

The 4 legitimate uses that it has now:

• The ability to use populate local variable references to the global table to avoid indexing global in every event (the reverse is never needed since the local references will update the global ones runtime)
• The ability to re-populate meta tables (as James said they aren't persisted between save-load)
• The ability to update mod global data when prototypes are changed or the mod data structure is migrated due to changes in mod version when loading old saves)
• The ability to re-register conditional events (none of my mods always-tick - they tick when they have work to do and un-subscribe when they have no work to do - https://github.com/Rseding91/Plasma-Sho ... ol.lua#L19)

All of these would be satisfied perfectly if on_load was not called after the game was saved - that is to say - I have never seen a mod that needed on_load's functionality of "being run after saving" - every mod I've seen would be satisfied if on_load was replaced with on_init and was only called when the game was created or loaded.

Rseding91 wrote: All of these would be satisfied perfectly if on_load was not called after the game was saved - that is to say - I have never seen a mod that needed on_load's functionality of "being run after saving" - every mod I've seen would be satisfied if on_load was replaced with on_init and was only called when the game was created or loaded.

Yes, couldn't have said better myself.

kovarex wrote:The motivation to do this is the possible mess that can be done when using these methods. The biggest problem is changing the game state in any way, as
[*] on_init would be called not only when the game is started but also when the mod was added to an existing game and the game ???.

But hey, why wouldn't the on_init then cause desyncs the current onload does?
Also, it has been said already but it's still important: METATABLES

I very much agree that on_load does have some good use cases.
I use it to re-initialize some variables dependent on global... contents. I hope it stays in

SirRichie wrote:I very much agree that on_load does have some good use cases.
I use it to re-initialize some variables dependent on global... contents. I hope it stays in

What exactly do you mean? Because from the sounds of it - that's exactly what this is meant to stop.

All runtime data that a mod uses should be stored in the global table at all times if it needs to persist past the current execution's scope. Local references to the global table accomplish this while allowing the indexing to be skipped.

I think it would be more clear to say what the new on_init will do. As it is, I am not sure what it will do and whether I can adjust to it. My current use of on_load doesn't seem to be the sort of use that causes determinism issues.