search

inwc3 / wc3libs

Java library for reading and modifying Warcraft III maps and game files
Apache License 2.0
31 stars 11 forks source link

Update .w3i Info file parser #80

Open Luashine opened 1 year ago

Luashine commented 1 year ago

The Map info file has been fully documented now, format versions 0-31. The missing legacy pieces are ROC Beta 100 (the first one).

After implementing this, you'll be able to correctly read the info of ROC/TFT Beta maps.

This would be a total rewrite of the hardcoded W3I.java

Frotty commented 1 year ago

Thank you for letting us know. I appreciate your suggestion, but at this time, I think that implementing this feature is not a priority for us. However, if you or anyone else would like to contribute to the codebase and make this change, we would be happy to review a pull request.

WaterKnight commented 1 year ago

I don't have any such old/odd formatted files for testing, though.

WaterKnight commented 1 year ago

This would be a total rewrite of the hardcoded W3I.java

Well, the scheme there is that every format version will have its own parsing method except that the reusable chunks re-use some code. This may be not so well suited for small changes, but I was planning to do the parsing/writing at some point differently anyway, that the W3I would only be the model class and serializers/deserializers are extracted to better support different formats and those can be generated from schemas and make use of standard serialization/deserialization libraries.

Luashine commented 1 year ago

In Warcraft the parser evolved around backwards-compatibility, like around a living format. The parser is a single entity with some branching for version support and does set default values where needed. This is the reason Hodor wrote his documentation the way he did and I picked up where he left.

WaterKnight commented 1 year ago

Yes, I think it's good to write the documentation this way. If each version was separate, there would likely be drift and it's worse for interfacing. In wc3libs, I also did it this way that you can load files of different formats that map to the same model class and the fields not available in the serialized form are just null/default in the model then. Later, you might want to output it in a different format than it was originally read in, so stuff required in the serialized form missing in the model will again end up writing defaults or if some fields are not supported in the serialized form, those will just be omitted.

We can do this branching strategy as well in the parsers/writers, but when they are auto-generated from a schema that supports branching itself, it does not matter that much.