Creating the same unit, with result of different heights

[TwoVenomous]

Hello Everyone, i'm facing a problem when creating units, i created them with the same actions but they were created in different heights even though they're the same units. This is the trigger that do these things :

• Unit - Create 1 (Unit-type of (Triggering unit)) for (Owner of (Triggering unit)) at Line[5] facing 0.00 degrees
• Unit - Create 1 Progress Bar for Player 12 (Brown) at Line[5] facing Default building facing degrees
• Unit - Create 1 (Unit-type of (Triggering unit)) for (Owner of (Triggering unit)) at Line[6] facing 0.00 degrees
• Unit - Create 1 Progress Bar for Player 12 (Brown) at Line[6] facing Default building facing degrees
• Unit - Create 1 (Unit-type of (Triggering unit)) for (Owner of (Triggering unit)) at Line[7] facing 0.00 degrees
• Unit - Create 1 Progress Bar for Player 12 (Brown) at Line[7] facing Default building facing degrees

The unit is a dummy unit (Locust, Invulnerable, with a height of 150 and a movement type of Fly).

and this is the result i got :

 

[Kusanagi Kuro]

What is the Line[a] Variable?

 

[Hashjie]

Why not set the movement type to none or foot and use the crowform bug to create them on the same flying height?

 

[TwoVenomous]

What is the Line[a] Variable?

it's a Point Variables

and i set it like this :

• Set Line[5] = (Center of First Line <gen>)
• Set Line[6] = (Center of Second Line <gen>)
• Set Line[7] = (Center of Third Line <gen>)
• Set Line[8] = (Center of Fourth Line <gen>)

but it doesn't matter at all.

Why not set the movement type to none or foot and use the crowform bug to create them on the same flying height?

i will try this, wait up..

EDIT : it worked. thanks a lot, Hashjie. +rep to all.

 

[Hashjie]

When the movement type is foot or none the flying height is not taking the terrain height into account when using the crowform bug.
Flying movement type always takes the terrain height into account. Hence why a flying unit will move up a hill instead of staying on the same flying height.

 

[TwoVenomous]

When the movement type is foot or none the flying height is not taking the terrain height into account when using the crowform bug.
Flying movement type always takes the terrain height into account. Hence why a flying unit will move up a hill instead of staying on the same flying height.

but, as the screenshot showed, the terrain for the two in right are on the same height, why they weren't placed with proper heights ?

 

[Hashjie]

but, as the screenshot showed, the terrain for the two in right are on the same height, why they weren't placed with proper heights ?

That is a good question.
Perhaps the collision size of the flying unit is big and therefore takes the cliff into account?
I have no idea why, but apparently it does seem to work when using movement type none or foot, so it must have something to do with the terrain (I think).
You could test it out by checking what the z height of the terrain is on the location of the flying unit with a custom script line:

set udg_z_height = GetLocationZ(udg_your_loc)

Where your_loc is a point variable and z_height is a real variable.

 

[rulerofiron99]

It's based on occlusion height.

Flying units start to gradually increase in height before the terrain reaches that height.

You'll see the same thing with destructables that have an occlusion height settings, for example trees.

 

[Hashjie]

It's based on occlusion height.

Flying units start to gradually increase in height before the terrain reaches that height.

You'll see the same thing with destructables that have an occlusion height settings, for example trees.

Thanks a lot relurofiron99, I learned something new today (•‿•)

Can't spread yet

 

[TwoVenomous]

Thanks a lot rulerofiron99, I learned something new today (•‿•)

hey, how did you understand that ? teach me

anyway, thanks for the information everyone.

for ruleronfiron99 , must spread rep first

EDIT : sir Hashjie, i checked the z_height for Line[5] and Line[6] and it has the same height that is 0.00. or did i checked it wrong ?

• Untitled Trigger 001
  • Events
    • Map initialization
  • Conditions
  • Actions
    • Set Line[5] = (Center of Enemy First Line <gen>)
    • Set Line[6] = (Center of Enemy Second Line <gen>)
    • Custom script: set udg_z_height = GetLocationZ(udg_Line[5])
    • Game - Display to (All players) the text: (String(z_height))
    • Custom script: set udg_z_height = GetLocationZ(udg_Line[6])
    • Game - Display to (All players) the text: (String(z_height))

 

[ap0calypse]

What iron said (but worded differently):

It's the same effect that makes a flying unit begin to rise before even reaching the base of the cliff.
The most simple solution is placing the cliff a bit farther away.
I believe Blizzard did this to avoid jerky movement (going from height 0 all the way to height 128 doesn't look good, so gradually increasing the height before even reaching the cliff is a logical solution to that problem).

I hope that's a bit more understandable.

Edit: for a little bit more clarification, I don't think you can actually get the modified height.
Both the FlyHeight as well as the LocationZ get modifiied, but only the base can be retrieved (like Height = 0.00 right before the cliff instead of what it actually is).
If I had some values it wouldn't be hard to reverse engineer the system so the actual and modified height are the same, but I don't have them and have no idea how to get them either :/.

 

[TwoVenomous]

What iron said (but worded differently):

It's the same effect that makes a flying unit begin to rise before even reaching the base of the cliff.
The most simple solution is placing the cliff a bit farther away.
I believe Blizzard did this to avoid jerky movement (going from height 0 all the way to height 128 doesn't look good, so gradually increasing the height before even reaching the cliff is a logical solution to that problem).

I hope that's a bit more understandable.

Edit: for a little bit more clarification, I don't think you can actually get the modified height.
Both the FlyHeight as well as the LocationZ get modifiied, but only the base can be retrieved (like Height = 0.00 right before the cliff instead of what it actually is).
If I had some values it wouldn't be hard to reverse engineer the system so the actual and modified height are the same, but I don't have them and have no idea how to get them either :/.

yeah, thanks a lot. i did a test by creating the unit away from the cliff and it worked perfectly.

oh, so that's the reason it's always went 0.00. :/