Model texture paths

[Retera]

Why does Hive not automatically update the used texture paths of a model to some consistent value or at least have an autocorrect path option at model upload time?

It's 2021. People have had almost 20 years to learn how Warcraft 3 handles texture references from inside models. But because my MDX models that I created years ago aspired to match the Warcraft 3 style and organization, I often have a model with a texture path such as "Units/Naga/MurgulEmperor/MurgulEmperor.blp". This comes from when I organized the biggest MPQ archive of models I had ever created (with 300-500 custom assets) at the request of Kam when he saw that the original archive had all the files usually imported at "no path". So when I think about that, for me these long texture paths are the correct way. And, when I upload one of my custom models from 15 years ago to open it up and celebrate the community by sharing it, the files are old and I'm not really interested in changing them to make specific "web" versions because that feels unnecessary.

But even now after 20 years or whatever people still DM me asking why my model won't load for them. And if you can imagine, people like me have been helping people with problems like this for 20 years and so it's not interesting and it's very obvious when their problem is that they don't know how the system works like this.
The Hive already automatically generates a README that tells the users accurately how to import the textures, and what paths to use, but this would require users to READ which is asking too much. The point of "View in 3D" is that it is all the user needs to know. (The only other possibly interesting info a professional user might need is license info, which I often find hard to determine for any given model which can be frustrating.)

So, I was wondering if we could have at least an optional checkbox here on Hive at model upload time to automatically change all texture paths to "no path" in the uploaded model? Ideally for similar reasons there should be a second option to automatically combine portrait files into a single MDX with the main file, but adding that might be above the pay grade of hobbyist programming for a site like this. But changing texture path automatically is something I didnt understand why we do not have, and I have not undersrood why for years.

Curious on the thoughts of others about this... thanks. I'm probably not going to help the guy who DMed me more than I already did.

Edit:
Another reason that Hive specifically exacerbates this issue is that if I was going to share a ZIP of a model and texture with someone, I might share a zip containing the MDX and then a subdirectory named "Units" and in there another subdirectory named "Naga" and in there another subdirectory named "MurgulEmperor" and in there I would put the texture. And then when a user downloads the zip, its forced on their computer to see how the original location of the texture is to be in a subdirectory in this way. Instead, Hive sabotages models of this form by requiring the texture to be generated into being in the same root directory as the MDX, which means the MDX probably cannot even be viewed correctly in certain older viewers like Prophets War3 Previewer. So a competent user might spend their time creating all those folders by hand just to preview their model. And it only happens because of Hive ZIP generator. Hive site even knows at model upload time that the texture was actually supposed to be in a nested directory.

Edit 2: Maybe an even more ideal solution would be to patch Warcraft 3 so that models and textures in the same folder could see each other, and then to have models use a relative path for textures except when referencing a texture in some other "game storage absolute" location as they do now.

 

[Ralle]

My Mdx parser is only a parser. But aren’t most text strings in Mdx a buffer of a specific length? 256 bytes or something. That should be easy to replace without too much logic.

 

[Retera]

But aren’t most text strings in Mdx a buffer of a specific length?

Yes, as I recall. And for those weird neckbeards who believe that the file paths are part of their sacred art binary that should never be changed (do such people really exist?) we could keep this automatic fix optional with a checkbox anyway.

Edit: Ideally as well as for TEXS dont forget to do the same thing for FAFX chunk file references to facefx file, CORN chunk references to pkfx file, ATCH chunk file references to birthlink MDX models, PREM chunk file references to spawned MDX models or for bitmaps but nobody uses bitmaps on PREM, SNDS chunk file references to WAV/FLAC files, and any others that I forgot. But maybe these could be added later, and surely your parser cant parse SNDS because they're proprietary/unknown to general public.

 

[Ralle]

Yes, as I recall. And for those weird neckbeards who believe that the file paths are part of their sacred art binary that should never be changed (do such people really exist?) we could keep this automatic fix optional with a checkbox anyway.

Edit: Ideally as well as for TEXS dont forget to do the same thing for FAFX chunk file references to facefx file, CORN chunk references to pkfx file, ATCH chunk file references to birthlink MDX models, PREM chunk file references to spawned MDX models or for bitmaps but nobody uses bitmaps on PREM, SNDS chunk file references to WAV/FLAC files, and any others that I forgot. But maybe these could be added later, and surely your parser cant parse SNDS because they're proprietary/unknown to general public.

Right. Sounds like a good idea.

 

[Dr Super Good]

And then when a user downloads the zip, its forced on their computer to see how the original location of the texture is to be in a subdirectory in this way. Instead, Hive sabotages models of this form by requiring the texture to be generated into being in the same root directory as the MDX, which means the MDX probably cannot even be viewed correctly in certain older viewers like Prophets War3 Previewer. So a competent user might spend their time creating all those folders by hand just to preview their model. And it only happens because of Hive ZIP generator. Hive site even knows at model upload time that the texture was actually supposed to be in a nested directory.

I think fixing this is a good idea. Especially since it is possible to bulk import models and textures now using file explorer they should arrive in a ready to use form that can be copied straight into the map folder.

 

[BogdanW3]

What would this proposal do upon encountering multiple textures of a same or same-without-folders name? For madness's sake, let's say I am making an HD model and I want to have all texturesets in separate folders rather than all in the same folder (this is actually useful for easier navigation in some programs like Unity), every diffuse texture just being called D.dds, every normal map called N.dds, every ORM being called O.dds, and every emissive being called E.dds. While they're in the folders, they are both unambigouous and non-overlapping, but once they get crammed into a folder-less setup they overlap with each other. Would this automated mangling instead add the foldername to the texture's name or would it just let the conflict of filenames continue and disregard that it just made a model unusable?

I am aware that my precise example is not likely to happen to any one person's workflow, but it would happen to my Unity HD workflow AND my Warcraft 3 HD texture naming schemes, and thus could happen to anyone else depending on their sorting methods. This means it cannot be eliminated as an option.

Even more simply, let's say someone makes a pack of dragon models, having dragons of different colours in separate folders with all having the textures being {Colour}Dragon\Main.blp, {Colour}Dragon\Wings.blp, {Colour}Dragon\Gutz.blp

Same issues, but a simpler and much more likely example than the extremely perfectionistic HD setup I have.

Edit: the edit 2 of the initial post could be a very favourable solution, but it is not likely to ever happen, and would slow down the loading time of most models if not at the bottom of the loading hierarchy, whence it would probably still be overshadowed by some unwanted textures in the map root if it's an often used filename like bandit.blp. I agree with Dr Super Good that it would be better to let Hive export archives that are ready to extract directly into the map instead, keep the folders but have it simpler by the zip extractor making them all.

 

[Ralle]

I'd probably run through the textures up front and if I discover any conflicts, I wouldn't touch it.

 

[Retera]

I tried making a test model and uploading it and it shows that for this problem case, the current solution on Hive just does not allow uploading the model properly. The Hive texture upload stuff assumes that my "Legs\Main.blp" and "Body\Main.blp" are the same texture asset, and only allows one texture asset upload alongside the model, so as you can see the model does not look like in my screenshot and there does not appear to be a way to even fix it to look like the screenshot within the Hive previewer since Hive is broken in this kind of case:

Orange Centaurion

This is an orange centurion model that I created. It is designed to see how Hive uploads handle models relating to the discussion here: https://www.hiveworkshop.com/threads/model-texture-paths.336789/#post-3512695 Feel free to customize or modify the orange centaurion in any way.

www.hiveworkshop.com

 

[Ralle]

Can you share the model and both textures?

 

[Retera]

Sure, here is the file: