Factorio Forums

kasandraen wrote:Hi

Both the mod Treefarm, and the rubber tree growing part of dytech relies on this to work. Is there a way to work around it? Now I cant load my save anymore becouse the CRC is not what the mod expected.

bobingabout wrote:I'm not sure what I can tell you as an end user, but as a modder, the answer is simple... Don't use "on_load", ever, there is no need to.
Either use the on_configuration_changed system, or on_initialize (I think) to set things up. Since any data you want to keep should be stored in the global table, where it is saved with game saves, and loaded again on game load, the whole concept of on_load is obsolete.


The only time you should ever use on_load is to generate lookup tables and such that does not need to be saved.

bobingabout wrote:I'm not sure what I can tell you as an end user, but as a modder, the answer is simple... Don't use "on_load", ever, there is no need to.
Either use the on_configuration_changed system, or on_initialize (I think) to set things up. Since any data you want to keep should be stored in the global table, where it is saved with game saves, and loaded again on game load, the whole concept of on_load is obsolete.


The only time you should ever use on_load is to generate lookup tables and such that does not need to be saved.

prg wrote:

kasandraen wrote:Hi

Both the mod Treefarm, and the rubber tree growing part of dytech relies on this to work. Is there a way to work around it? Now I cant load my save anymore becouse the CRC is not what the mod expected.

You need to provide more information, like example code, steps to reproduce, logs, an explanation of why you think on_load is the problem...

Are you not able to load the save anymore at all, or are you just unable to join a multiplayer game? If the former, the mention of invalid CRC sounds like the ZIP archive got corrupted, which a mod really shouldn't be able to do. If the latter and the CRC refers to mismatching game state, complain to the mod author.

bobingabout wrote:I'm not sure what I can tell you as an end user, but as a modder, the answer is simple... Don't use "on_load", ever, there is no need to.
Either use the on_configuration_changed system, or on_initialize (I think) to set things up. Since any data you want to keep should be stored in the global table, where it is saved with game saves, and loaded again on game load, the whole concept of on_load is obsolete.


The only time you should ever use on_load is to generate lookup tables and such that does not need to be saved.

You need on_load to conditionally register the on_tick handler and re-set metatables (but I'm not sure how officially those are supported by now. They used to not be supported but they seem to be working fine.)

bobingabout wrote:I'm not sure what I can tell you as an end user, but as a modder, the answer is simple... Don't use "on_load", ever, there is no need to.

prg wrote:Ah yeah, global is getting modified in on_load. No idea why the author would feel this is necessary since its contents gets preserved across saves automatically. Don't touch global in on_load.

function on_load()
    --This already exists as a table from on_init and is unnecessary anyways.
    global.myTable = global.myTable or {}
end

credomane wrote:Don't event handlers still get lost? Making on_load still needed if you do any with the GUI.

credomane wrote:Lot of mods I see aren't really "modifying" the global table. This seems to be enough to trigger the global modified crc check even thought it did essentially nothing. The fix is generally to change the event from on_load to on_configuration_change (ignoring for what mod) to fix the issue.

credomane wrote:

Code: Select all

function on_load()
    --This already exists as a table from on_init and is unnecessary anyways.
    global.myTable = global.myTable or {}
end

prg wrote:If you want to register an event handler unconditionally, you can do that just fine in global scope.

prg wrote:You should change global in on_configuration_changed if that is required by a new version of your mod (or possibly another mod, if your mod cares about that), sure. Just reassigning stuff to global independently of what actually got changed shouldn't be necessary though. If you feel this is still required to fix things up it's a hint you're doing something wrong elsewhere already.

bobingabout wrote:I'm not sure what I can tell you as an end user, but as a modder, the answer is simple... Don't use "on_load", ever, there is no need to. Either use the on_configuration_changed system, or on_initialize (I think) to set things up. Since any data you want to keep should be stored in the global table, where it is saved with game saves, and loaded again on game load, the whole concept of on_load is obsolete.

The only time you should ever use on_load is to generate lookup tables and such that does not need to be saved.

prg wrote: Let's say you've already published MyMod-v1 that doesn't use global.myTable yet and you're currently writing MyMod-v2 that does.

credomane wrote:

Code: Select all

function on_load()
    --This already exists as a table from on_init and is unnecessary anyways.
    global.myTable = global.myTable or {}
end

Doing this in on_load is either a no-op or wrong. You'd just do global.myTable = {} in on_init for a new game or when the mod gets newly added to an existing game. In on_configuration_changed you'd check which version of your mod you're updating from and set global.myTable = {} if needed.

-- Reference to oft-used table
local deep = nil

script.on_load (function() deep = global.some.hierarchical.tree.structure end)

function on_tick(event)
    if deep is nil then deep = global.some.hierarchical.tree.structure end
    ...
end

script.on_load(
    function()
        if global and global.some and global.some.hierarchical and
            global.some.hierarchical.tree and global.some.hierarchical.tree.structure then
            deep = global.some.hierarchical.tree.structure
        end
    end
)