• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Bypass 8 MB

Status
Not open for further replies.
Level 16
Joined
Mar 27, 2011
Messages
1,349
I don't think you can if you intend on making your map multiplayer. You have 2 options. Relocate some imports into a custom MPQ, or compress your imports. If you choose to use a custom MPQ, everyone who plays your map will require this MPQ to play. It won't get downloaded with the map. Could be tricky. Next option is to compress your imports.

Compress your files in your map to reduce the map size. Compression is a method used to usually decrease
the quality and file size of a file. Your map can be compressed and the files (imports) inside your map can
also be compressed.


There is not much you can do to compress model files.
 
Level 24
Joined
Aug 1, 2013
Messages
4,657
There is a reason for having the 8MB limit on B.net.

However, I also agree on not having a massive map even just locally.
Imagine having 20 of your maps because of previous versions to take a look what you have changed that makes something right or wrong.

The best solution that I found is using local files.
You have to do some setup to enable them (also requires a registry edit which you should do with causion) but after that, it gets amazing how easy it is to import stuff to your map... better said, you dont have to import them at all... forever. (With some exceptions.)

What you do is make a folder inside your Warcraft III folder and give it a nice name.
I called mine "AutoImport".
In that folder, you then place your stuff. It be icons, models, textures, sounds, music (big byte-eater), etc, etc, etc.

Then when you have your unit in the object editor (which you want to have the custom model) you then change the path to "AutoImport/MyModel.mdl" (if your model is named "MyModel" and your folder is named "AutoImport" and you have it there instead of in a subdirectory).

For making it multiplayer, you have to tell the other people to enable the local files and download all files that your map needs.
(For real, you are not going to B.net and download a 30MB sized map with 100kB/s and you will download the resource folder when you download the map... and everyone needs local files enabled when they want to make really cool maps :D)

Anyway, there should be some tutorial about how to enable and use them.
I recall a nice tutorial by LordDz (iirc).
 
Level 3
Joined
Jul 18, 2010
Messages
54
Do you know about the thing you put on Redist>Miles? I loved that tutorial, gonna use.

My map Saint Seiya is going to have too many skills and models.

Just for Athena is going to have 88 Male Models + Female Models.
And more 88x4 Spells. So it's kinda HUGE.
 
Level 24
Joined
Aug 1, 2013
Messages
4,657
You shouldn't use custom MPQs because you would have to go to your Warcraft III folder to set the right MPQ each time for each different map.

And you wont spam folders all over the place when you have one main folder where you place all local files in.
 
Level 24
Joined
Aug 1, 2013
Messages
4,657
Yep.

Take me for example.
My Warcraft III folder is "C:\Program Files (x86)\Warcraft III\"
In that folder, I have a subfolder called "AutoImport" ("C:\Program Files (x86)\Warcraft III\AutoImport\")
In there I have a few folders: "Models", "Icons", "Audio", "Textures".

In my maps, I have a footman.
The default value of a footman's model is "units\human\Footman\Footman".
I replace that path with "AutoImport\Models\Units\Footman.mdl".
Now the game will search for the Footman.mdl file in "C:\Program Files (x86)\Warcraft III\AutoImport\Models\Units\".
The game doesnt care about the files that are in there, it just loads the file you want.

One other feature is that you don't have to get them in the loading time.
You can, but you can also choose to load only the files you are going to use.
For example when you play an AoS and you have 50 heroes (5v5), you would only use 10 of the 50 so you dont want to load the other 40 heroes.

It will spam folders inside "AutoImport", but you wont use it for anything else so you dont care about it.
You will have to copy and paste the paths to the editor but you would have to in any case if you would import them via an MPQ (unless you use a replacement) or import manager.

The only things that you cant import like this is terrain textures, DISBTN (obvious because of the path), scripts (.txt stuff like CommandStrings.txt) and replacements that aren't able to be changed in gameplay constants/interface.
 

Chaosy

Tutorial Reviewer
Level 40
Joined
Jun 9, 2011
Messages
13,182
Icons wont work properly as you pointed out as the disabled version need to be at the right path.
A model's texture usually got their own path as well, either Texture/name or just name. Which puts it directly in your Wc3 directory. How wonderful. (this can be fixed but it's not really worth to edit and reimport every single model with a texture for this purpose)
Skins do not work at all.

