- Joined
- Feb 7, 2006
- Messages
- 14
Things in RED have been edited since first posting this guide
=====================================================
War3 and World Edit Rare Tips: some important lessons ive learned, the hard way. You would do well to read.
=====================================================
-----------------------------------------------------
Introduction
-----------------------------------------------------
In making the labyrinthian complex mass that is Dodgeball Extreme (a job made all the more harder because the skeleton base map wasn't mine, and the code was illogical spagetti) i have run into alot of game-threatening problems with World Edit.
Specifically, game-limiting lack-of-power of the world editor provided by blizzard. Most of the pros here will know it is sadly lacking in many undesirable ways. However it may be a help to warn some of you before hand of some of these lapses, so that you dont waste time with dreamy high hopes before hitting a wall head-on.
This guide is mostly useful for people IN THE CONCEPT STAGE of their maps.
(For anyone who wants to check out DodgeBall Extreme)
http://www.wc3sear.ch/?p=Maps&ID=9289)
-----------------------------------------------------
MAJOR WARNING: While the WorldEdit used to be viewed as an incrediblely clever & easy-to-use program, (by me too) at an advanced level i have found the silver begins to rust. ALOT of the things in the world editor DONT ACTUALLY DO as they say, or at all. The world editor is VERY STUPID, never assume inteligence on its part, with any complicated situations.
-----------------------------------------------------
Always make a small Test Map consisting of you and an enemy computer with start locations.
Then whenever you have a conceptually new piece of code or system, test it first on a micro scale using your little test map.
ALOT of things require lots of other things to be true (instead of automatically doing these things as you would assume it should inteligently do) before they will work.
ALOT of other things only work in a limited fashion, and you will find it partially using default values here and there, and theres no way for you to change this.
SOME of the time, a trigger or unit-property JUST _W_O_N_T_ WORK, AT ALL! There is no way of getting it to work, it might aswell not even be in the WorldEdit.
The game will ONLY allow default values for some things, even though it lies to you on the editor that you can change them.
-----------------------------------------------------
Quick note: to make units for Neutral Passive/hostile/victim/rescuable, make the units for player 1 (red) or someone like that, then select the units and change their Owner properties to Neutral Passive/hostile/victim/rescuable.
-----------------------------------------------------
-----------------------------------------------------
Arrays - they start on 0, ALWAYS remember this
-----------------------------------------------------
player 1 is ArrayYouAreUsing(0), through to player 12 who is ArrayYouAreUsing(11). You might have to have alot of (PlayerNumber - 1)'s in triggers to make up for this.
-----------------------------------------------------
Amount of Text, limits - quest logs and loading screen
-----------------------------------------------------
There is NO OBVIOUS WARNING of text limits on quest logs or the loading screen, but in-game when you test it will harshly cut of the bottom of the loading screen after a certain point, and the TOP of the quest log after a certain size. The loading screen text-allowance is exactly the size of the text box you enter it, WITHOUT the slider appearing (there is small gap at bottom you need to sliderize your window to access, this is cut off) The quest log is pretty massive, but dont get hopes of putting an encyclopedia in any individual quest log.
Also: your map title + sub comment is quite short, often you can only fit ONE colour code in, unless you have a very short map name. (Hence why you dont see rainbow names)
-----------------------------------------------------
Camera boundary limits - Dont make cinematics take place near the edge of your map, although heres how if you really want to anyway:
-----------------------------------------------------
Sometimes you dont even have to be near the edge to encounter "Cannot creat camera - outside camera limits". The target of the camera must be inside the camera boundaries (which can be increased by you if you in the properties screen).
A camera targetting a point outside the boundary can be SIMULATED by a camera targetting a point near the edge, and then lifted on the Z co-ordinate. Its a long winded trial-and-error to get it to face the right place at the right height, but its possible.
Side Note on cameras: The war3 UI always cuts of 25% of the bottom and 10% of the top of the screen, always zoom a little further out than neccessary to fit everything in.
-----------------------------------------------------
applying Camera objects - forced pans, user cannot stop this, even if they dont wish it. plan for it.
-----------------------------------------------------
When you apply a camera object (dont do "without pan" btw, this is basically the same as you not even having the trigger, might aswell delete the camera too ;<) it will pan from the currect camera in a very round-the-houses way. It will NOT just go directly in a straight line to the other camera, while simply rotating at a constant speed. It WILL NOT do this and there is no way to make it do this.
Applying all cameras causes atleast a SLIGHT (inteligently decided) arc by war3, an arc which is followed by the camera as it goes to the new camera position you want. If the 2 cameras are close, often this arc is near non existant; but if the cameras are further away, or have MOST IMPORTANTLY: Wildly different angles, it will do a massive rotating arc WITHOUT YOU ASKING. Be warned
-----------------------------------------------------
Cinematics - Wait commands are the glue and cement of cinematic sequences.
-----------------------------------------------------
cameras get instantly overwritten by other cameras unless you give them time to play out with a Wait of the same length.
Also you will have to use (Pick Every Player) and (Apply camera object for Picked Player) every time you want to do a camera for everyone... its just one of those things.
-----------------------------------------------------
Misc - cameras
-----------------------------------------------------
You cannot directly access the X, Y, or Z of the source (or even target) of one of your cameras, either to state them for your information, or as a value to use in a trigger. You have to be in-game, and have the current view set to that camera, and THEN ask for the CurrentCamera(X,Y,Z).
-----------------------------------------------------
Flying Units & Varying movement/unit HEIGHT mid-game
-----------------------------------------------------
Only flying units can have their height varied mid-game (Animations - Flying Height). The rate value has to be pretty high btw, otherwise its helluva slow.
Non-flying units can move around really high when you set the unit property (Movement Height) in the world editor, but its PERMINENTLY SET from start-to-finish of the game.
WARNING about flying units: It is an undocumented world edit flaw to NOT ALLOW the (Animation - Elevation sample radius) UNIT PROPERTY to be changed on flying units.
EVEN if you pre-set it in the Unit Editor, and god forbid you try to change it mid game.
Flying units have a PERMINENTLY SET default elevation sample radius, yes i realise there is the option to change it in the unit properties, but it wont work, it might aswell not be there.
Example: Gryphons are the same as Frost Wyrms! Even though blizzard have cleary set them different values, as you can see on the world editor, but both units have exactly the same elevation sample radius in-game.
What this means:
Flying units will always PRE-EMPTIVELY increse their flying height when near a bit of higher ground, EVEN THOUGH they are on the lower ground. this can badly screw up complicated flying-height-changing triggers. Note: they will technically still have the same "flying height" as when the higher ground was not near, but the ground itself effectively "moved up" for them. Thus any height changing triggers would stack on the top of the already rising ground.
A good example of this automatic un-asked pre-emptive flying height changing, but being abused to achieve a positive desired effect, is Dodgeball. You know how the balls seem to bounch up a bit when they hit the edges? Looks good/realistic doesnt it. Thats because when they reach the edge, higher terrain enters their elevation sample radius, and they pre-emptively raise themselves up a bit.
DO NOT have complex flying and height-changing cinematics take place anywhere near higher ground, even a little one-map-square bump. Have a healthy portion of flat plateau all around the cinematic area
-----------------------------------------------------
Of movement types and collision/clipping:
-----------------------------------------------------
Flying units can fly anywhere within the map boundaries (note this is "Boundary, which you can place like tiles, not the physical edge of map borders) regardless of how high or how many levels the terrain has.
Foot/Horse&Hover units are exactly the same as flying units, except they cannot get past changes in terrain level (cliffs) and they cannot go on sea.
Floating units are sea-only. They collide with anything sticking up from the sea, and cannot sail where there is something removing the sea (such as a bump) even if the terrain level is technically still "sea".
Amphibious units are naga, they get out of the sea and walk on land, or go back into the sea for a cool dip. they collide with terrain level changes (such as cliffs) and so need ramps or other continuous terrain like foot&hover do.
Foot/Horse&Hover&Amphibious&Flying are NOT effected by higher terrain if it isn't a change in terrain level, so massive hills/bumps are fully pathable.
Floating units ARE effected by pulling up a bump in the terrain, IF that bump sticks up above the sea. Ever seen a ship sail on grass?
NONE: ill talk about this a bit further down, its important.
Ground pathing blockers - blocks foot/horse&hover&hibious&floating units, but not flying.
Flying pathing blockers - blocks flying units, but not
foot/horse&hover&hibious&floating.
Unit Property - Collision Size
While a very small collision size means the unit can get really CLOSE to stuff, and visa versa, it isnt as powerful as you might think. Setting collision size to 0.00 IS NOT the same as turning its collision "off".
Even with 0.00 collision size, there is still a single pixel of collision the unit has, which can never be removed. This means that other units will only be able to get as close as their own collision size to it, and it will only be able to go where it normally could anyway, except it will get a bit closer than usual.
Trigger - Turn collision OFF
This really DOES make the collision 0.000, meaning the unit doesn't collide with anything, not even cliffs. Floating boats can sail up cliffs and onto land!
HOWEVER, other units with collision will still collide with IT, inconveniencing the 2nd unit, but not the 0 collision unit.
WARNING: CRITICAL AI FLAW. While a unit may have its collision turned off, it will not always make use of this. Ground units especially will still think they have collision in respect to SOME things, on the first move-to order, and path themselves around terrain-level changes. on the SECOND move-to command, while they are still trying to complete the first, will give the AI a jolt of REALISATION, and the ai will then path in a straight line through terrain-level changes.
The same AI flaw occurs with pathing blockers. Collision OFF units CAN go through their movement-type pathing blockers (i.e. footman can go through ground-blockers, gryphones through air blockers), BUT it still takes the 2 orders to overcome the AI flaw and actually go through the pathing blockers, as with cliffs.
Units with collision off can also path through map boundaries (the blacked out bits usually found at the edges of the map, but can be tiled anywhere), and without AI flaw ;D *shock*
Movement Type : NONE
This is a very special and rather powerful movement type.
Firstly, NONE movement type units have NO COLLISION, exactly the same as if they had had it turned off. This includes casually waltzing through terrain-level changes and map boundaries. Furthermore:
They dont have any AI flaws, (unlike Ground unit's which have had their collision turned off later in life, but still sometimes think they are ground units), if you tell a NONE-movement-type unit to walk through a mountain it will do it straight away.
Also no pathing blockers can block NONE movement types, and there are no AI flaws with them walking through said blockers.
Crucially, NONE movement types also have this power:
OTHER UNITS WITH COLLISION DO NOT GET INCONVENIENCED BY THEM. its the same as if every unit which tries to go through a NONE-movement-type unit, gains collision off temporarily themselves too. With conventional Collision OFF for a unit, other units would still treat them like they had collision, where as when a unit is a NONE-movement-type, other units treat them as if they aren't even there. So its far more powerful.
If a unit has NONE movement type, its collision size unit property is irrelevant, and doesn't do anything. Also using a trigger to turn a NONE movement type's collision OFF will not gain it any further powers, in any way shape or form, NEITHER will it lose it any powers.
-----------------------------------------------------
Misc - weather and terrain tips
-----------------------------------------------------
While weathers such as rain and fog over regions, they wont always exactly fit the region, as they have undivisible animation tiles, and if you even have a little bit of an edge of a tile included in your region, the entire tile will have to play its weather animation!
Note: The same kind of indivisible tiling happens to big images you place on the terrain of your map.
The "perminent" crator terrain deformation, cannot be reset back to normal with "stop all terrain deformations" or "stop specific deformation" or anything else for that matter. It can be undone with an exactly opposite crator deformation, to deform the terrain 'back into shape'. after a certain point, if a crator gets deep enough, it will perminently mess up the appearence of the terrain in-game, even if you undeform it back to normal. This can be highly amusing. If a unit walks deep enough into a crator it can also sometimes crash the game ^_^
Note: flying units ignore deformed terrain, meaning they will be hidden inside a mountain, or floating above an abyss.
-----------------------------------------------------
Misc - Multiboards
-----------------------------------------------------
These things are really lame. Theres so many silly little things you have to do to get them to work. And yet they are important to use, so get learning!
Multiboards are the only boards which minimise.
Leaderboards do NOT minimise, ever.
On the flip-side, leaderboards can easily be sorted into an order, where as it is next to impossible to sort a multiboard into an order (unless you have ALOT of time on your hands)
Your call, but if your leaderboard is big, it's non-minimising click-stopping ugly mass may drive your players away in annoyance.
-----------------------------------------------------
Don't give a non-hero-reincarnate to a hero, it wont work properly.
-----------------------------------------------------
At the very least a trigger detecting final-death will falsely detect a hero has died without ability to res, even if it does have the ability and is reincarnating.
You should give the hero version of reincarnate to hero units, then everything will work properly. The unit wont be reported as "killed" or "dead" until it has been killed for a 2nd time, while its hero reincarnate is on cooldown.
-----------------------------------------------------
Trying to play specific unit animations - dont bother
-----------------------------------------------------
it doesnt work
If you set a rexxar to use Spell Slam animation when casting a non-slam spell (in WorldEdit unit properties), it will still use his non-slam spell animation. Its like trying to getting blood out of a stone.
Same with trying to play units rare-stand animations, they will just stand there looking gaumless, ESPECIALLY if they know they are in a cinematic.
-----------------------------------------------------
Moving regions in-game, and centering a detection area on a moving unit/object
-----------------------------------------------------
I had to find this out the hard way, when i added dodge detection to dodgeball extreme:
THE MOVE REGION TRIGGER DOES _N_O_T_ WORK.
its as simple as that.
The closest thing to a moving region, centered on something, is to simulate it with a similar trigger.
The (BlahDeBlah comes within -range- of -unit-) trigger is your best bet, if not your only salvation.
However there is a major lack-of-power flaw with this, you can only have the -unit- equal to a pre-existing unit on game-load, i.e. one ready-placed and not a newely created one. There is no way around this im afraid.
Thus for the dodge detection on my map, i have pre-existing units which have the 'within-range region' centered on them, which then FOLLOW the newly-created hero units of the players around
As for the proximity checking of the balls hitting the players, that is currently using a lag-heavy every-0.005-seconds method to individually check every player and every ball... if i changed this to the lag-free method in the previous paragraph (where there are no regular checks, it just procs WHEN a ball gets near enough), player death would be too unreliable. Alas, blizzard suck.
-----------------------------------------------------
Build up of PC LAG, "Every 0.05 or 0.01 seconds of game time" events - blizzard's memory leaks in war3. (badly effect even 512mb RAM users)
-----------------------------------------------------
If you have to repeatedly remove and create new units, or order alot of existing ones to move (either by order or instantly), at the same time, every 0.05 seconds or less; the small memory leaks of war3 will build up slowly, filling up the users RAM with useless data.
The more RAM the user has, the less the effect and the longer he can continue without it negatively effecting his game.
HOWEVER 5 frames/per/second can suddenly come out-of-the-blue and aflict a user, so i have this advice for everyone:
At the INITIAL CONCEPT STAGE of your game, avoid a situation where you have to do alot of things every 0.05 seconds or 0.01 seconds. Also DON'T get your hopes up of 12-player being playable. Perhaps make your game with 6 people max.
For a good example of how PC lag can build up, you should try playing dodgeball extreme past round 6 with only 512MB of RAM. Even if your the host you'll start getting big delays, and come round 8 your frames/per/second will start going down, till you cant even control your character in round 9. Perhaps this is just my computer, but people with better computers are still effected to a lesser extent.
-----------------------------------------------------
Internet Lag : Only the host (you) will ever have a playable game, everyone else will have delay depending on the number of players.
-----------------------------------------------------
Always GET SOMEONE ELSE to host your map, at an EARLY STAGE of map creation, so YOU can experience what its like to play as a normal player with delay. Try to fill the game with max users too. When you are making your game, make allowance for the fact that everyone except Red will have 0.5 to 1 second delay.
-----------------------------------------------------
Imported Sounds - reduced play quality, and sometimes dont work at all
-----------------------------------------------------
War3 usually (but not always) plays an imported sound in a lower quality than it is, even if it has the full-quality sound successfully embedded the map.
This doesn't always happen, but seems to happen most with mp3's. There are some mp3's which it wont happen with, and alot of .wavs. I dont know why this is, all i know is there are alot of different types and settings when creating an mp3, and most of them war3 doesn't like.
Some mp3's and even .wavs dont play at all. A funny example is making war3's own TFT Human01.mp3, a usable map sound object (which you have to do with every sound before you play it), and then trying to play it. It doesn't matter what sound-type or settings you make the sound object, human01.mp3 just WONT play, under any circumstance... although it plays fine if the game automatically chooses&plays it as the in-game music.
Just one of those things i guess.
-----------------------------------------------------
Bug testing is easiest if you don't have any bugs...
-----------------------------------------------------
I avoid most of my bugs by doing it right the first time, use your imagination ALOT every time you add ANY CODE, think how various things are integrated and imagine every possible knock-on-effect everywhere. Always think alot before you make a map, and frequently during.
Finding bugs during testing can often be INFINITELY HARDER and take WAY MORE TIME than having spent that extra bit of time in the first place, when you made it. Sometimes you wont even know there is a bug for a very long time, until in a rare set of circumstances, when it bites you HARD on the arse.
An example of this being the dodgeball extreme 1.12c patch i had to wheel out after only 5 hours of 1.12b being online. I had forgotten that while most of the OnSelectingAHero functions occured through a discriminating trigger which only accepts HeroSelectors (a unit), the setting of team lives was still handled by an old trigger left over from the skeleton map, and this did not discriminate between players and units.
-----------------------------------------------------
...and Finally
-----------------------------------------------------
Expect to be disapointed, there are lots of power-limiting things ive forgotten to add, or simply dont know about; there are lots of easily tripped-over bugs too. If you run into a wall, dont give up at first, but be prepared to give up eventually
(c)2006 Leon_the_Great@Northrend
=====================================================
War3 and World Edit Rare Tips: some important lessons ive learned, the hard way. You would do well to read.
=====================================================
-----------------------------------------------------
Introduction
-----------------------------------------------------
In making the labyrinthian complex mass that is Dodgeball Extreme (a job made all the more harder because the skeleton base map wasn't mine, and the code was illogical spagetti) i have run into alot of game-threatening problems with World Edit.
Specifically, game-limiting lack-of-power of the world editor provided by blizzard. Most of the pros here will know it is sadly lacking in many undesirable ways. However it may be a help to warn some of you before hand of some of these lapses, so that you dont waste time with dreamy high hopes before hitting a wall head-on.
This guide is mostly useful for people IN THE CONCEPT STAGE of their maps.
(For anyone who wants to check out DodgeBall Extreme)
http://www.wc3sear.ch/?p=Maps&ID=9289)
-----------------------------------------------------
MAJOR WARNING: While the WorldEdit used to be viewed as an incrediblely clever & easy-to-use program, (by me too) at an advanced level i have found the silver begins to rust. ALOT of the things in the world editor DONT ACTUALLY DO as they say, or at all. The world editor is VERY STUPID, never assume inteligence on its part, with any complicated situations.
-----------------------------------------------------
Always make a small Test Map consisting of you and an enemy computer with start locations.
Then whenever you have a conceptually new piece of code or system, test it first on a micro scale using your little test map.
ALOT of things require lots of other things to be true (instead of automatically doing these things as you would assume it should inteligently do) before they will work.
ALOT of other things only work in a limited fashion, and you will find it partially using default values here and there, and theres no way for you to change this.
SOME of the time, a trigger or unit-property JUST _W_O_N_T_ WORK, AT ALL! There is no way of getting it to work, it might aswell not even be in the WorldEdit.
The game will ONLY allow default values for some things, even though it lies to you on the editor that you can change them.
-----------------------------------------------------
Quick note: to make units for Neutral Passive/hostile/victim/rescuable, make the units for player 1 (red) or someone like that, then select the units and change their Owner properties to Neutral Passive/hostile/victim/rescuable.
-----------------------------------------------------
-----------------------------------------------------
Arrays - they start on 0, ALWAYS remember this
-----------------------------------------------------
player 1 is ArrayYouAreUsing(0), through to player 12 who is ArrayYouAreUsing(11). You might have to have alot of (PlayerNumber - 1)'s in triggers to make up for this.
-----------------------------------------------------
Amount of Text, limits - quest logs and loading screen
-----------------------------------------------------
There is NO OBVIOUS WARNING of text limits on quest logs or the loading screen, but in-game when you test it will harshly cut of the bottom of the loading screen after a certain point, and the TOP of the quest log after a certain size. The loading screen text-allowance is exactly the size of the text box you enter it, WITHOUT the slider appearing (there is small gap at bottom you need to sliderize your window to access, this is cut off) The quest log is pretty massive, but dont get hopes of putting an encyclopedia in any individual quest log.
Also: your map title + sub comment is quite short, often you can only fit ONE colour code in, unless you have a very short map name. (Hence why you dont see rainbow names)
-----------------------------------------------------
Camera boundary limits - Dont make cinematics take place near the edge of your map, although heres how if you really want to anyway:
-----------------------------------------------------
Sometimes you dont even have to be near the edge to encounter "Cannot creat camera - outside camera limits". The target of the camera must be inside the camera boundaries (which can be increased by you if you in the properties screen).
A camera targetting a point outside the boundary can be SIMULATED by a camera targetting a point near the edge, and then lifted on the Z co-ordinate. Its a long winded trial-and-error to get it to face the right place at the right height, but its possible.
Side Note on cameras: The war3 UI always cuts of 25% of the bottom and 10% of the top of the screen, always zoom a little further out than neccessary to fit everything in.
-----------------------------------------------------
applying Camera objects - forced pans, user cannot stop this, even if they dont wish it. plan for it.
-----------------------------------------------------
When you apply a camera object (dont do "without pan" btw, this is basically the same as you not even having the trigger, might aswell delete the camera too ;<) it will pan from the currect camera in a very round-the-houses way. It will NOT just go directly in a straight line to the other camera, while simply rotating at a constant speed. It WILL NOT do this and there is no way to make it do this.
Applying all cameras causes atleast a SLIGHT (inteligently decided) arc by war3, an arc which is followed by the camera as it goes to the new camera position you want. If the 2 cameras are close, often this arc is near non existant; but if the cameras are further away, or have MOST IMPORTANTLY: Wildly different angles, it will do a massive rotating arc WITHOUT YOU ASKING. Be warned
-----------------------------------------------------
Cinematics - Wait commands are the glue and cement of cinematic sequences.
-----------------------------------------------------
cameras get instantly overwritten by other cameras unless you give them time to play out with a Wait of the same length.
Also you will have to use (Pick Every Player) and (Apply camera object for Picked Player) every time you want to do a camera for everyone... its just one of those things.
-----------------------------------------------------
Misc - cameras
-----------------------------------------------------
You cannot directly access the X, Y, or Z of the source (or even target) of one of your cameras, either to state them for your information, or as a value to use in a trigger. You have to be in-game, and have the current view set to that camera, and THEN ask for the CurrentCamera(X,Y,Z).
-----------------------------------------------------
Flying Units & Varying movement/unit HEIGHT mid-game
-----------------------------------------------------
Only flying units can have their height varied mid-game (Animations - Flying Height). The rate value has to be pretty high btw, otherwise its helluva slow.
Non-flying units can move around really high when you set the unit property (Movement Height) in the world editor, but its PERMINENTLY SET from start-to-finish of the game.
WARNING about flying units: It is an undocumented world edit flaw to NOT ALLOW the (Animation - Elevation sample radius) UNIT PROPERTY to be changed on flying units.
EVEN if you pre-set it in the Unit Editor, and god forbid you try to change it mid game.
Flying units have a PERMINENTLY SET default elevation sample radius, yes i realise there is the option to change it in the unit properties, but it wont work, it might aswell not be there.
Example: Gryphons are the same as Frost Wyrms! Even though blizzard have cleary set them different values, as you can see on the world editor, but both units have exactly the same elevation sample radius in-game.
What this means:
Flying units will always PRE-EMPTIVELY increse their flying height when near a bit of higher ground, EVEN THOUGH they are on the lower ground. this can badly screw up complicated flying-height-changing triggers. Note: they will technically still have the same "flying height" as when the higher ground was not near, but the ground itself effectively "moved up" for them. Thus any height changing triggers would stack on the top of the already rising ground.
A good example of this automatic un-asked pre-emptive flying height changing, but being abused to achieve a positive desired effect, is Dodgeball. You know how the balls seem to bounch up a bit when they hit the edges? Looks good/realistic doesnt it. Thats because when they reach the edge, higher terrain enters their elevation sample radius, and they pre-emptively raise themselves up a bit.
DO NOT have complex flying and height-changing cinematics take place anywhere near higher ground, even a little one-map-square bump. Have a healthy portion of flat plateau all around the cinematic area
-----------------------------------------------------
Of movement types and collision/clipping:
-----------------------------------------------------
Flying units can fly anywhere within the map boundaries (note this is "Boundary, which you can place like tiles, not the physical edge of map borders) regardless of how high or how many levels the terrain has.
Foot/Horse&Hover units are exactly the same as flying units, except they cannot get past changes in terrain level (cliffs) and they cannot go on sea.
Floating units are sea-only. They collide with anything sticking up from the sea, and cannot sail where there is something removing the sea (such as a bump) even if the terrain level is technically still "sea".
Amphibious units are naga, they get out of the sea and walk on land, or go back into the sea for a cool dip. they collide with terrain level changes (such as cliffs) and so need ramps or other continuous terrain like foot&hover do.
Foot/Horse&Hover&Amphibious&Flying are NOT effected by higher terrain if it isn't a change in terrain level, so massive hills/bumps are fully pathable.
Floating units ARE effected by pulling up a bump in the terrain, IF that bump sticks up above the sea. Ever seen a ship sail on grass?
NONE: ill talk about this a bit further down, its important.
Ground pathing blockers - blocks foot/horse&hover&hibious&floating units, but not flying.
Flying pathing blockers - blocks flying units, but not
foot/horse&hover&hibious&floating.
Unit Property - Collision Size
While a very small collision size means the unit can get really CLOSE to stuff, and visa versa, it isnt as powerful as you might think. Setting collision size to 0.00 IS NOT the same as turning its collision "off".
Even with 0.00 collision size, there is still a single pixel of collision the unit has, which can never be removed. This means that other units will only be able to get as close as their own collision size to it, and it will only be able to go where it normally could anyway, except it will get a bit closer than usual.
Trigger - Turn collision OFF
This really DOES make the collision 0.000, meaning the unit doesn't collide with anything, not even cliffs. Floating boats can sail up cliffs and onto land!
HOWEVER, other units with collision will still collide with IT, inconveniencing the 2nd unit, but not the 0 collision unit.
WARNING: CRITICAL AI FLAW. While a unit may have its collision turned off, it will not always make use of this. Ground units especially will still think they have collision in respect to SOME things, on the first move-to order, and path themselves around terrain-level changes. on the SECOND move-to command, while they are still trying to complete the first, will give the AI a jolt of REALISATION, and the ai will then path in a straight line through terrain-level changes.
The same AI flaw occurs with pathing blockers. Collision OFF units CAN go through their movement-type pathing blockers (i.e. footman can go through ground-blockers, gryphones through air blockers), BUT it still takes the 2 orders to overcome the AI flaw and actually go through the pathing blockers, as with cliffs.
Units with collision off can also path through map boundaries (the blacked out bits usually found at the edges of the map, but can be tiled anywhere), and without AI flaw ;D *shock*
Movement Type : NONE
This is a very special and rather powerful movement type.
Firstly, NONE movement type units have NO COLLISION, exactly the same as if they had had it turned off. This includes casually waltzing through terrain-level changes and map boundaries. Furthermore:
They dont have any AI flaws, (unlike Ground unit's which have had their collision turned off later in life, but still sometimes think they are ground units), if you tell a NONE-movement-type unit to walk through a mountain it will do it straight away.
Also no pathing blockers can block NONE movement types, and there are no AI flaws with them walking through said blockers.
Crucially, NONE movement types also have this power:
OTHER UNITS WITH COLLISION DO NOT GET INCONVENIENCED BY THEM. its the same as if every unit which tries to go through a NONE-movement-type unit, gains collision off temporarily themselves too. With conventional Collision OFF for a unit, other units would still treat them like they had collision, where as when a unit is a NONE-movement-type, other units treat them as if they aren't even there. So its far more powerful.
If a unit has NONE movement type, its collision size unit property is irrelevant, and doesn't do anything. Also using a trigger to turn a NONE movement type's collision OFF will not gain it any further powers, in any way shape or form, NEITHER will it lose it any powers.
-----------------------------------------------------
Misc - weather and terrain tips
-----------------------------------------------------
While weathers such as rain and fog over regions, they wont always exactly fit the region, as they have undivisible animation tiles, and if you even have a little bit of an edge of a tile included in your region, the entire tile will have to play its weather animation!
Note: The same kind of indivisible tiling happens to big images you place on the terrain of your map.
The "perminent" crator terrain deformation, cannot be reset back to normal with "stop all terrain deformations" or "stop specific deformation" or anything else for that matter. It can be undone with an exactly opposite crator deformation, to deform the terrain 'back into shape'. after a certain point, if a crator gets deep enough, it will perminently mess up the appearence of the terrain in-game, even if you undeform it back to normal. This can be highly amusing. If a unit walks deep enough into a crator it can also sometimes crash the game ^_^
Note: flying units ignore deformed terrain, meaning they will be hidden inside a mountain, or floating above an abyss.
-----------------------------------------------------
Misc - Multiboards
-----------------------------------------------------
These things are really lame. Theres so many silly little things you have to do to get them to work. And yet they are important to use, so get learning!
Multiboards are the only boards which minimise.
Leaderboards do NOT minimise, ever.
On the flip-side, leaderboards can easily be sorted into an order, where as it is next to impossible to sort a multiboard into an order (unless you have ALOT of time on your hands)
Your call, but if your leaderboard is big, it's non-minimising click-stopping ugly mass may drive your players away in annoyance.
-----------------------------------------------------
Don't give a non-hero-reincarnate to a hero, it wont work properly.
-----------------------------------------------------
At the very least a trigger detecting final-death will falsely detect a hero has died without ability to res, even if it does have the ability and is reincarnating.
You should give the hero version of reincarnate to hero units, then everything will work properly. The unit wont be reported as "killed" or "dead" until it has been killed for a 2nd time, while its hero reincarnate is on cooldown.
-----------------------------------------------------
Trying to play specific unit animations - dont bother
-----------------------------------------------------
it doesnt work
If you set a rexxar to use Spell Slam animation when casting a non-slam spell (in WorldEdit unit properties), it will still use his non-slam spell animation. Its like trying to getting blood out of a stone.
Same with trying to play units rare-stand animations, they will just stand there looking gaumless, ESPECIALLY if they know they are in a cinematic.
Waldbär said:-specific animations
Using the normal GUI function, it does not work, you're right. But it actually does using the custom script action SetUnitAnimationByIndex. To use it just make a custom script line and enter:
You have to find out the unit's custom script name by converting a simple trigger with it to custom text and and the number by try and error, but this works perfectly, it will never play the false animation!Code:call SetUnitAnimationByIndex( unit, number )
-----------------------------------------------------
Moving regions in-game, and centering a detection area on a moving unit/object
-----------------------------------------------------
I had to find this out the hard way, when i added dodge detection to dodgeball extreme:
THE MOVE REGION TRIGGER DOES _N_O_T_ WORK.
its as simple as that.
The closest thing to a moving region, centered on something, is to simulate it with a similar trigger.
The (BlahDeBlah comes within -range- of -unit-) trigger is your best bet, if not your only salvation.
However there is a major lack-of-power flaw with this, you can only have the -unit- equal to a pre-existing unit on game-load, i.e. one ready-placed and not a newely created one. There is no way around this im afraid.
Thus for the dodge detection on my map, i have pre-existing units which have the 'within-range region' centered on them, which then FOLLOW the newly-created hero units of the players around
As for the proximity checking of the balls hitting the players, that is currently using a lag-heavy every-0.005-seconds method to individually check every player and every ball... if i changed this to the lag-free method in the previous paragraph (where there are no regular checks, it just procs WHEN a ball gets near enough), player death would be too unreliable. Alas, blizzard suck.
-----------------------------------------------------
Build up of PC LAG, "Every 0.05 or 0.01 seconds of game time" events - blizzard's memory leaks in war3. (badly effect even 512mb RAM users)
-----------------------------------------------------
If you have to repeatedly remove and create new units, or order alot of existing ones to move (either by order or instantly), at the same time, every 0.05 seconds or less; the small memory leaks of war3 will build up slowly, filling up the users RAM with useless data.
The more RAM the user has, the less the effect and the longer he can continue without it negatively effecting his game.
HOWEVER 5 frames/per/second can suddenly come out-of-the-blue and aflict a user, so i have this advice for everyone:
At the INITIAL CONCEPT STAGE of your game, avoid a situation where you have to do alot of things every 0.05 seconds or 0.01 seconds. Also DON'T get your hopes up of 12-player being playable. Perhaps make your game with 6 people max.
For a good example of how PC lag can build up, you should try playing dodgeball extreme past round 6 with only 512MB of RAM. Even if your the host you'll start getting big delays, and come round 8 your frames/per/second will start going down, till you cant even control your character in round 9. Perhaps this is just my computer, but people with better computers are still effected to a lesser extent.
-----------------------------------------------------
Internet Lag : Only the host (you) will ever have a playable game, everyone else will have delay depending on the number of players.
-----------------------------------------------------
Always GET SOMEONE ELSE to host your map, at an EARLY STAGE of map creation, so YOU can experience what its like to play as a normal player with delay. Try to fill the game with max users too. When you are making your game, make allowance for the fact that everyone except Red will have 0.5 to 1 second delay.
-----------------------------------------------------
Imported Sounds - reduced play quality, and sometimes dont work at all
-----------------------------------------------------
War3 usually (but not always) plays an imported sound in a lower quality than it is, even if it has the full-quality sound successfully embedded the map.
This doesn't always happen, but seems to happen most with mp3's. There are some mp3's which it wont happen with, and alot of .wavs. I dont know why this is, all i know is there are alot of different types and settings when creating an mp3, and most of them war3 doesn't like.
Some mp3's and even .wavs dont play at all. A funny example is making war3's own TFT Human01.mp3, a usable map sound object (which you have to do with every sound before you play it), and then trying to play it. It doesn't matter what sound-type or settings you make the sound object, human01.mp3 just WONT play, under any circumstance... although it plays fine if the game automatically chooses&plays it as the in-game music.
Just one of those things i guess.
-----------------------------------------------------
Bug testing is easiest if you don't have any bugs...
-----------------------------------------------------
I avoid most of my bugs by doing it right the first time, use your imagination ALOT every time you add ANY CODE, think how various things are integrated and imagine every possible knock-on-effect everywhere. Always think alot before you make a map, and frequently during.
Finding bugs during testing can often be INFINITELY HARDER and take WAY MORE TIME than having spent that extra bit of time in the first place, when you made it. Sometimes you wont even know there is a bug for a very long time, until in a rare set of circumstances, when it bites you HARD on the arse.
An example of this being the dodgeball extreme 1.12c patch i had to wheel out after only 5 hours of 1.12b being online. I had forgotten that while most of the OnSelectingAHero functions occured through a discriminating trigger which only accepts HeroSelectors (a unit), the setting of team lives was still handled by an old trigger left over from the skeleton map, and this did not discriminate between players and units.
-----------------------------------------------------
...and Finally
-----------------------------------------------------
Expect to be disapointed, there are lots of power-limiting things ive forgotten to add, or simply dont know about; there are lots of easily tripped-over bugs too. If you run into a wall, dont give up at first, but be prepared to give up eventually
(c)2006 Leon_the_Great@Northrend
![Dreadnought[dA]](/data/avatars/s/134/134647.jpg?1465504677){kind=avatar}