Saving data about trains about factorio-stdlib HOT 5 CLOSED

Great analysis. I know a bit more about the inner workings of factorio serialization, so I'll clarify where I can.

This appears to be fine when handling LuaEntity references; I guess this is because the game can properly (de)serialize those and always returns the same references from global data and surface queries. but I don't know for sure.

Yes, this is exactly how it works. If you save a reference to a LuaEntity, and then compare the saved reference in a loaded-save against a newly retrieved reference (say from surface.find_filtered_entities), and the entities are the same, the references will also be same. There is definitely back-end logic keeping these all in sync in Factorio. It is safe to assume references will never change.

However, the Trains.to_entity method above always returns a new table, so the references will never match.

Yep. Fuax-references won't work unless we also persisted them, which would be a lot of overhead. Also persisting faux-references would leak memory as we could never tell when to deference and free the memory, as there is no way to tell when a train when it was 'dead' or not. I agree this is not the best approach.

To that end, I would propose making a slight change to the Entity module to have it call an equals method on the input entity if there is such a method and the entity references don't match.

Makes sense to me. All your proposed code & changes look good. I would make on additional suggestion, on top of what you already have, to provide helper-methods to cut down on the verbosity a bit:

function Trains.set_data(train, data)
  return Entity.set_data(Trains.to_entity(train), data)
end

function Trains.get_data(train)
  return Entity.get_data(Trains.to_entity(train))
end

Look forward to reading your PR.

from factorio-stdlib.

Hi Afforess,

This isn't forgotten. Unfortunately. work stuff has come up, and reduced the time and effort I can put in to this.

from factorio-stdlib.

As far as I am concerned, this is covered and completed by #50, @AndyBursh if you disagree, feel free to let me know.

from factorio-stdlib.

I'm 50/50 on it being complete. I haven't yet implemented, or put any thought in to, handling train id changing events within the module. The idea there would be to perform the book keeping necessary to make sure data is always associated with the lead engine. That said, I'm not even convinced that's a job for a library and not an application-specific behaviour

from factorio-stdlib.

@Afforess Would you rather discuss this in a separate issue, or reopen this one?

from factorio-stdlib.