Call on_configuration_changed for new games

[danielbrauer]

I think the current lifecycle callbacks make the following case difficult to handle:

• There are two mods, Client and Service
• Service provides a remote interface
• Client optionally uses the interface during initialisation (and so declares an optional dependency on Service)

Right off the bat, it smells wrong that Client needs to check for Service in two places: on_init (for new games) and on_configuration_changed (if Service is added later). Even if Client does this, though, it opens up a possible ugly scenario:

• New game starts with Service, but not Client
• Client is introduced later in the game
• on_init is called for Client, which detects and calls Service's remote interface
• Now Service has code being called before its globals (or anything) are initialised

It is possible to handle this in most situations, but it seems very wrong that a mod author should have to consider their code being called before it has had a chance to initialise.

If factorio called on_configuration_changed after on_init for new games, it would remove the need to try and handle inter-mod communication in on_init. Instead, mod authors could use a single, safe callback for all initialisation that depends on other mods.

I realise that a proposal to change the lifecycle callbacks in any way at this point probably sets off all sorts of alarms, but would adding this extra call actually cause any problems? Because on_configuration_changed can be called at any point during a game, and mods need to handle arbitrary changes at this point, shouldn't it be quite safe to call it before the first frame?

[Rseding91]

I don't see this as happening. If you depend on another mod then you depend on it. If you don't, you don't. If you don't depend on the mod then you can't guarantee he or you are both ready for cross-mod communication because you have no idea who is loading in what order.

That's easily fixed by depending on the mod. Or if it's really optional then just skip it completely since it wasn't needed to begin with (being optional).

Adding more complication to try to solve these edge cases never works in the end. You just reach a tipping point of "well it's all broken, and complicated, and still doesn't work" and nothing is better.

[Honktown]

One can test for the existence of an interface: https://lua-api.factorio.com/latest/Lua ... interfaces . If a mod can silently handle the case where a remote interface is not ready, then the mod interface only needs to be used when it's available. Surely there's some cases where doing things on tick 1 instead of tick 0 wouldn't have the desired result, but would there be that many? (map chunks can be rewritten, characters can be moved, surfaces deleted...)

It's simple enough to do a one-time scheduled event: a function can unregister an nth-tick-handler that it itself is registered under.

What's the actual goal here? I've seen another thread (probably yours?) on this, and although the description is "dependency", using that is pretty empty statement. What's the urgency in doing it on the exact same tick as the interface is made?

As per on_init and on_configuration_changed, some of us use the same function for both Mostly for real reasons i.e. unless every change was tracked (and trackable in the first place) we want to do the same thing as on_init did. Only thing to keep in mind is to add the proper "but this thing already exists" or "may have values that are invalid now" code in whatever functions there are downstream.

[Optera]

As per on_init and on_configuration_changed, some of us use the same function for both Mostly for real reasons i.e. unless every change was tracked (and trackable in the first place) we want to do the same thing as on_init did. Only thing to keep in mind is to add the proper "but this thing already exists" or "may have values that are invalid now" code in whatever functions there are downstream.

This!
Even my most complex mods on_init and on_configuration_changed call the same functions to set up event and api handlers, initialize globals, etc

For most mods as long as you do things like global.my_table = global.my_table or {} it should be safe to call the same init function from on_init and on_configuration_changed.