Dismiss Notice
60,000 passwords have been reset on July 8, 2019. If you cannot login, read this.

Bypass 8 MB

Discussion in 'World Editor Help Zone' started by Spiderligh, Nov 22, 2015.

  1. Spiderligh

    Spiderligh

    Joined:
    Jul 18, 2010
    Messages:
    54
    Resources:
    0
    Resources:
    0
    What are the ways to Bypass the 8 MB? And how?
     
  2. Radicool

    Radicool

    Joined:
    Mar 27, 2011
    Messages:
    1,148
    Resources:
    4
    Maps:
    4
    Resources:
    4
    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.
     
  3. Eagle XI

    Eagle XI

    Joined:
    Mar 9, 2012
    Messages:
    1,359
    Resources:
    117
    Models:
    2
    Icons:
    109
    Packs:
    4
    Skins:
    2
    Resources:
    117
  4. Spiderligh

    Spiderligh

    Joined:
    Jul 18, 2010
    Messages:
    54
    Resources:
    0
    Resources:
    0
  5. I think it's both but it's useful, try it.
     
  6. Wietlol

    Wietlol

    Joined:
    Aug 1, 2013
    Messages:
    4,638
    Resources:
    3
    Spells:
    3
    Resources:
    3
    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).
     
  7. Spiderligh

    Spiderligh

    Joined:
    Jul 18, 2010
    Messages:
    54
    Resources:
    0
    Resources:
    0
    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.
     
  8. Wietlol

    Wietlol

    Joined:
    Aug 1, 2013
    Messages:
    4,638
    Resources:
    3
    Spells:
    3
    Resources:
    3
  9. Zwiebelchen

    Zwiebelchen

    Joined:
    Sep 17, 2009
    Messages:
    7,014
    Resources:
    12
    Models:
    5
    Maps:
    1
    Spells:
    1
    Tutorials:
    1
    JASS:
    4
    Resources:
    12
    Why not get your map into playable state first and worry about hundreds of imports you don't even have later?

    Quality, not quantity makes good maps.
     
  10. Chaosy

    Chaosy

    Tutorial Reviewer

    Joined:
    Jun 9, 2011
    Messages:
    11,064
    Resources:
    18
    Icons:
    1
    Maps:
    1
    Spells:
    10
    Tutorials:
    6
    Resources:
    18
  11. Wietlol

    Wietlol

    Joined:
    Aug 1, 2013
    Messages:
    4,638
    Resources:
    3
    Spells:
    3
    Resources:
    3
    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.
     
  12. Chaosy

    Chaosy

    Tutorial Reviewer

    Joined:
    Jun 9, 2011
    Messages:
    11,064
    Resources:
    18
    Icons:
    1
    Maps:
    1
    Spells:
    10
    Tutorials:
    6
    Resources:
    18
    So if you use a skin in a map using the other method you would not have to go and change that between each map?
    (same goes for icons and all textures, unless to reassign the model they are attached to)
     
  13. Wietlol

    Wietlol

    Joined:
    Aug 1, 2013
    Messages:
    4,638
    Resources:
    3
    Spells:
    3
    Resources:
    3
    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.
     
  14. Chaosy

    Chaosy

    Tutorial Reviewer

    Joined:
    Jun 9, 2011
    Messages:
    11,064
    Resources:
    18
    Icons:
    1
    Maps:
    1
    Spells:
    10
    Tutorials:
    6
    Resources:
    18
    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.
     
  15. Wietlol

    Wietlol

    Joined:
    Aug 1, 2013
    Messages:
    4,638
    Resources:
    3
    Spells:
    3
    Resources:
    3
    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.
     
  16. Zwiebelchen

    Zwiebelchen

    Joined:
    Sep 17, 2009
    Messages:
    7,014
    Resources:
    12
    Models:
    5
    Maps:
    1
    Spells:
    1
    Tutorials:
    1
    JASS:
    4
    Resources:
    12
    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.
     
  17. Wietlol

    Wietlol

    Joined:
    Aug 1, 2013
    Messages:
    4,638
    Resources:
    3
    Spells:
    3
    Resources:
    3
    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).
     
  18. Zwiebelchen

    Zwiebelchen

    Joined:
    Sep 17, 2009
    Messages:
    7,014
    Resources:
    12
    Models:
    5
    Maps:
    1
    Spells:
    1
    Tutorials:
    1
    JASS:
    4
    Resources:
    12
    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.
     
  19. oger-lord

    oger-lord

    Joined:
    Jul 24, 2006
    Messages:
    156
    Resources:
    2
    Maps:
    1
    Tutorials:
    1
    Resources:
    2
    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.
     
  20. Zwiebelchen

    Zwiebelchen

    Joined:
    Sep 17, 2009
    Messages:
    7,014
    Resources:
    12
    Models:
    5
    Maps:
    1
    Spells:
    1
    Tutorials:
    1
    JASS:
    4
    Resources:
    12
    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 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.