Factorio Forums

[5] on_configuration_changed()

This step runs for all mods if the save's mod configuration has changed. The configuration is considered to be different when the major game version or any mod version changed, when any mod was added or removed, when a startup setting has changed, or when any prototypes have been added or removed.

During it, their LuaBootstrap::on_configuration_changed handler is called, allowing them to make changes or adjustments to their internal data structures. To that end, global can be accessed and modified at will. Mods also have full access to the game object, enabling any change to the game state that they deem appropriate.

Examples of when this event would fire when loading of a save file:
1. Game version has changed.
2. Save file format is different than current version.
3. List of active mods (name+version+crc) sorted by dependencies order is different.
4. Mod startup settings are different.
5. It is forced by a user (holding Control key while pressing the "Load" button in the Load game gui).
6. There were migrations applied to a save file since they were not yet applied to it.

Examples of when this event does NOT fire when loading a save file:
1. Client is joining a multiplayer server (client and server must already be in sync in all respects to join), and server has already run on_configuration_changed if necessary when loading the map when starting up.
2. Game is playing a replay.
3. Game has determined map was saved with an 'identical' configuration to the current game.

local function my_evil_func(event)
    script.on_event(defines.events.on_tick, nil)
    ...
end

...
script.on_event(defines.events.on_tick, my_evil_func)

[1] control.lua

During this step, each mod's control.lua file is loaded and executed in their own Lua state that will be owned by them for the remainder of the play session. It allows a mod to register for events using the script object, register remote interfaces with the remote object, or register custom commands with the commands object.

Access to the game and rendering objects is not available as the game state can not be manipulated at this point. While each mod has their own global table, it is not restored until the end of this step (if loading a save file). This means that global is still empty at this point and anything a mod adds to it during this step will be overwritten.

Since this step is run every time a save file is created or loaded, it is not necessary to restart the game for changes to the control.lua file to take effect. Restarting or reloading a save will re-run this stage and pick up any modifications to the code.

Cautionary Note:
In multiplayer games, execution of control.lua cannot happen at the same time for all users; it is run for each user upon joining the game. Despite this, registering event handlers in control.lua is *usually* safe from desyncs because most mods register event handlers consistently regardless of mod/game state. However, if a mod makes *conditional* event handler registrations, registering event handlers in control.lua will surely cause a desync (the newly-joined client's events will fire differently than the previous clients in the game).

In the case of conditional event registration, the mod should instead store the current event registration state in the global table at all times. Then, control.lua should register an on_load event handler, which will then inspect the current event state in the global table and set up the conditional event handlers as appropriate for the current game state.

Obviously, feel free to edit/discard to your desire. No offense will be taken if these suggestions are ignored

\data\core\prototypes\noise-programs.lua
\data\base\prototypes\entity\enemy-autoplace-utils.lua

...These can be modified to after surface generation,...

The count formula used for this infinite research. nil if this research isn't infinite.

The count formula, if this research was defined with one. Otherwise nil.