Closed PlutoyDev closed 8 months ago
Thanks for the update. Since you opened as draft PR, is this finished from your side? Will look over it soon then.
It's not fully completed yet.
I had just finished analyzing and parsing the data in my project. Will be adding on to the docs later today/tomorrow.
Added Map Property structures and fixed formatting.
Although I use English day to day, it ain't very good, there are definitely a few broken English in my edited part, please help me fixed it, Thanks
While I've successfully read my save file. Its without a doubt the full save. The sample file was from weeks ago where my progression should be around oil processing. I didn't have time to feed in the new save until next weekend, so this is all I've got.
In case you need it, here is my code for reading the save file.
https://github.com/PlutoyDev/satisfactory-save/blob/main/src%2FparseSave.ts
Some info for reading.
getTypeParser
is a function that returns function. The returns can then be use with the "call" method to reference "this" ie SatisfactoryFileParser class.
readProperty, readPeoperties can recursively call each other. For evaluting Array/Set/Map of Structs.
Inside the repo, it also contains a outputs/main folder. This folder contains very big JSON file that will break any reader JSON tokenization, view with a simple text viewer like less or notepad is recommended.
I pushed some changes and fixes for the docs.
Here are some things I changed:
int64 "size of TOC data" / "world object data size"
This is duplicated. That value is already used as size by the TArray containing the blob data. Within the blob buffers there is no additional size.
Version should be the same as header SaveVersion
Is probably wrong, at least in future. As far is I know this used for versioning objects independent from the version used for the whole save. So currently it is the same number as this feature was just implemented in the latest save version, but in future this may fall behind. I don't know this for sure, but I think this may be used, because the level split of the objects allows to not serialize the whole save at once anymore. I.e. when you do not visit a certain map region in the game and save with a new version of the game, the not loaded objects just keep as is until you load that part by visiting that place in the world.
Sometimes there might be additional 4 bytes of zeros after the last property.
This is always the case and a bool HasGuid.
I did some larger restructuring in the property part. There were still some details missing, so I tried to rewrite with everything I know about the structure.
Nevertheless, I also found enough errors and outdated things from me, which should hopefully be fixed now. 😃
Please feel free to check and comment if you still find unclear things or errors, otherwise from my side it would be ready to merge now.
Looks good, I couldn't have done it better. Thank you
Thanks for the updates.
The documentation that you have provided are tremendously helpful for getting me started in understanding the structure of Satisfactory Save file.
I'm personally working on a save file parser in the browser using JavaScript. I have managed to work out some of the parsing myself through guess and checks and now I'm contributing back :).