• 🏆 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!

Resizing Tutorial

Level 19
Joined
Nov 16, 2006
Messages
2,165
<-- Map Resizing Tutorial -->

Resizing?
Yes, in this tutorial I will explain the following things from the editor
which TAKE extra space and can be easly fixed to save plenty of space.

What does this do?
If you are correctly doing what I just showed then your map will be possibly
300-600 kb's smaller, and alot faster with loading.

Why don't we just use a program?
We can use vexorian's optimizer also after optimizing our map, which can
totaly even remove more space ( 1+- mb).

Lets get started!
The first chapter will be the triggers.

-- Triggers --

Now, what is taking space when we use triggers?
First of all : the variables. Each variable created will take a new part of space
in your map, so this will also increase your size and loading time.

Each variable will increase the map its size very slightly, using variables with
arrays will take ofcourse more space.

How can I reduce so much variables taking space?

There are different options here:
- Use only ONE variable which each has the maximum arrays.
For each trigger, use a different array number.
- Use custom scripts with local variables (I will add another tutorial if some don't understand this).
-The third option is to use JASS. JASS doesn't require any(!mostly) variables (when using it
correctly) and increases your map its speed slightly. Since JASS is just a script, it also
doesn't need much space.
Allright, now lets go to the triggers themselves!

Each trigger created will take up space, depenting on how many events/conditions/actions you are using.
An example would be a trigger with 4 actions, those will take lesser space and loading time then
a trigger with 20 actions. Also, try to put useless triggers together since each NEW trigger created will take
extra space and loading time. An example here is using one trigger to setup
the map (set boolean1 = true ,like that), and another trigger to setup the waygates.
Just add the actions in one same trigger, that makes much sense : saving space and reducing the loading time.

------------------------------------------------------------------

-- Objects --

The next part I will discuss : The object editor.
Here are the most mistakes made. I would like to start by the units,
but actualy it doesn't matter where to start since the explanation comes down
on the same.

A thing, that GREATLY reduces the loading time and size is to NOT create custom units!

What should we do then?

Simply edit a standard unit that isn't used in your map.
I'm sure that there are plenty of units which are unused.

I think it doesn't make sense after all...

If you don't believe me, simply create four custom units, save the map and check
the size. Remove them and then check the size. I lost 400kb by removing custom
units.

But now to go on, we come out by the items, destructibles, doodads, abilities, buffs/effects and
upgrades : this is just the same information as above, from the units. Simply edit things you
won't use in your map, and voila! Your map size will be lesser then with custom objects!

-- The map --

Here are some hints to also save space and increasing your loading speed.

-Do not pre-place units, but use a trigger that does it.
-Some doodads like tree's can also be created on the map with a trigger.
I suggest placing some tree's, and then let the trigger automaticly add some.
-Also don't add items manualy, but let a trigger do it. Its very easy, and the
effect stays the same.

> A last hint for placing these objects : use points.
Go stand with your cursor on a location, where the object needs to be created.
Check LEFT down of your world editor : it displays Point: (-3501,4), (2614,6), (0.00).
The ones I displayed are just an examples. But just write down those points or keep
them in minds and then use the [Conversion - Convert Coordinates to Point] option to
create your unit!
BEWARE! This does not mean that it won't leak! Use a variable or
custom script to prevent leaks.
What does this means?
An example of this would be :
  • Actions
    • Set PositionTest = (Point(-500.40, -300.10))
    • Unit - Create 1 Footman for Player 1 (Red) at PositionTest facing 0.00 degrees
    • Custom script: call RemoveLocation(udg_PositionTest)

<Complete your map by using Vexorian's Optimizer>
-> surely even faster now if you already used it!

Thanks for reading this tutorial,
Sorry for my bad english.
!

~- Heero
 
Last edited:
Level 11
Joined
Oct 13, 2005
Messages
233
Fl4meS said:
-Some doodads like tree's can also be created on the map with a trigger.
I suggest placing some tree's, and then let the trigger automaticly add some.
Creating destructables with triggers instead of pre-placing them gives little/no benefit. I have done testing on this with various maps, and found no difference in loading time when removing pre-placed destructables from a map. As for file size, chances are you won't notice a difference in file size.

Just pointing this out so people don't waste their time creating all their destructables with triggers.

Fl4meS said:
-Do not pre-place units, but use a trigger that does it.
Just to let you know, pre-placed units are automatically in the map script. Their positions, however, are saved in a separate file for use with the World Editor only. That specific file is useless, and Vexorian's Optimizer will automatically remove it if you let it.

Fl4meS said:
-Also don't add items manualy, but let a trigger do it. Its very easy, and the
effect stays the same.
I'm pretty sure items are also created with the map script like units are.

