I could have sworn someone already made a fully functional MPQ system that supports every MPQ type from Diablo II to StarCraft II (and probably Diablo III soon if not already).
If you want authentic behaviour, they also made a header file that allows you to interact with the WarCraft III libraries to open MPQs in the exact same way as the game does.
Are you talking about StormLib or SMPQ? I am aware of those tools but I want to replace them with my library (StormLib has a very bad code design and no real abstraction). Of course this means more work for me but as I wrote, reading of most files does already work. Furthermore, this library should only support Warcraft III formats for the moment, so I am happy with that.
Are you sure that the tileset constants have to be coupled into the program data?
Are all those dynamic structures really needed for storing data? I am sure simple arrays would be faster and suffice.
I wanted to have an abstract interface for all kinds of tools, so each tool doesn't have to load and write the data in its own way. I know it seems to be a very huge library of classes for each data type but imagine minor tools which only change some parts of an MDX files for example.
Of course it is not as efficient as modifying files directly but I guess in most cases you have to rewrite the file anyway (if you add some structures or their size is being changed).
When writing terrain mesh data, you incorrectly limit the player to 16 tile types and 16 cliff types. There is no limit as long as the number is elements is stored correctly. Obviously only the first 16 can practicly be used due to the nibble sized index but WarCraft III will still load more than 16 (is a valid mesh file). Any such restriction has to be applied at a higher level of program architecture as it is not truely an invalid number.
Yes, you are right. I didn't consider that. It's a minor fix. I just have used my environment and tilepoint classes for fixing some terrain yet.
Map vertices are stored in a structure more complicated than needed which makes iterating through all elements needlessly complicated. I imagine the best solution would be to have an array stored in the natural read/write order and then declare mapping functions that depends on X and Y size. Altering map size would force a rebuild of the array during which some translation algorithms could be used (potentially taking advantage of bulk copy functions).
Hm, most of my other structures are implemented like this (I use vectors if the number is stored). For terrain I thought it would be nice to have a map but maybe I will change this because I've already changed many structures to get a better performance on reading and writing. By now, I prefer this way and mapping the structures if they have to be searched faster (as you suggested, I guess).
@Troll-Brain:
I would like some help in way of contribution (as Dr Super Good already did by writing his post, thank you). If some of you are familiar with C/C++ you can just post reviews or send patches. As you wrote, I only tested it on my Gentoo Linux system, so testing on other operation systems is always appreciated!
Please consider that this was more or less my little hobby project where I improved my C/C++ knowledge, so the design of this library shouldn't be the best but still better than some random C-like source code which is really hard to maintain.
It would be great if I could improve this library with your help so we can maybe have our own World Editor one day with better terraining and pathmapping support etc.
stream. Usually you can use something like 