So no, using a single folder wont work.
 
Level 24
Joined
Aug 1, 2013
Messages
4,657
You only have to import the disabled icon in the import manager to "ReplaceableTextures\CommandButtonsDisabled\DIS<button name>"

You can change a model's texture path with mdxpather or even notepad.
In-game textures are automatically loaded.

Skins aren't really what they seem to be ;)
They don't work the same way but they work.

So yes, a single folder works... and I have used it quite often... I prefer that over anything else because it automatically configures instead of me having to import the models via the import manager or editting an MPQ.
 

Zwiebelchen

Hosted Project GR
Level 35
Joined
Sep 17, 2009
Messages
7,236
It's a shame that Blizzard did put a protection in that scans models for the texture filepaths and turns the model into a green box regardless of if the actual texture there is currently displayed or not.

I tried to circumvent the need to import HD textures in max resolution for models with basicly two animations: a lowres one, using a default imported texture and a highres anim, using the one in an external folder.
The game can then read a dummy file automaticly to determine if that external folder exists or not:
If not, use the lowres animations, if yes, use the highres animations.

That worked fine in theory. But in practice, it doesn't matter if the texture is actually displayed by the model or not: if only one texture is missing, the model is simply not displayed.

This could have been THE ultimate solution for highres doodads and unit models. But blizz said "screw you guys!".



However, I came up with a new concept on how to fix this problem:
What if we use the Preload bug to actually write a dummy texture into the folder it is attempting to read from?

Basicly, what you can do is open a black 1x1 pixel BLP (the smallest texture you can have in WC3) in the windows editor, copy & paste the encrypted machine code out of it, then use the Preload native to create this as a placeholder texture in the designated filepath?

In that case, the texture checked would be registered as existing (and working) and probably display fine after starting the game (as a full black texture). We could then use the animation approach to display the imported lowres texture or the highres texture (if the 1x1 black texture was overwritten by the user by installing the external folder).

Is there a flaw in my idea? A problem could arise if creating these 1x1 textures in map init is too late for the game to preload the model textures. In that case, players would have to restart the map/game at least once to get rid of the green boxes.
 

Zwiebelchen

Hosted Project GR
Level 35
Joined
Sep 17, 2009
Messages
7,236
The green box appears when you did something wrong... you missspelled a texture path or didnt copy one.
Better to have the green box instead of having that small texture of the bottom side of someone's foot (for example).
You misunderstood.

Basicly, my approach works like this:

Have an imported doodad model.
"Stand" animation uses an imported texture at war3mapImported/house1.blp
"Morph" animation uses a texture at External/Textures/house/house1.blp.

The second anim uses a texture that only people have that use the distributed external folder (with local file support enabled).

So far so good.

I can now use SetDoodadAnimation to switch between both anims (and thus both textures) on the fly.

To detect if a player has the external file or not (and thus, to determine if the game should play the "stand" or "morph" animation locally), I can use various methods. The most popular one is having a dummy sound file in the folder and just test if the file duration of this sound is > 0.

-> We now know if the external texture exists or not (unless the player deliberately deletes textures from the folder).


In theory, the game should now automaticly display the (imported and existing) lowres texture for player A who doesn't have the folder and the highres texture in the external folder for player B. This works very well in practice for player B.

The problem is: player A will see green boxes, even if the external texture is not even displayed on his machine. This is because WC3 does a sanity check when preloading the model and flags the model as inconsistent if it misses a texture, regardless of if it is needed or not.



This is where my idea comes into play:

Use the preload native to write a dummy 1x1 black texture into the filepath of the highres texture to make sure the game always finds a texture, even for those players that don't have the folder.
I tried just creating an empty .blp file in the past and this didn't work, as the game also checks if the file header of .blp is valid.
However, by using the editor to extract the machine code of the blp file and using the Preload native to also write that into the dummy file, we might be able to effectively fool the game into thinking the .blp is valid.
 
