"On_load" causing the save to be out of sync and cant load.

[kasandraen]

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]

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]

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.

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.)

[kasandraen]

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.

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.

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.)

Hi!

This is the part of dytech-tree growth that causes the issue: https://docs.google.com/document/d/1TrX ... sp=sharing

and this is the same issue with Treefarm mod, which uses the same method to grow trees https://github.com/Blu3wolf/Treefarm-Lite/issues/60

The issue is that randomly while playing and everytime you change mods while playing, the CRC is out of cync and the save cant be loaded. Apparently its a hard nut to work around since bluewolf is working on it too with no solution yet.

I'm not a good mod dev so this is way beyond me so my current work around is to just comment out the entire tree growth part of dytech and disable treefarm mod and make alternative recipes without wood and rubber

[prg]

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.

[credomane]

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.

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

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.

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. This was the quick fix I did for Shuttle-Train.

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

[Rseding91]

"essentially nothing" and "nothing" are two completely different things

If the mod did nothing, the CRC check wouldn't fail.

[credomane]

Agreed. That is why I said "modified" in quotes.
What the mod sees it is identical. What Factorio sees is everything changed and that is a no-no.

[prg]

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

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

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.

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.

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.

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.

[credomane]

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

I get to thinking of doing things in event handlers only. I forget that I can register my GUI handlers in global scope and that on_load isn't needed even for that. Which is funny because I registered my on_load handler in the global scope. Just pretend I never said anything about event handler registration in on_load.

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.

Oh, I do. All my stuff is in on_configuration_change with mod name and version checking so that the global.<whatever> can be gracefully upgraded from even the oldest scheme to the current in one "pretty" go. I only use on_load for re-registering event handlers that I keep forgetting I don't need on_load for them at all. A lot of other mod devs use on_load like it is on_configuration_changed. Which tends to allow for just blindly shoving on_load contents directly into on_configuration_change in most cases. Yes, that is the lazy way but it works for a quick fix. The correct way is to setup global.<whatever> in on_init then if your mod's schema ever changes use on_configuration_changed to convert it to the new schema while the rest of the mod remains oblivious to the change.

[doktorstick]

I'm relatively new to modding and this forum (my first post, actually), but I've spent a bit of time experimenting. My statements below are from my observations and I fully welcome any course corrections where I'm off-base.

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.

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.

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.

Here's the rub though. The order of events is on_load before on_configuration_changed. Let's say for the sake of example you have the code:

Code: Select all

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

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

This will fail if your mod is being added since on_configuration_changed won't fire until after. This effectively means you cannot bind references a priori, even to skeletal trees (like the OP did). You end up having to setup your binds in a custom event handler (untested; not sure if it'll fire before on_tick) or do a check in on_tick (and in every tick) like:

Code: Select all

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

or what i ultimately settled on:

Code: Select all

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
)

Messy, but... effective?

Maybe the performance overhead is not worth the time of writing this post--I don't know; I'm not familiar enough with Lua nor Factorio's architecture. I will add though that I've seen references to locally binding functions if they are going to be used a lot in the function, which makes me think that binding to a deep reference in a tree is worthwhile.

[orzelek]

From what I remember messing with global in on_load event is not recommended (or not allowed currently even).
You'd need to do lazy loading in place you are using the data or use on_tick after loading.