OPS savefiles (palette key) break BSON specification, preventing interoperability

[tigercat2000]

OPS savefiles (palette key) break BSON specification, preventing interoperability

[git4rker]

why didn't you open a pull request?

[tigercat2000]

why didn't you open a pull request?

I'm not sure how to version this correctly in this codebase, it's a breaking change

[LBPHacker]

This has been known for a long time and we've decided that because there's nothing we need to be interoperable with, it's a non-issue.

As a fix of the bureaucratic variety, we would accept a PR that renames BSON.cpp/h to PowderON.cpp/h.

[tigercat2000]

I mean I'm working on a simulator that takes in OPS savefiles in Rust, so that's one thing that it's a problem for lol

[LBPHacker]

Welcome to tech, where technical debt is cumulative and mistakes made 10 years ago affect you today :)

[LBPHacker]

To be clear, I'm being depressing about this for more than just the fun of it. I see no economic way to fix this. We do try to maintain compatibility with old clients at least to the point of having them be able to render a partial thumbnail of new saves, and fixing this problem would make that impossible. In light of the interoperability requirements we have that I explained above (none), this would not be economical.

[jacob1]

I manage to parse it in python, because the library I use doesn't care about all the keys I don't use. If you don't fetch palette info, are you able to parse the save data?

[simtr]

Changing this to use BSON_OBJECT should still be reasonably backwards compatible. Palette data is optional-ish as the game will fall back to the compiled element map and should still be able to render thumbnails most of the time.
But at the same time, the save format wasn't intended for interoperability, though the binary format of array and object are the same so patching \x04palette\x00 sequence to \x03palette\x00 should work if you need to parse using another library.