Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overcomplex creations do not decode #1

Open
Kade-N opened this issue Feb 10, 2020 · 2 comments
Open

Overcomplex creations do not decode #1

Kade-N opened this issue Feb 10, 2020 · 2 comments
Labels
bug Something isn't working

Comments

@Kade-N
Copy link
Member

Kade-N commented Feb 10, 2020

Some overcomplex creations fail to decode.

I'm not sure of the exact reason for this. It fails during the gzip decompression.

I've heard that this could be because Spore doesn't save all the required data in the PNG file, for creations that are well beyond the complexity limits. Therefore, it would not be possible to decode, as the data isn't even present in the PNG file.

More information is needed, before we can figure out how to fix this issue, or if it's even possible.

@cpoftea
Copy link

cpoftea commented Jul 24, 2020

Spore doesn't save all the required data in the PNG

I didn't hear it. More-fore, Spore can open complex creation which data not stored in official Sporepedia or it was created with mods.

@Kade-N
Copy link
Member Author

Kade-N commented Jul 24, 2020

Forgot to update this thread with more accurate info. Copying this from discord:

Technically, the complexity of a creature, as it appears in the editor, has no bearing on whether or not it can be saved. The complexity meter is, for this purpose, a made-up concept, and has nothing to do with the technical side of things.

Spore PNGs are always 128x128. Because of how the data is stored, each pixel is capable of holding 4 bits of data. This gives a total of 65536 bits, or 8192 bytes (aka 8 KB). This space is used to store two things: a metadata header (creation name, author, ID, etc...), and an XML document that holds the model (parts and paints).

The XML document is produced when a creation is saved. Before embedding it in the PNG, it is compressed, to reduce its file size.

Since we're limited to 8 KB of space, the XML document (after compression) must be smaller than this. In most cases, it is, and therefore the PNG works fine.

However, if, after compression, the XML doc is still larger than 8 KB, the game will put the first 8 KB of the document into the PNG. The rest? It can be found in your game save files, but there is currently no easy way to extract this data, nor is there any way to share it.

So you end up with only a portion of the creation in the PNG. The rest is stuck in your save files.

Once again - the complexity of the creation has no bearing on this whatsoever. Everything comes down to how well it can be compressed. It is standard deflate (gzip) compression. I am not familiar with the format, but generally speaking, duplicate data can be more easily compressed than unique data. So, using the exact same part will generally take up less space than using a bunch of unique parts - and therefore increase the chances it will compress small enough to fit the PNG.

Tl;dr: A million knurldowns is probably smaller than a hundred unique parts

@Kade-N Kade-N added the bug Something isn't working label Jul 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Development

No branches or pull requests

2 participants