Hello,
The format of the war3mapUnits.doo file inside map archives has been changed as of 1.32 to additionally feature a “skinId” attribute per unit/item object. But the version/sub version numbers after the “W3do” start marker have not been increased, i.e., to parse the file properly, additional context information is needed now, i.e., one needs to know what game version the war3mapUnits.doo was saved with as found in the war3map.w3i.
This breaks existing libraries/tooling which handle war3mapUnits.doo as a standalone file.
Observed on: 1.33.0.19308
Expected:
The format version should be increased to indicate the different format. If the indication should now be using the war3map.w3i in general instead, then at least change the specified format version in the war3mapUnits.doo one last time, maybe to 0x0 in order to indicate that it is not self-sufficient anymore and in order to not break backwards compatibility.
2 Likes
Is there a version field? A lot of WC3 binary files were reverse engineered by fans and as such many assumptions were made.
FYI they’ve done this pretty frequently since the reforged team took over so just gotta expect it basically
There is indication that suggests so. It’s right after the start token like in other file types and before the object definitions. The WE does not suggest a global doodad property, nor does something come to mind that a global doodad property makes sense. It’s a value that is not large when interpreted as the common Warcraft 3 integer but quite specific. It was observed to be very invariant. The reverse engineering notes suggested the “sub version” to match RoC/TFT. The other bytes were observed to be 0 invariantly and if it was a bit set, it would be atypical to other flags fields, so it’s more likely an enum. When you take an existing doo file and change the “version” to 0 for example, the editor complains that the file is invalid, which you wouldn’t normally do with simple bit set or integral value fields.
So far, I know this from the war3mapUnits.doo, war3map.doo and war3map.w3c. It is also inconsistently solved even in the newer patches. The objMod files (w3u, w3t, w3d, …) have increased their version field as did the w3s. With the objMod files you may argue that they are public interface, you can export them standalone, so it makes more sense to make them self-sufficient, but there is no such feature for the w3s.