[JASS] Setting an ABSOLUTE z height

[Lord_BoNes]

I have a problem...
I need to set an "absolute" height on the z-axis. In my test map, the values returned are correct, but the object still "rises" over cliffs, forming an upside-down V.

I'm doing all this in vJASS. I'm still learning a little, so don't flame me, if this is a simple question (even though, I can assume it is not).

I'm using GetLocationZFixed(x,y) to detect the terrain height at the designated area... it returns correctly.

I'm using a formula that finds the constant velocity vector (x,y,z) and stores it in the projectile, so that I just multiply that by speed * tick-time.

All I want is for it to go in a dead straight line from point A (x,y,z) to point B (x,y,z), without terrain effecting it at all. On flat terrain, I've achieved that, but with cliffs or deformations... that's another story.

I can post my code, if that helps. But, be forewarned, it is pretty long... a good hundred lines, possibly more, last time I looked at it.

Any help would be GREATLY appreciated.

And, if you help with a solution +rep for you... then I can go

 

[Day-Elven]

Can't you just check pathability?

 

[Justify]

Then your GetLocationZFixed sucks like hell
No, realy. If you use GetLocationZ correctly it'll work on any deformation and cliff, the only problem is the "bugged" result on water because it returns the ground and not the surface of the water... you should show your code I think

EDIT: @Day-Elven: That has NOTHING to do with flying heights? oO

 

[Lord_BoNes]

I have run MANY play tests. The problem isn't in the GetLocationZFixed function. The results have proven it... But, I'll post my code when I get up tommorow (well, later today). I'm quite tired now (it's 5:30am), and I honestly wasn't expecting such a quick response.

@Day-Elven: What kind of stuff are you smokin'? Where's mine? LOL
Seriously though, I'm not caring about whether it's pathable or not... The caster, can possibly fly... I want it to be able to pass over terrain, without changing it's direction or height. As I said above, using default camera, the projectile follows an upside-down V arc, that's usually about an inch in length. The "sharpness" of the V depends on the steepness of the terrain below. On a ramp, it is more like a flattened U shape.

I want a STRAIGHT line from caster to target, without terrain even being taken into account.

Sleep now.
I'll catch ya's tommorow.

 

[Akolyt0r]

do you use a dummy unit as projectile ?
if yes, make sure its movement type is hover not flying...

 

[Eleandor]

This is the info you have:
X1 = X of caster
Y1 = Y of caster
X2 = X of target
Y2 = Y of target

Z1 = Terrain height of (caster) + flying height of (caster)
Z2 = Terrain height of (target) + flying height of (target)

Given any X and Y on a straight line between point 1 and point 2, you can calculate the Z as:
Z = (terrain height of X, Y) + (linear interpolation between Z1 and Z2)
You can then calculate the flying height of the projectile as:
flying height = linear interpolation between Z1 and Z2 - terrain height of X,Y

(is that correct? Pretty tired at the moment...)

 

[Quantum_Menace]

See this thread. He had the same problem, and like Akolyt0r said, it was because of the dummy unit's movement type.

I know that "foot" movement type with Crow Form works, but haven't tried hover.

 

[Lord_BoNes]

I tried hover, foot, and amphibious... All three demanstrated the same problem, but because of collision radius (fly is the only one that lets two units be so close together), I have to you fly.

 

[maskedpoptart]

height of terrain + flying height = total height of unit.
we want the total height to remain constant (for 0 zvelocity)

say we start off at point (x1,y1,z1) and want to move to (x2,y2,z2) without changing the total height. we set up an equation for constant total height.
GetLocationZFixed(x1,y1) + current flying height = GetLocationZFixed(x2,y2) + final flying height.
we want to find final flying height.
final flying height = (GetLocZ(x1,y1) - GetLocZ(x2,y2)) + current flying height.

if (x2,y2,z2) is the point to move to in the next frame, you can take your zvelocity into account by using this equation:

final flying height = (GetLocZ(x1,y1) - GetLocZ(x2,y2)) + current flying height + zvelocity

of course, you'll have to convert this to real code

 

[Justify]

Oh, and why do you need "fly" as movement type? If you use SetUnitX and SetUnitY it ignores the collision radius oO

 

[Lord_BoNes]

I'm doing a "DBZ" style beam. It creates "beam segments" every x distance. The beam segments are the main objects effected by this problem, the actual "beam head" is still effected, just not as much. To conserve CPU cycles, I only update the height of the segments when they're created and when the next one is created.

I've included my test map. Please look it over and try to find out why this is happening. All I do to demonstrate this, is to order one of the flying heroes to cast past the cliff (so the beam flys over the cliff on its way down).

<RANT>
I'm releasing this test map only to get help with it. I'm sorry if this is already implied, it's just that I'm against releasing my things "unprotected". I'm the kind of person that bends the rules of an engine (to see what I can do). Alot of what I do, I haven't seen anywhere else... so please don't copy it, without full credit.
</RANT>

Now that's over with...
Thanx in advance to those that help me

EDIT: My map didn't attach.... It is now.

 

[Element of Water]

There is NO WAY of making a dummy unit fly without taking terrain into account if you only update the height when it starts and when it stops. You must update the height every time the dummy unit is moved along x and y.

 

[Lord_BoNes]

The tail segments don't move after creation, only the head does.
The "-" are tail segments, the "O" is the head.
O
-O
--O
---O

Load up the map and see...

As I said above, the head creates a trail of segments (dummy units that look like the head, only smaller) behind it going from caster to target, DBZ beam style... I'm trying to imitate a Kamahamaha in this case.

I just want some assistance, as the numbers don't add up.

 

[Quantum_Menace]

Alright, that's definitely caused by the "fly" movement type. You can either give it a movement type of "none" which ignores collision, or give it "foot" along with the locust ability which makes it ignore collision and also be untargetable and unselectable.

 

[Dr Super Good]

Its due to the smoothing of flying height changes for cliffs that WC3 uses on air units.

Use a collision type none with flying trick and with luck it should be fixed.

 

[Lord_BoNes]

Thanx Dr Super Good.... you live you to your name. It works perfectly.
BTW, seen as you fixed the problem, in 2 short sentences, would you be able to look over my coding? I'm still a little new to vJASS, and I'm fairly sure that there are improvements to be had.

Thanx for the help, either way. +REP to all those who helped

 

[Quantum_Menace]

On another note, GetLocationZFixed does not seem to sync any better than GetLocationZ itself.

I tested it between two computers, and GetLocationZFixed always gave the same results as GetlocationZ, including desynced results from terrain def/fog of war differences and walkable doodads.

 

[maskedpoptart]

lol wow... i'm surprised the problem could be fixed so simply after i did all that work trying to calculate the flying height. nah idc; i got rep anyway . good luck to you on your project, Lord_BoNes. i'll look for it when it's done.

 

[Lord_BoNes]

@MaskedPopTart: I've updated the test map... I've removed it from the post where it was, it is now in the first post. In this updated version, the beam travels as it's meant to, and it even explodes (with a scaled explosion) upon impact with the ground.
Also, thanx for doing all that work with trying to fix the problem. I really appreciate it. I'd done a fair amount of effort myself, only to be surprise at the simplicity of the solution

I still have to do collision detection (units, buildings, etc.), and power struggles. Then, it will do f*cking awesome