Level 8
Joined
Jul 24, 2006
Messages
157
However, I came up with a new concept on how to fix this problem:
What if we use the Preload bug to actually write a dummy texture into the folder it is attempting to read from?
Local files need to be enabled to read them?
The best possibility I see is a tool similar to my doodad merger. Chunks of doodads are created as models and used in the map as doodad. In the normal version this doodad cannot be loaded and create a green box model that is hidden via trigger.
But when you have them in the local files a trigger makes the normal doodads invisible.
The idea of merging is to reduce the number of additional doodads that are necessary.
 

Zwiebelchen

Hosted Project GR
Level 35
Joined
Sep 17, 2009
Messages
7,236
Local files need to be enabled to read them?
DAMN! You are right... I totally forgot that WC3 can't even "see" the file in that case.
Alright, screw this; this wouldn't work. :(

The best possibility I see is a tool similar to my doodad merger. Chunks of doodads are created as models and used in the map as doodad. In the normal version this doodad cannot be loaded and create a green box model that is hidden via trigger.
But when you have them in the local files a trigger makes the normal doodads invisible.
The idea of merging is to reduce the number of additional doodads that are necessary.
The problem is that you can not remove, hide or create doodads. You can only do that with destructables.

... which means you would still have to make these doodads invisible by using the animation trick. AND have a destructable for each highres version. ...
or even worse (for game performance): have twice the amount of destructables in general.

I mean... it IS possible, but it's super inconvenient and probably not feasable unless you really build your map around the use of DoodadMerger.
 

Zwiebelchen

Hosted Project GR
Level 35
Joined
Sep 17, 2009
Messages
7,236
You can always migrate to StarCraft II which has a much larger limit (~100MB or more, infinite with asset mods hosted by other accounts).
Nobody will migrate to SC2 just because you keep bugging them.

You tried that strategy for years. It doesn't work. And it's super annoying.

Wrong? You can hide normal doodads, for example:
Animation - Play the hide animation for all doodads of type Cattail within (Playable map area)
Yes, but this will not cause the green box to disappear if a texture file is invalid ... because it doesn't truly "hide" the doodad, it just makes the material invisible or a geoset, depending on how the model is constructed.
 

Zwiebelchen

Hosted Project GR
Level 35
Joined
Sep 17, 2009
Messages
7,236
It's not. Path is "Objects\Invalidmodel\Invalidmodel.mdx"
Interesting. So I import an empty .mdl in this path and the boxes are gone forever?

In that case, all we need would be a 3rd party tool that adds a death anim to all doodad models and stacks a second doodad on top of the first that uses the external model.
 
Level 3
Joined
Jul 18, 2010
Messages
54
You can always migrate to StarCraft II which has a much larger limit (~100MB or more, infinite with asset mods hosted by other accounts).


Hey! So, right now i'm kinda worried about that, i really tought of migrating to SC2

But the real problem is: I need lots of models, and the community really hates Animes, and because of that i'm really having some problems on actually doing a good RPG.

But, if i get support i can do it on SC2! For now i'm staying at WC3.
 
Level 8
Joined
Jul 24, 2006
Messages
157
In that case, all we need would be a 3rd party tool that adds a death anim to all doodad models and stacks a second doodad on top of the first that uses the external model.
I think you can hide doodads even when they dont have a death animation.
Thus the easiest way would be to create a copy of the model that uses another texture path and in the map stack a second doodad on top.
Only downside is that the doodad count would be increased considerable.
 

Zwiebelchen

Hosted Project GR
Level 35
Joined
Sep 17, 2009
Messages
7,236
I think you can hide doodads even when they dont have a death animation.
Thus the easiest way would be to create a copy of the model that uses another texture path and in the map stack a second doodad on top.
Only downside is that the doodad count would be increased considerable.
Yes, you can use any animation name; however, "death" offers some advantages over other names, in that you can preplace it with that animation as destructables and that you can also use it as a special effect then.
That might not matter for this particular case, but it's a good practice.
 
Status
Not open for further replies.
Top