The size of every terrain chunk

Enhance your gameplay with these tools. This category is also the right place for tools useful for modders.
Mod databases, calculators, cheatsheets, multiplayer, scripts, libs and other useful stuff that is not strictly in-game mods.
User avatar
ssilk
Global Moderator
Global Moderator
Posts: 12888
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: The size of every terrain chunk

Post by 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. ;)
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

Zeblote
Filter Inserter
Filter Inserter
Posts: 973
Joined: Fri Oct 31, 2014 11:55 am
Contact:

Re: The size of every terrain chunk

Post by 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
Smart Inserter
Smart Inserter
Posts: 1099
Joined: Sun May 04, 2014 11:29 am
Contact:

Re: The size of every terrain chunk

Post by sillyfly »

ssilk wrote: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 :P 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
Former Staff
Former Staff
Posts: 1428
Joined: Thu May 07, 2015 8:42 am
Contact:

Re: The size of every terrain chunk

Post by Oxyd »

sillyfly wrote:
ssilk wrote: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 :P 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.
sillyfly wrote: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. :)

Post Reply

Return to “Tools”