10-16-2020, 08:19 PM
(09-10-2020, 11:28 PM)xelivous Wrote: I tried reverse engineering the format myself but the furthest I got was figuring out that the first 2 bytes were likely a version identifier, next 4 bytes are an int denoting the size of a data blob, and then the rest of the data blob is mostly unknown. There's a good chance that the first 4 bytes of the data blob are also a version identifier but there's no way to really tell. All of the data seems to be strewn about in a way I can't really glean from trial and error, and even something as simple as changing a single vertex changes a ton of the data.
I've worked out that the files are compressed and I think checksummed with a trailing 4-byte checksum, which is why so much of the data changes when you change just a tiny bit of the design, and why editing just 1 byte makes the modified file not open. The underlying compression is using QT's qCompress/qUncompress functions, but I tried feeding the whole blob with and without the length prefix and checksum to qUncompress and qUncompress just always said the data had been courrupted (presumably because the checksum didn't match). So I think Haxus's wrapper function (which seems to be called AuUncompress) is doing some other transformation before qUncompress-ing the blob.
If someone can work out what that is (or if Haxus cares to share), we can write a tool to dump the actual design data from a compressed file and start working out how things are represented.
If anyone happens to have a debug build of the client laying around that I could borrow, that might help speed things up.