Hey,

currently there is a bug that will result in incorrect unpacking of data. In very rare cases, you will receive a (distance/length) symbol, with the distance being higher than the current pointer of the decompressed data buffer. E.g. you are writing on copyPos = 5, receiving (6,3), it will go write the values of indices {-1,0,1}, or without a boundary check the values {deflatedBuf[-1],deflatedBuf[0],deflatedBuf[1]}

In Settlers, this will result in the values out of bounds trying to be read being 0, but due to the implementation of StreamWriter.getByte(x) with x < 0 || x > data.length returning -1 (0xFF), it will not do the same as expected. Weirdly enough, this appears to be intended behaviour to read beyond the beginning of the inflated buffer.

Sadly I do not have an example at the moment, but I just wanted to let you know that this may result in unintended behavior in the future :)

Also I'd like to say that your work is amazing! I would have probably given up if it wasn't for your RE'ing of settlers DEFLATE function. I have learnt so much about compression from trying to understand your implementation and it helped me a lot! I have at this point completely reversed the entire MAP/EDM format with all its segment (chunk) contents and I will soon upload a repository if you lack any information, feel free to use that repository in return of your great effort👍

Cheers

Hi, cool project.

I see that you can read and display .map files.
Do you think it's possible to write .map files so we can create maps programmatically?
Or do you not actually read .map files and just display what the graphics engine spits out?

Thanks in advance

Hi tom, is there a way to contact you? It seems you don't have an email provided.
Cheers, MadShadow