The size of every terrain chunk

[ssilk]

This doesn't make sense.
The binary format which comes out of serialized C++ code. That is - as Onyx already states - out of date with the next version.
The right way is to use json-config and write a mod (Lua program), which uses the API to generate the wanted state of the game.
Or change the game so that it uses documented formats.

[Zeblote]

The easiest way is probably to make a mod that does exactly that. Would be a lot easier if we had a proper file API, though: https://forums.factorio.com/forum/vie ... 10#p111945 (warning: topic is a mess up to that point)

Also, you won't be able to export everything. Entities on transport lines for example have zero lua access as far as I know.

[sillyfly]

This doesn't make sense.
The binary format which comes out of serialized C++ code. That is - as Onyx already states - out of date with the next version.
The right way is to use json-config and write a mod (Lua program), which uses the API to generate the wanted state of the game.
Or change the game so that it uses documented formats.

I think it was Oxyd Autocorrect trolled you?

Anyway, while the format may change, it will presumable become more stable as the game becomes more stable, and until that point - we'll have to keep adapting.
I believe there is no real alternative to direct access to the saved games file - having a lua interface inside the game engine will never be as flexible, I'm afraid.
Of course, the best option would have been to have a stable designed format (rather than a serialized memory format, which no one can really tell exactly how it looks), or else an API provided by the developers, but I understand this option will cost a lot of time and effort for the developers, so I see why they won't prioritize it.

Still, I believe we can make enough good effort to get what we need from the files, as long as the developers don't actively deter us (i.e. - ask us explicitly not to, or else explicitly obfuscating or encrypting the saved files).

[Oxyd]

This doesn't make sense.
The binary format which comes out of serialized C++ code. That is - as Onyx already states - out of date with the next version.
The right way is to use json-config and write a mod (Lua program), which uses the API to generate the wanted state of the game.
Or change the game so that it uses documented formats.

I think it was Oxyd Autocorrect trolled you?

Anyway, while the format may change, it will presumable become more stable as the game becomes more stable, and until that point - we'll have to keep adapting.
I believe there is no real alternative to direct access to the saved games file - having a lua interface inside the game engine will never be as flexible, I'm afraid.
Of course, the best option would have been to have a stable designed format (rather than a serialized memory format, which no one can really tell exactly how it looks), or else an API provided by the developers, but I understand this option will cost a lot of time and effort for the developers, so I see why they won't prioritize it.

Still, I believe we can make enough good effort to get what we need from the files, as long as the developers don't actively deter us (i.e. - ask us explicitly not to, or else explicitly obfuscating or encrypting the saved files).

The problem with a “stable designed format” is that it would change with every minor version as well. Remember: One of the requirements here is that if you save a game and load it back, your in-memory datastructures end up being in exactly the same state as they were before the save. This is especially important for multiplayer because when one peer send the map to another peer, after receiving and loading the map, both peers have to be in exactly the same state, otherwise it desyncs.

This means that the save has to contain pretty much every part of the game state, and as we add or remove variables from our data structures, the format has to reflect these changes. (Except for things that can be computed from other values that are already there, of course.) So the format wouldn't be very stable anyway.

Just serialising our objects and saving the result to a file is the easiest solution here, and it works rather well for us. And I'm pretty sure that making the format easy to mess with using external tools was never a requirement.

having a lua interface inside the game engine will never be as flexible, I'm afraid.
Of course, the best option would have been to have a stable designed format (rather than a serialized memory format, which no one can really tell exactly how it looks), or else an API provided by the developers, but I understand this option will cost a lot of time and effort for the developers, so I see why they won't prioritize it.

Extending the interface to allow access to more parts of the game state would be the saner option, I think. That's what we do, after all: We deserialise it into memory and then mess with the state there. But, like you said: Time.