Walkable Doodads are causing a dilema

[Gilded Touch]

ok, so i have this fps map. so far, every unit has it's own height and shooting it within that height range will get the unit killed.

so far, making doodads that you cant walk over is annoying because in reality you can walk over them and and making them walkable, puts the unit over the doodad which changes the overall height for the unit.
having a unit walk over something will change its height, but to the triggers, you can still shoot it at the normal height range and dies. so if u were to shoot a unit below what its standing on, it will dieand if you shoot the unit just above its normal height when it's not standing on top of a table, you will miss. Even though you are aiming at it right.

so what i am asking is, "Is there any way possible to register the height of a unit when it is standing on top a walkable doodad? Let it be known that not all doodads are in perfect geometrical shapes and normal sizes."

anyone who knows anything about this will not be eradicated
this is a screenshot of what i am dealing withView attachment delima.psd
if u read this and know what the answer is but do not tell me, i shall send my cyclopsafter u
if he doesnt eat u first

 

[GhostThruster]

You'll have to use a Pick Every Destructable Action that detects what the target is standing on, and then set the height required for the missile to hit.

 

[Gilded Touch]

not all doodads are perfectly round
some doodads reach out of their pathings like a long rectangle,
but it would work if i made every walkable doodad a small square, and kept them away from each other

 

[WaterKnight]

Walkable destructables (destructables, not doodads) are added to terrain height --> the function GetLocationZ(<location>) considers them. GetLocationZ returns the terrain height at a point, so GetLocationZ(GetUnitLoc(whichUnit)) + GetUnitFlyHeight(whichUnit) is the drawing origin of your unit. You should know that GetUnitLoc creates a new location object which should be destroyed after using but you can also use a static location that you only move via MoveLocation function to GetUnitX/Y.

Furthermore, GetLocationZ is not influenced by temporary terrain deformations but by permanent ones and it can be asynchronous among the different player clients because of different sight. I do not know whether destructables are immediately added upon creation when they are not visible but a friend of mine once had a problem that there was an animated walkable destructable and the animation started because of normal mechanics just when the destructable came into view so it was shifted among the players and the animation also influences GetLocationZ.

 

[Gilded Touch]

thanks waterknight

thanks, that is so much more simpler than changing the map, and it's alrdy implemented : )