The behavior way is pretty simple and elegant, but if you want to use triggers there's a couple ways to do it. The methodology is the same behind both.
Pretty much you need a way to detect collisions in the X Y region. You'll want to base your events on what collides. If you're going to have static (non-respawning and on the map since the beginning, like buildings) you can use the event which detects if a unit is in a certain range of a specific unit. I'm not too sure on this event because I didn't use it for my map, but it looked like a possibility.
The other event you can use is a periodic timer that every 0.XX seconds checks for XY collision within a unit group and then checks to see if their Z's (height) are within collision radius. This works well if you have multiple units that die/respawn/get created and want to check their collisions. This is also very similar to the data method Funky mentioned.
As for declaring unit heights you could always use custom values. Each unit pretty much has an array of custom values they can store. So you can make every unit you want to check use the Custom Value [0] = Height of unit.
I brushed over the basics of this and don't have my map editor open, but hopefully this helped.
Change the second parameter to your desired unit type
Change the third parameter to "Collide", so the Scope is Generic (CUnit), the Field is Collide, and the Index represents the # representation of the collide type.
I don't know if it changes per unit type, but it shouldn't. For example #8 = Ground, #1 = Burrow. I found these numbers by going into the Data Editor, finding my unit, opening the Collide reference and numbering them off from top to bottom (burrow is the first option, and ground is the eighth).
Then when it says to "", put either a 0 or 1 in the value. I believe 0 is disabled and 1 is enabled.
After this the code should look like "Set value of Units Reaper Collide[8] for player ( Triggering Player ) to "1""
This makes all Reapers for the triggering player collide with ground. If the 1 were a 0 they would no longer collide with ground.
I'm not completely certain. You can flip through all the catalog options for unit types to see if you can change how LOS works. Honestly I don't deal with data very often so I don't know how LOS works in the first place haha.
I suggest you ditch the morph ability and use catalog values to change movers and collisions. This works especially well if the player is only controlling 1 of the unit since it will change the values for all units of that type for that player, which it looks like you're doing.
Here the unit type Raynor01 is becoming uncollidable with cliffs and... I think force fields? I don't remember, but you can look up the order by looking at collisions in the data editor under the unit. Like what willuwontu said you can do this for movement too.
For my map I also made my units ignore terrain height so that if they flew over a higher cliff they wouldn't automatically fly up with that cliff, but that's because I was dealing with projectiles that were moving in a path.
UnitSetState(u, c_unitStateIgnoreTerrainZ, true);
If you do this you also have to set the unit height to be desired fly height + world height @ point.
Maybe I'm late to say this, but did anyone notice the arcade got its own link on battle.net? http://us.battle.net/arcade/en/
Could this mean Blizzard has plans to make arcade its own client? Especially if their Rock the Cabinet competition goes well.
A rejoin feature in arcade would be amazing.
I would say that learning the sc2 editor is quite the task. Before I started mapping I knew java, vb, and a bit of similar languages. Also knew wc3 mapping quite well. I'd say triggering is easy to pickup even with limited programming knowledge, but the data editor is a task on its own that can take awhile to understand. Unless someone explains the architecture of it, learning it can be difficult even in 100 hours.
0
Chimera
0
Idk if you've figured it out yet, but if you look at this tutorial portions of it will show you how to do this.
0
The behavior way is pretty simple and elegant, but if you want to use triggers there's a couple ways to do it. The methodology is the same behind both.
Pretty much you need a way to detect collisions in the X Y region. You'll want to base your events on what collides. If you're going to have static (non-respawning and on the map since the beginning, like buildings) you can use the event which detects if a unit is in a certain range of a specific unit. I'm not too sure on this event because I didn't use it for my map, but it looked like a possibility.
The other event you can use is a periodic timer that every 0.XX seconds checks for XY collision within a unit group and then checks to see if their Z's (height) are within collision radius. This works well if you have multiple units that die/respawn/get created and want to check their collisions. This is also very similar to the data method Funky mentioned.
As for declaring unit heights you could always use custom values. Each unit pretty much has an array of custom values they can store. So you can make every unit you want to check use the Custom Value [0] = Height of unit.
I brushed over the basics of this and don't have my map editor open, but hopefully this helped.
0
What response are you looking for in the collision? Like, the flying unit takes damage, bounces off, etc.
0
Are you talking about cliffs, units, or doodads?
Because cliffs and units are definitely possible, if you want to put some work into it.
0
@uroboros1987: Go
Use the trigger action "Catalog Field Value Set"
Change the first parameter to "Units"
Change the second parameter to your desired unit type
Change the third parameter to "Collide", so the Scope is Generic (CUnit), the Field is Collide, and the Index represents the # representation of the collide type.
I don't know if it changes per unit type, but it shouldn't. For example #8 = Ground, #1 = Burrow. I found these numbers by going into the Data Editor, finding my unit, opening the Collide reference and numbering them off from top to bottom (burrow is the first option, and ground is the eighth).
Then when it says to "", put either a 0 or 1 in the value. I believe 0 is disabled and 1 is enabled.
After this the code should look like "Set value of Units Reaper Collide[8] for player ( Triggering Player ) to "1""
This makes all Reapers for the triggering player collide with ground. If the 1 were a 0 they would no longer collide with ground.
0
@uroboros1987: Go
I'm not completely certain. You can flip through all the catalog options for unit types to see if you can change how LOS works. Honestly I don't deal with data very often so I don't know how LOS works in the first place haha.
0
I suggest you ditch the morph ability and use catalog values to change movers and collisions. This works especially well if the player is only controlling 1 of the unit since it will change the values for all units of that type for that player, which it looks like you're doing.
Just ripping some code from my old map:
CatalogFieldValueSet(c_gameCatalogUnit, "Raynor01","Collide[1]", UnitGetOwner(u), "0");
CatalogFieldValueSet(c_gameCatalogUnit, "Raynor01","Collide[8]", UnitGetOwner(u), "0");
Here the unit type Raynor01 is becoming uncollidable with cliffs and... I think force fields? I don't remember, but you can look up the order by looking at collisions in the data editor under the unit. Like what willuwontu said you can do this for movement too.
For my map I also made my units ignore terrain height so that if they flew over a higher cliff they wouldn't automatically fly up with that cliff, but that's because I was dealing with projectiles that were moving in a path.
UnitSetState(u, c_unitStateIgnoreTerrainZ, true);
If you do this you also have to set the unit height to be desired fly height + world height @ point.
0
@Batomys: Go
I thought the whole post was a joke, since there's quite a few maps made for this contest.
0
@Bounty_98: Go
I think you should increase the width of the UI even more by placing the orbs on the sides of the bar! That would be so much more sleek.
0
@Necromoni: Go
loooooool no..... maybe
and see if anyone wanted to group up
0
Maybe I'm late to say this, but did anyone notice the arcade got its own link on battle.net? http://us.battle.net/arcade/en/
Could this mean Blizzard has plans to make arcade its own client? Especially if their Rock the Cabinet competition goes well. A rejoin feature in arcade would be amazing.
0
Is anyone in the Alpha / Beta for HotS? ;)
0
Don't give facebook a hotkey. lol.
0
@Mozared: Go
I would say that learning the sc2 editor is quite the task. Before I started mapping I knew java, vb, and a bit of similar languages. Also knew wc3 mapping quite well. I'd say triggering is easy to pickup even with limited programming knowledge, but the data editor is a task on its own that can take awhile to understand. Unless someone explains the architecture of it, learning it can be difficult even in 100 hours.