[0.17.41] lua on_force_created event handler is not called on game.create_force()

[Bilka]

I thought i got it, but your new description makes things even more unclear. You say first_mod creates force_x in on_init. Then second_mod on init runs and the force_x is not there (during init). Do I understand correctly?

[mk-fg]

You say first_mod creates force_x in on_init.

Note that "first_mod" does not imply any kind of on_init run ordering here, and as you also pointed out, it's not a good idea to rely on any kind of ordering there when mods can be added/removed at random times.
I only meant "first" in a sense of "one out of two".
Neither of the mods are designed to care when their on_init runs relative to other mods.
(afaik, as again, I'm not the author nor maintainer of one of them, just going by the code there)

With that potential language trap out of the way, first_mod indeed creates force_x in its on_init.

Then second_mod on init runs and the force_x is not there (during init). Do I understand correctly?

Yes, you are correct in both cases.

Note that second_mod's on_init can (and actually does) run before first_mod's on_init.

[mk-fg]

Just to anticipate further line of thinking, as it was mentioned in viewtopic.php?f=25&t=70952#p430659 :

If you put print() in:

- first_mod and second_mod's on_init functions.
- right before game.create_force() in first_mod (only first_mod does that).
- into second_mod's on_force_created event handler (only second_mod has that).
- into second_mod's on_nth_tick event handler.

Here's what these print's will output:

- second_mod.on_init
- second_mod.on_init_done
- first_mod.on_init
- first_mod.create_force
- first_mod.on_init_done
- second_mod.nth_tick

With end result of second_mod being unaware of newly-created force, despite on_init check/enumeration + on_force_created handler used there.

[Bilka]

That sounds like a bug to me, but I'm not the person who wrote this code, so I will forward this description (which I typed up as you made your second reply):

mod-abc runs on init. then mod-xyz runs on init and creates force. mod-abc does not get create force event.

[mk-fg]

I think it's just a documentation bug though, as 0.16.21 changelog ( viewtopic.php?f=3&t=57372 ) says this in no uncertain terms:
"Changed events so they won't fire until every mod has had on_init ran."

So expectation that *any* event handlers will run during *any* on_init is simply incorrect, it will not happen by design since 0.16.21.
Guess maybe that design decision can be reverted to make event handling a bit more intuitive and not need to amend all docs to say "this only works outside on_init phase!!!!", but I'm of course happy either way, as long as it's clear how things work

[eradicator]

I made two trivial test mods:

test2_0.0.1.zip

(1.14 KiB) Downloaded 78 times

test1_0.0.1.zip

(1.13 KiB) Downloaded 95 times

Code: Select all

script.on_init(function()
  print('T1 creating force')
  game.create_force('Test Force 1')
  end)
  
script.on_configuration_changed(function()
  print('T1 config changed')
  end)
  
script.on_event(defines.events.on_force_created,function(e)
  print('T1 recieved on_force_created:',e.force.name)
  end)

They seem to confirm the behavior described in the changelog. ANY event triggerd during ANY mods on_init WILL NEVER be recieved by ANYONE. It doesn't matter if one of the mods was already in the savegame before. This has serious implications for my mods too *sigh*. The only workaround i see is re-looping through *everything* *again* during on_config... and hardening *all* on_something_created handlers to not break anything if they get called on something that actually wasn't created but already existed.

[eduran]

on_configuration_changed is not triggered when you start a new game, only when you load an existing save and something changed. I don't see a good way to deal with this situation in a new game

[orzelek]

on_configuration_changed is not triggered when you start a new game, only when you load an existing save and something changed. I don't see a good way to deal with this situation in a new game

Thats why I ended up doing full set of checks in both on_init and on_configuration_changed.
This seems to work properly for now.

[mk-fg]

on_configuration_changed is not triggered when you start a new game, only when you load an existing save and something changed. I don't see a good way to deal with this situation in a new game

Thats why I ended up doing full set of checks in both on_init and on_configuration_changed.
This seems to work properly for now.

I don't understand "Thats why" there, as eduran seem to be pointing out why this approach won't work - on_configuration_changed event will not be fired after on_init when first initializing your mod alongside others, and any handlers will miss events, just like pointed out in example here - viewtopic.php?f=25&t=70952&e=1&view=unread#p430718

[Rseding91]

I fixed this so it will fire event handlers when a brand new game is being created but I can't make it work in the "mod added to existing save" scenario. The problem is: on_load has not been called by the time on_init is being run for the newly added mods. So, calling event handlers for a mod before on_load has even run is just asking for things to break.

And i can't move the processing of the added mods on_init around between calling on_load for other mods due to migration scripts running after on_init but before on_load.

[mk-fg]

Is it not possible to put all events generated by all on_init in all mods into some list and then once all mods are initialized and loaded, call all handlers for each of them?
From the standpoint of any individual mod, I'd think such delay will make no difference, as none of its other code can run during it anyway.

[eradicator]

I fixed this so it will fire event handlers when a brand new game is being created

Can you describe this fix in more detail please?

[orzelek]

on_configuration_changed is not triggered when you start a new game, only when you load an existing save and something changed. I don't see a good way to deal with this situation in a new game

Thats why I ended up doing full set of checks in both on_init and on_configuration_changed.
This seems to work properly for now.

I don't understand "Thats why" there, as eduran seem to be pointing out why this approach won't work - on_configuration_changed event will not be fired after on_init when first initializing your mod alongside others, and any handlers will miss events, just like pointed out in example here - viewtopic.php?f=25&t=70952&e=1&view=unread#p430718

I might be misunderstanding something. Not sure how the fix will affect that but my understanding is (I'm using surfaces not forces in here since it's in RSO):
1. When mod is added to the save on_init will run - it can enumarate surfaces and should see all the surfaces created in the game until now.
2. When another mod is added to the save on_configuration_changed will run - when it enumerates surfaces any surface added by new mod in on_init should be visible for me.
3. Then I still keep the on_sruface_created handler that will trigger if any of mods will add surface in runtime (outside of on_init)

[eduran]

I might be misunderstanding something. Not sure how the fix will affect that but my understanding is (I'm using surfaces not forces in here since it's in RSO):
1. When mod is added to the save on_init will run - it can enumarate surfaces and should see all the surfaces created in the game until now.

That was the issue: by enumerating you see the surfaces created by mods loading before your mod, but not the ones created by mods after your mod. And since no events are raised during on_init you would not know about them. Checking again in on_configuration_changed works only if the mods in question are added to an existing save. If all relevant mods are already present when creating a new game (i.e. no on_configuration_changed), there was no way to deal with this issues. That last part was my point.

And it is exactly the case Rseding fixed by raising events during the initial on_init. You still have to deal with mods added later in on_configuration_changed and you still have to enumerate during on_init (because your mod might be added to an existing game).

[mk-fg]

...
If all relevant mods are already present when creating a new game (i.e. no on_configuration_changed), there was no way to deal with this issues. That last part was my point.

And it is exactly the case Rseding fixed by raising events during the initial on_init. You still have to deal with mods added later in on_configuration_changed and you still have to enumerate during on_init (because your mod might be added to an existing game).

Note that if I understand correctly, same problem will still occur when multiple mods will be added to a saved game, even after the fix, as it doesn't affect events in that case.
Multiple on_init's will run for these mods added at the same time, and ones that get initialized earlier will neither get any events from on_init in later mods, nor get on_configuration_changed events to re-init.

[eduran]

Note that if I understand correctly, same problem will still occur when multiple mods will be added to a saved game, even after the fix, as it doesn't affect events in that case.
Multiple on_init's will run for these mods added at the same time, and ones that get initialized earlier will neither get any events from on_init in later mods, nor get on_configuration_changed events to re-init.

If a mod is added to an existing save file, both on_init and on_configuration_changed run for this mod. Already present mods don't run on_init, but only on_configuration_changed. on_configuration_changed is only omitted when creating a new game, because there is no pre-existing configuration that changed.

[mk-fg]

If a mod is added to an existing save file, both on_init and on_configuration_changed run for this mod. Already present mods don't run on_init, but only on_configuration_changed. on_configuration_changed is only omitted when creating a new game, because there is no pre-existing configuration that changed.

Oh, guess I was wrong then, thanks for clarifying.
That's great and indeed seem to fix the issue.