sinz163 / w3x-to-vmf Goto Github PK

On some maps, files that have been compressed using zlib or bz2 raise an exception.

1. For zlib the error can be "error: Error -3 while decompressing: incorrect header check"
2. For bz2 the error can be "IOError: invalid data stream"

Having a .doo parser (doodad / trees) parser, along with a script to add it to the vmf generation would serve a good use in aiding map devs to get a good copy from wc3

This can be done either through pure python code, or adding python bindings to existing C code, e.g. from StormLib.

Sometimes it can happen that ui.py throws a Tkinter-related exception about not being able to display the topdown picture. After that, a message in the console is displayed about the program requesting to be terminated in an usual way. Finally, the GUI crashes.

I do not know how to reliably reproduce this bug. I have encountered it a few times yesterday, but today everything is working fine again, so I did not write down the exact exception.
It happened when opening some of the bigger maps, thus it might possibly be related to Issue #1.

To help with consistency, some of the files for parsing specific filetypes need to be rewritten as functions instead of classes. As classes, they require to be initialized, and the correct method for parsing needs to be called which can differ depending on the parser.

In some cases it can happen that ui.py throws a MemoryError when opening some bigger maps and creating a topdown picture for them. This doesn't happen for everybody (e.g. I can open the Trolls'n Elves map just fine, but when SinZ does the same, a MemoryError is raised).

It doesn't appear to happen when running the topdown viewer on the map directly.

Some maps cause mpyq to throw an OverFlow error due to trying to read too much data from the file. This can happen when the number of bytes it tries to read are bigger than what can be specified by a 4 byte integer which can happen easily on 32 bit systems.
The error can look like this: "OverflowError: Python int too large to convert to C long"

Because no WC3 map can hold more than 4 GiB of data, this is could be an attempt by the author of the map to prevent people from opening the map.

The order in which the displacement info is listed in a dispinfo entry appears to be incorrect and not correctly sorted by row number.

Example: "row0", "row1", "row2", "row3", "row4", "row5", "row6", "row7", "row8", "row9", "row12", "row13", "row10", "row11", "row16", "row14", "row15"
(disregarding the data that followed after each row number)

Questions to be considered: Is the bug caused by incorrectly creating and adding the displacement info in VmfGenerators/displacement.py, or is it actually an issue in the underlying vmflib code?

Does it actually cause any bugs when compiling or testing the map, or is it just a minor inconvenience?

A map with encrypted, but not compressed data is required to properly test and fix the decryption process.