Factorio Forums

Entity references stored in a mod's global table are sometimes (but deterministically) invalidated after save/load. I've attached an isolated test-case to demonstrate this:
Steps to reproduce:

1. Start a new game using the mod.
2. Move your cursor over an entity and run the command /save-selected
3. Run the command /print-saved. Both save-method 1 and save-method 2 will properly display the saved entity.
4. Save and load the game.
5. Re-run the /print-saved command. I expect the same output as before, but instead save-method 1 has its entity invalidated.

Other notes: Removing save-method 2 fixes save-method 1. Generally, fiddling around with adding/removing a save-method can affect other save-methods.

PS, thank you Chrisgbk for double-checking that my test-case is reproducible, and confirming that this looks like unexpected behavior.

Just to add on some extra information:

It appears that something goes wrong somewhere in the games save/load, and this results in global.save1 turning into a table that contains the entity instead of being a plain reference to the entity, ie:
meaning that prior to loading, accessing global.save1 works, but after loading, accessing global.save1[1] works and global.save1 doesn't - a very unexpected result.

Thanks for the report. I have no idea what's happening here that would produce these results.

I did manage to track down that it's being caused by your on_init call to store nil. Specifically this line of code causes some weird broken state inside Lua:
This does reinforce my opinion that you should *never* use tables as keys though

If this ends up being a bigger problem I might just enforce that in the version of Lua that Factorio uses.

From what I found while looking into this I almost thing it's a bug with Lua itself.

For now I'm going to move this to minor issues and say "don't use tables as keys". If this becomes a bigger problem I'll enforce that people don't use tables as keys (at least in the global table that's saved/loaded).