Overall the tutorial is very helpful. You should also mention to the user not to edit fields in the object editor that aren't necessary, as when the map is saved, each change is noted. For instance, if you modified a unit's name when that unit would never be selected by a player, additional space would be used (even though it's only a small amount).
 
Last edited:
Level 19
Joined
Nov 16, 2006
Messages
2,165
Creating destructables with triggers instead of pre-placing them gives little/no benefit. I have done testing on this with various maps, and found no difference in loading time when removing pre-placed destructables from a map. As for file size, chances are you won't notice a difference in file size.

Just pointing this out so people don't waste their time creating all their destructables with triggers.

The map always LOADS all destructibles/doodads, u ain't going to tell me that when removing those and placing it with triggers would load also.
Try this : Create a map with 200-300 tree's.
Create a trigger that creates 300 tree's.
Rara ... It will make a BIG difference.. :)
Just to let you know, pre-placed units are automatically in the map script. Their positions, however, are saved in a separate file for use with the World Editor only. That specific file is useless, and Vexorian's Optimizer will automatically remove it if you let it.
And again, I want you to point, that when saving the map with the units, the space will be increased. Placing them with triggers will surely decrease the map its size and speed. Try it :)

Well, thanks for the comments :)
 
Level 11
Joined
Oct 13, 2005
Messages
233
The map always LOADS all destructibles/doodads, u ain't going to tell me that when removing those and placing it with triggers would load also.
Try this : Create a map with 200-300 tree's.
Create a trigger that creates 300 tree's.
Rara ... It will make a BIG difference.. :)

While it may take longer while loading with the world editor, it makes little/no difference in-game. I made a tool to remove all destructables from a .doo file (file containing all pre-placed doodads/destructables). I took the .doo file from a map (had a lot of destructables), ran it through the program (I know it works), and then imported the new .doo file. When loading the file in the world editor, there was a time difference. When loading the game in Wc3 (I loaded it multiple times) there was no time difference. My program also generated a function that when called, would load all the destructables that it had removed. When that function was called (it generated about 1500 destructables) it took no time to run. Conclusion: no difference in loading time, there was a slight (very slight) decrease in loading time. I tried it again on a larger map, and the map file size increased.

Fl4meS said:
And again, I want you to point, that when saving the map with the units, the space will be increased. Placing them with triggers will surely decrease the map its size and speed.
The map script already creates all the units while loading the map (the code is in the map script), but I can agree with you on saving time, but it's not worth it effort-wise.
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,201
The trigger part of this guide is rubish! total rubish!
Jassing triggers makes the map bigger since WEU makes a special jass trigger file that is basicly a copy of the ingame script but with alot of added junk.
Also the same goes for GUI, it makes a inefficent file.
Vexorians optimizer AUTOMATICLY removes all unessary lines and letters and so it is pointless to do so your self as well as it removes all the GUI trigger files and jass trigger files just leaving the main trigger script.
By optimizing globals you can save atmost 1 KB in a really big map, hardly sagnificant.

You can reduce map size by rewriting your GUI triggers with jass and restructuring them more efficently than they could be in GUI but vexorian's optimizer auto removes the if functions generated AND bj calls, so it helps all round for no effort.

Most very large maps are only 1--1.75 MB in size from the actual map, the rest is caused by custom modles/skins, yet you fail to mention you can compress theses and reduce them size wise at minimal cost to their quality using a special program at WC3C, it can reduce models by up to 25% meaning that 25% more models can be added into your map. So adding a custom stuff reduction section would be a better idea than that trigger section that is just a waste of effort to do since vexorians optimizer does it all for you.
 
Level 32
Joined
Oct 23, 2006
Messages
5,291
*bump*

Heero: this tutorial has been sitting for months now. Have you / do you intend to address the Doctor's concerns? I don't think we can approve this in its present state.

Spell Moderators: what other recommendations/suggestions might you have?
 
Level 40
Joined
Dec 14, 2005
Messages
10,532
I agree with Doc about the trigger section

-locals take up more map space than globals (script size-wise)
-good jass uses more variables than GUI, by alot
-GUI is an overlay onto JASS. it's exactly the same (well, with worse functions) script. Convert to Custom Text just shows you what's behind the pretty pictures

Loading speed --

-If you didn't already work it out, units preplaced are created with triggers. It's a part of the generated script (behind the scenes). Customly creating them makes absolutely no difference in the map's size/load speed if you've optimized your map with Vex's Optimizer and write the creation in JASS with x/y
-Since you have to deleak Points in GUI, non-'JASSed with x/y' unit creation takes up more resources (load time) and space (map size) than preplaced (generated) units
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,201
I say this guide would need a total rewrite to be informitave and tell exactly how to reduce map size and loading times so it will probably be better if someone remakes one for scratch unless Heero improves it a lot.

Give him a few days to do something and if nothing is done, bury this.
 
Level 32
Joined
Oct 23, 2006
Messages
5,291
This moderator just sent him a PM and jumped over to Fragments of Life while at it: I'm sure he'll notice now.

[EDIT]

The chat room scuttlebutt:
Code:
[04-47-58]  Heero: u can move it away, I'll finish a better one up later

[04-48-42] Wolverabid: Heero, I'll bury it then, people can always read it in the graveyard.

~ Thread moved.
 
Last edited:
Top