Tangled craft in save, Stored Parts etc #1
-
I have a craft in a savefile that has issues so downloaded sfsutils to investigate further. I'm finding some strange parent and attach references and am wondering if the new-ish stored parts in KSP1 are processed sanely in sfsutils, or maybe there are some wrinkles to how the part array is handled in ksp that is eluding me. Example of what I'm seeing is parts, other than root, that are their own parent going by the index into the array as the part reference. Also sym references off by 1 (indicating parts that aren't in the group. I'm thinking in zero based indexing of the part array as being the sfs part reference and that seems to sync with nearly the data but the odd stuff. But there are "stored parts" in inventory that don't show in the sfs array and am wondering if they may be accounted for when KSP writes the file but not when sfsutils parses it. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
Basically all sfsutils does is take the SFS file and naively parse it into plain dictionaries/lists (equivalent with JSON). It doesn't do any special processing or interpretation with any of the fields in the file, so the way arrays are indexed may well differ. If the library is working properly, the loading an SFS file and then saving it to disk should give you the exact same file back, if it's not doing that then there's a bug here Provided the above works, there could also be an issue with the file not being parsed sensibly. If it malformed according to my assumption of the SFS spec, parsing may crash (which you're not seeing) or be partial and/or nonsensical (this is also a bug) Could you try the file consistency test and report back? If that works, then the data you are looking for is definitely somewhere in the object returned by the parsing function |
Beta Was this translation helpful? Give feedback.
Basically all sfsutils does is take the SFS file and naively parse it into plain dictionaries/lists (equivalent with JSON). It doesn't do any special processing or interpretation with any of the fields in the file, so the way arrays are indexed may well differ.
If the library is working properly, the loading an SFS file and then saving it to disk should give you the exact same file back, if it's not doing that then there's a bug here
Provided the above works, there could also be an issue with the file not being parsed sensibly. If it malformed according to my assumption of the SFS spec, parsing may crash (which you're not seeing) or be partial and/or nonsensical (this is also a bug)
Could…