1.36.0.20200 Naga buildings (KMTF) still broken after "fix"

PTR Discussion and Bug Report
1

On August 17th, 2022 a new patch for Warcraft III: Reforged broke the 3D asset loader. In this patch, a new asset format for MDX, “version 1100,” was introduced. Along with the change to the Reforged ingame asset parser, the game code was broken by a bug so that classic “SD” models that used the KMTF chunk type would not load correctly. [Bug affects all asset versions: 800, 1000, 1100]

In the recent patch 1.36.0.20200, probably because users informed you about this bug, the patch has changed the contents of the 3D assets that most commonly show the issue but did not fix the bug in the code.

This means that you have NOT fixed 20 years of custom games that are affected by the code bug, because you did not fix the underlying code bug. Also, fixing the 3D assets and not the code obscures the issue so that it will be more difficult for your developers to see and fix the bug.

Now it will look like the bug is fixed in your office, but the bug will not be fixed for users out in the public.

You can confirm that this bug is still present by opening the Patch 1.35 game that is currently live, taking out of the game the Buildings\Naga\TidalGuardian\TidalGuardian.mdx file, then importing this file in the Asset Manager of the Patch 1.36 PTR World Editor. Upon doing this, the Patch 1.35 file will still appear broken.

Edit:
I am the developer of “Retera Model Studio,” a fan-made tool that can load MDX versions 800, 900, 1000, and 1100 and cross-convert between them. I assure you that all the data is present in the Patch 1.35 assets that you recently reformatted, and that reformatting them is unnecessary, and that if you fix the code and not the 3D files then you can solve the underlying issue without the necessity for modifying individual assets as you have done.

Edit 2: Retera Model Studio is also fully open source and public domain (ReterasModelStudio/LayerChunk.java at master · Retera/ReterasModelStudio · GitHub), so you could use my code if you need to, to compare against your own if this helps to restore the parser for the older formats in a way that actually works. However, my code is written hastily for a hobby and was not written professionally and is coded to a lower coding standard than Reforged, so per the MIT license my code comes with no warranty nor guarantee that it would work properly, etc.

Edit 3:

Correction to the above: Whatever you did wrong is more wrong than what I reported above. It appears that even importing the Patch 1.36 PTR asset into the Patch 1.36 PTR World Editor is broken. So, my code will not help you.

I was incorrect to assume that the 3D assets were fixed in the recent PTR. Now, it looks more as if the recent PTR has some logic going on that I do not fully follow. Maybe it loads some assets at preset file paths in a special way that is not used for assets in general. This is crazy. I may not be able to help you further with technical details (because I do not have your code), and perhaps what I have said so far is technically incorrect because of something crazy going on in your Reforged code, but I can assure you that I am seeing broken behaviors on the PTR.

2 Likes
2

Hello Retera, I can confirm this issue, I will be explaining this problem in layman terms:

The problem:
Models which are animated using more than 1 texture are (right now) just moving around a single texture to make it seem like they are animated, before that it would switch multiple textures, like a sprite, this behavior is broken as seen by the video below.

https://www.youtube.com/watch?v=Lv5Hefe4810

In this video you can see:

The top line of units/buildings (except the leftmost unit) are 1.27 assets that were imported into 1.36’s PTR editor, as you can see, they are broken just like before the fix.

The leftmost unit at the top is a custom model (this is to show that every custom model using the technique is affected by the issue, hence why it has to be fixed systematically and not per model like the current fix.

The bottom line of units are the manually fixed models by the Warcraft 3 team in 1.36, while they work fine (at the moment) the problem still resides and every existing custom model will be affected. Furthermore, if a team at some point in the future fixes the issue, this might cause further problems.

The problem was better explained technically by Retera, I just wanted to contribute a more visually understandable explanation.

3

I disagree with the wording of this sentence. If a team at some point in the future fixes the issue, then the issue will be fixed. It is good to fix the issues.

4

Yeah I guess I should have specified better, it’s good that they fix it, just that if then they forget to revert the models once the system wide fix is done then you’ll have a bunch of models with useless workarounds lying around in the game files.

5

Based on further testing that I was doing today, I was coming around to the idea that the technical details surrounding what broke listed in my post are actually factually incorrect. So, actually, there might not be a workaround in any of the models.

The behavior that I was seeing in the world editor was more consistent with the idea that the code was doing something like:

function filePathIsOnOurListOfBrokenModels(String assetPathToLoad) {
    if (assetPathToLoad == "Buildings\Naga\TidalGuardian\TidalGuardian.mdl") {
        return true;
    }
    return false;
}

function loadModel(String assetPathToLoad) {
    if (filePathIsOnOurListOfBrokenModels(assetPathToLoad)) {
        loadUsing136Fix(assetPathToLoad);
    } else {
        loadUsing135CodeThatImAfraidToChange(assetPathToload);
    }
}

This is just a pseudocode example, but the behavior exhibited in my World Editor was insane like this. There was a decision happening based on some criteria – maybe just a preset list of ingame assets – and all other assets were still broken. Even the ingame assets, if loaded a second time as a “custom” import, were also broken. I am honestly confused by what is happening here on the 1.36 PTR, which is why my previous post might have been so incorrect.

7

I don’t think it’s based on file path as it’s broken if you replace the original models with 1.27 assets in the same path they are now broken, it has to be a different thing.

8

Yes but it may be based on asset loading source. For example, the game might be doing this:

function filePathIsOnOurListOfBrokenModels(String assetPathToLoad) {
    if (getLoadingSource(assetPathToLoad) == LoadSource.CASC) {
        return true;
    }
    return false;
}

or perhaps it could also be

function filePathIsOnOurListOfBrokenModels(String assetPathToLoad) {
    if (fullResolvedPath(assetPathToLoad).startsWith("war3.w3mod")) {
        return true;
    }
    return false;
}

Really, for us as users who cannot tell, I was wrong to even speculate. Knowing and understanding what they did can be very difficult from the outside.

What we know is that their solution is an incomplete hack and is not a full solution to the issue. Beyond that, we can do little more than to speculate.

However, here is one thing that I know for certain:

As the author of Retera Model Studio, an open source tool for handling Warcraft III models specifically, I can tell you that the “bandaid” fix in the code added in the Patch 1.36 PTR is written poorly. It attempts to solve the problem over a limited scope of affected assets, instead of fixing the asset loader in a fundamental and simpler way. When I was forced by Activision’s updates last fall to update my code likewise, I was able to implement a more fundamental and simpler solution that affects all models loaded, and retains support for all existing assets from the last 20 years. So, I am not speaking from a point of ignorance when I tell you that you CAN fix this and there IS A WAY. Like Ron Swanson at the hardware store, “I know more than you.”

9

I think this video (By Retera) might also be of a bit of help, nearing the end he does get a bit too technical but I hope at least someone in the studio can understand the technical jargon:

The key thing to take is basically that the ideal fix is for this to work for every SD model, not just the ones inside the casc.

1 Like