Microsoft Store Save Compatibility #3
Comments
|
As I said on Twitter I am taking a hiatus from working on Bug Fables things, but I actually can at least point people in the right direction should they choose to make a pr to support it (since I will be able to review PRs). The file begines with 04 00 00 00 D7 01. Following that is the content of config.dat which is always 43 lines. After that, you have an 8C and then following that, the 18 lines of the save (I assume it's save0.dat, I wouldn't be surprised if save1.dat was following that and then save2.dat with the 8C separator). This can be a challenge to support: the save editor doesn't support editing config.dat (it could be argued it's in the scope of the project to do that though) and when you write the file, the save part is a partial part of the file. What this means is unlike on pc where you write the whole file with XOR encryption, here, you have to write a part of the file with NO ENCRYPTION. Maybe we should consider adding support for config.dat because it's part of the persistent storage of the game. I unfortunately haven't researched what line is which though, but you can figure this out by checking the game's code. If you were to add support, then you could offer the option to CREATE a new microsoft store save format because currently, you can't: config.dat isn't supported, you would only be able to EDIT an existing one. For the record, the switch save format also operates with different files, it's just that they aren't encrypted and they have a different header, but the rest are the same. So yeah, that's all one would need to know to add support to this. |
|
As Bug Fables was removed from gamepass, this feature is not as needed. However, I will not close this issue because there have been some cases where people still wants to load up their save file from gamepass and convert it to standard pc save. The procedure to do it is a little weird, but it is possible for me to come up with something. FYI, the first starts with some sort of binary header, followed by config.dat followed by some kind of separator followed by save0.dat in the standard format as outlined here: https://github.com/aldelaro5/Bug-Fables-Internal-Docs/blob/master/Data%20format/Save%20File%20Format.md . The only difference is that the file isn't XORed like it is on standard pc. It is possible to manually convert the file which is what I have been doing by copying the piece of it that is the save file. You can need to load the save without XORing which the editor doesn't support currently and it will parse all well. I need to do some renovation work on this project, having the ability to load without XORing is going to be a thing before the full conversion feature. |
|
Update on this: implementing reading from this format is easy and will be done. Exporting to it however is very complex and may not be possible because of the complexity involved. It is DEFINITELY not possible to create a blank one, but the question of whether modifying an existing one is possible remains. It's the last feature I want before the next big release so I will look into it, but the reality is this version is by far the worst version of the game (it has known major issues) and its save format is probably the worst because it's so encoded upon layers of weirdness. Even the switch format is really easy to deal with: it just uses BinaryReader/BinaryWriter encoding, but the xbox pc one is not just the blob (the file you can read the file from), it also involves a container which has an outer structure too and these structures have moving parts that aren't as well documented. Basically, expect reading from, don't get your hopes up for writing to and definitely do not expect creating blank saves in this format. |
|
Ok last update before I implement this (and release, I actually plan to release p soon after I setup this + potential avalonia upgrade + setup CI). It's basically a mixed bag, but I can confirm reading will be 100% supported as well as updating an existing save. I did some digging and I found a VERY useful thread by someone who was working to reverse the format for No Man's Sky: goatfungus/NMSSaveEditor#306 There are only a few things I knew that they didn't, but most of it is essentially as much as I could gather and they also performed more testing than me that proves/disproves some stuff. With all this info, I was able to come up with how this system works at a high level, what we can do with it and what are the practicality of doing so. I'll give only a high level explanation so people can understand, but feel free to check the issue I posted above for the full details. How the format worksYour files are located at
From there, it starts to get tricky, but basically, an xbox save file is made up of containers which can contain one or more blobs which contains the data. Fortunately (or unfortunately as we'll see shortly), bf made this super simple: there's only one container with one blob containing all the 4 files persisted by every versions (config.dat and the usual 3 saves files). So if you piece together what the issue above says, we essentially have only 3 files involved in this whole thing that are in a structure like so: The container.index has some unknowns in its file, but more importantly, it contains 2 pieces of information to resolve the contrainer: its name (that 16 bytes folder name is its name) and its number (which is the suffix used in the inner container file). This means these 2 info MUST match the structure. Once you get into the inner folder though, it's easy: the container.[num] file is fully known and it contains the blobName (another 16 bytes hex name) which is ultimately where the good stuff is. The encoding is super simple: start with a uint32 with a value of 4 and then do a What this all means?Gathering all of this leads me to some observations:
So basically, creation from scratch is not possible, reads is 100% doable, conversion to is possible (with caveats) and updating existing save is doable. However, we need to talk practicality for a moment. Practicality and final conclusionLet's face it: this version is the worst version of the game to buy short of those cloud gaming ones because it is known to have at least 2 major issues and I am not gonna lie, one of the main reasons I want to implement AT LEAST reading the file is because I had to manually convert like 5+ people's saves so far since they wanted to migrate AWAY from it in part due to the game no longer being on game poss. What I mean is that not only converting a save TO this format isn't just not popular in demand, it's also less practical: I always would not recommend to buy this version over the MANY other ones that don't have such problems EVEN if you buy it on switch (requires homebrew to edit saves) or ps4 (which I have no samples of to test and definitely requires homebrew). Creating a save from scratch in this format is even worse considering this. Given everything, it's not worth the effort investing in save creation. THAT BEING SAID, it is also not worth to convert TO, but this is also because there's an additional complication. When I said the structure of the blob is too simple, it's because it combines your config.dat and ALL THREE save files into one. This means that if you want to CONVERT from pc/switch to xbox pc, what do I do to generate the blob? Do I give you a default config which clears all your settings? Do I leave the other 2 saves blanks which might delete them if you replace the blob file? It's such a different structure that it basically means the most reasonable way to accommodate it is to build a module SPECIFICALLY to generate this format with 3 different save editor sessions and it has to be AFTER I get done a config editor which is already platform specific to start with... So it's a lot of effort for very little gain. THAT BEING SAID, there is however one usecase that this doesn't apply: updating an existing save. If you load an xbox pc save, edit it, it is actually not hard to save it back in the same blob with your edits. The most complications are ensuring the save data after the one you edit are shifted correctly, but the rest is the same. All it would need is to have the format class remember the state at which you read the file and use that info to write the new data correctly on save. This is something I am fine to implement even the low practicality because it's relatively low effort and I want to implement reads anyway so might as well. So to conclude:
There, hopefully I can release within a week :) |
|
This is now supported as of 1.0.0 |
With the release of the game on game pass, it brought a new save format.
The save is a random string of letters and numbers with no file extension located in
C:\Users\{user}\AppData\Local\Packages\DANGENEntertainment.BugFables_zfxw8h9xxzgzt\SystemAppData\wgs\, then inside two userID folders withinwgs\.When opened in Notepad++ it seems like the flags are stored mostly in plaintext, but I also don't exactly know what I'm doing so I can't be certain. I know this is probably a very niche request but I'll help in any way that I can if you have the time to work on it. I'll paste the plaintext below and also attach the save file itself if you want to poke around at it.
Thanks a lot for your contributions to the Bug Fables scene!
Here is the save file
The text was updated successfully, but these errors were encountered: