[JASS] GetLocationZ() does not change for cliffs

[Anachron]

Hi guys,

I was just about to update my missile engine and I found out that GetLocationZ() does not take care of the cliffs.

If I throw an unit to the target and there is a cliff on the way, it still says the height is the same.

If you want I will attach my missile engine and you will see what I mean.

Basically:
Start + Target location have same cliff level.
Put a cliff which is on the way.
Throw a missile to the target.
Print the Z-Value of GetLocationZ all the time.

Wonder why it never goes +64. (+1 clifflevel)

 

[Garfield1337]

It should work properly. I did a quick test and it worked for me.

Post the way you did it.

 

[The Reborn Devil]

GetLocationZ() does detect cliffs. You must be doing something wrong if it's not working. I've made several missile systems, and a physics engine, and I have never encountered issues with cliffs. And I'm not using the functions for cliff levels.

 

[Anachron]

Argh, of course guys, you are right.
I am abusing vJASS and I seem to not be supposed to play around so much...
Thanks, I will try to fix it.
I will post the map if I cant get it to work...

 

[Adiktuz]

Hmmm... I think I also experience that on my old missile system... weird things when the missile fly on blizzard cliffs...

 

[Anachron]

Yeah interestingly it doesnt go up from 0 to 128/64 but increases until it hits cliffs center.
I will post my map soon here. I made a little mistake but I cant find it

 

[WaterKnight]

Press G to view grid. See that there is a gradient between different cliff levels.

 

[Cokemonkey11]

They did this on purpose to allow doodads to be placed "on" cliffs with at least a little bit of realism. Open the doodads layer and zoom in on a cliff, move your mouse perpendicular across the cliff and you can see this in action.

 

[Berb]

Not really sure what you mean by "abusing" vJass... if you're using GetLocationZ then it works whether you're using cliffs or raise/lower terrain.

Print the Z-Value of GetLocationZ all the time.

Wonder why it never goes +64. (+1 clifflevel)

Depending on your current level, it will go from (lets use your numbers) 64 and rapidly decrease from 64 to either 0 or -64 depending on the height of a cliff (I forget, its one or the other) and then stay steady and then rapidly incline. Can I see the code you're using to print the location Z?

They did this on purpose to allow doodads to be placed "on" cliffs with at least a little bit of realism. Open the doodads layer and zoom in on a cliff, move your mouse perpendicular across the cliff and you can see this in action.

They are simply placed on the location Z of the terrain point that they are placed on. The cliff level does not make the height go from 0 to X in an instant, its a fairly quick but gradual incline. You can see the same effect if you set a flying unit with 0 height. It not possible to move a unit to a point that is lower than the terrain.

 

[Anachron]

I give up.
Could someone please check what's wrong with my missile engine?

I have module MissileUnitTarget and MissileLocTarget, and they both use MissileMovement.

When I have a struct UnitTargetMissile and give it the MissileUnitTarget module it also triggers the initialization of MissileLocTarget.

Please check the attached map.

Second thing is, why does the unit not have proper flight height on water cliffs? On land everything seems to be fine.

View attachment PS_UP_v.0.1.8.w3x

 

[Berb]

Could you maybe specify where the problem is in your code?

From what I can see the missile is doing what it is supposed to.

 

[Anachron]

If you throw the missile to a target and it's in shallow water, it makes weird spikes (when its on the cliffs) and also the Target Point Missile somehow triggers the UnitTargetCleanup method, but its only declared in MissileUnitTarget module and the missile of my spell does NOT have the module (thus firing the null struct deallocation).

 

[Anachron]

I would be happy if someone could find the mistake.
I don't see it.

 

[PurplePoot]

I can't actually modify your map to test anything since my version of JNGP doesn't support some things in your code, but I suspect it isn't actually a code issue. Movement type "foot" on your dummy sets it on the ground assuming 0 fly height--even if the ground is underwater--whereas GetLocationZ considers water to be ground. "Hover" would fix this specific issue (since the unit will use the water level as the ground level as well), but would make fly height mess up around cliffs. I don't recall any good solution.

 

[Anachron]

Thanks for your answer.
I use the Ravenform ability 'Arav' to set the fly height.
About the coding issue: I think it's some mistake since it triggers and uses parts of code which I did not tell them to use.

I use latest JNGP (5e) and latest JassHelper.

 

[PurplePoot]

It doesn't matter what you use to set the fly height, sorry if my post was unclear; what I mean is that for a given unit with 0 fly height and move type "foot", it will be underwater since it measures from the ground underneath the water (and 50 fly height would be 50 above that, etc), whereas GetLocationZ (and move types "hover"/"fly") measure from the top of the water as 0. It's easy to test if this is in fact the problem since changing your dummy's move type to "hover" should fix the display issues over water (but cause different ones over cliffs, so don't expect this to be a miracle fix).

And yeah, the issue with JNGP is presumably that mine is super outdated from back when I actually used to mod wc3, but I can't really be bothered to update it at this point.

 

[Berb]

When I set my dummy (in my Projectiles library) to movement type "Hover" (as well as doing the Raven Form thing) it seems to fix the display glitch over water.

I don't think this has anything to do with vJass though.

 

[Anachron]

Well, if I do this in my engine it doesn't do anything

 

[PurplePoot]

When I set my dummy (in my Projectiles library) to movement type "Hover" (as well as doing the Raven Form thing) it seems to fix the display glitch over water.

I don't think this has anything to do with vJass though.

Of course not; it has to do with the fact that the unit move type considers the ground to be in a different place than GetLocationZ does.