As nobody posted in this thread I'm re-purposing it, it turns out using table.deepcopy() on a table containing entity's causes the game to corrupt. I was able to get around the problem by writing my own table copy function that doesn't change meta tables. Using table.deepcopy() on entity's causes the game to crash.
OldStuff
For the past 2 days I've been trying to debug a problem with one of my mods, however it appears I'm causing the entities I'm trying to remember to become corrupt.
This may be something caused by util.table.deepcopy(), as the deepcopy function changes metatables. The effect of "corrupt" entities seem to be crashes when their data is accessed and crashes when you try to end the current game session. (Hitting end game or Loading another save.)
The Entity tables never become nil, and are still accessible with lua:
Load the Included Save file.
Place some Force field posts so they generate a field.
Open the Table data browser/debugger tool using the command below.
Take Note of the data structures of the tables, "MLAEnts","MLALoops" (Click the buttons named after the table to open it.)
Close the Table browser with the command below.
Save your game then reload that save. Then Reopen the Table browser.
See that the data structures are saved and reconstructed 100% correctly.
The Gui Debugger is opened and closed through the game console.
remote.call("MoDebug","OpenGui") --Opens the Gui
remote.call("MoDebug","CloseGui") --Closes the Gui
Download Mod Here: I Fixed it now, Ill release soon.
Thanks for the report. The problem here is that the "factorio" lua objects (i.e. lua entity, lua technology) need to correspond to the C++ object in the backend. Factorio lua objects cannot be "raw-copied" (table copy of attributes). So the result of using deepcopy was there were two distinct tables that corresponded to one instance in the backend. When the original table (the one we copied from) is garbage collected (GC is explicitly triggered every 300ticks or so) then the object is deleted and the copy becomes invalid (it tries to call functions on deleted C++ object).
For 0.9.5 I have changed the definition of deepcopy as follows:
if type(object) ~= "table" then
return object
-- presence of __self parameter means this is a factorio object
elseif object.__self then
return object
elseif ...
This way the factorio objects will be treated as references within the deepcopy. This actually makes better sense because the entity in the game "cannot be copies", you can only make 2 distinct references.