A plea regarding absolute height, suma

[Prospero 1]

A massive scripting niggle is the difficulty in determining absolute height (or height above *mean* sea level) - without jitter - and regardless of whether an object is over the ground, sea or a surface defined in a Roadway LOD. An associated problem is placing an object into the OFP world at an absolute height in the same circumstances.

If there was one single addition to OFP scripting commands, I would choose a (relatively simple) function to solve this problem. I have written about this before, I know. But I really think this would be a very good feature, so I just want to say it here again (in isolation, as it were).

Prospero

[Doolittle 0]

Prosphero, I tried something like this, where I see if the distance command can see the "mean" height, and take and extract Y from that value, but I couldn't get this to work.  Have you tried anything along these lines?

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">_pos = getPos player

_x = _pos select 0

_z = _pos select 1

_hyp = sqrt ((_x ^ 2) + (_z ^ 2))

_obj = "Logic" createVehicle [0, 0, 0]

_dist = _obj distance player

deleteVehicle _obj

_y = sqrt ((_dist ^ 2) - (_hyp ^ 2))

hint format ["mean %1 dist %2 hyp %3 player %4,%5,%6", _y, _dist, _hyp, _x, _z, _pos select 2]

<span id='postcolor'>

Doolittle

[Prospero 1]

If myobject is at location [_x, _y, _z], then its absolute height can be determined thusly:

mytrigger setpos [_x, _y, 0]

_objheight = (getpos myobject select 2) - (getpos mytrigger select 2)

Which is like saying:

_objheight = height of object above ground + height of ground at that location

Prospero

[Doolittle 0]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">_objheight = (getpos myobject select 2) - (getpos mytrigger select 2)

<span id='postcolor'>

I don't understand this code?  If I have a trigger at the shore, then it's Y (select 2) is 0, and if I am standing on a mountain, then my Y is also 0.  How would 0 - 0 be an object's true height?  I think I am misunderstanding you or something.

I had no idea stuff over water oscillated, other than when a vehicle would respawn after dying in the water it would still have crazy velocity!! Wait, are you sure it oscillates?! I didn't get results that suggested my spot in the water was moving around.

Doolittle

[Spitfire 0]

Yeah, water oscillates, OK. All you have to do to test it is to put two blocks of bridge near each other and do a looping setPos with a constant Z-value for the second bridge. You can easily see the movement compared to the stationary bridge. It goes up'n down with the waves.

So, there's not even a mean sea level in OFP

[Doolittle 0]

Prospero, I got it, I think!  With this code you can find an object's altitude.  Great if you want someone to stay below a certain altitude or they're detected, etc.  Also great for what I need it for, artillery adjustments according to height differences in target and source.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">_obj = _this select 0

_hypotenuse = _obj distance SeaLevel

_pos1 = getPos _obj

_pos2 = getPos SeaLevel

_x = ((_pos1 select 0) - (_pos2 select 0))

_z = ((_pos1 select 1) - (_pos2 select 1))

_adjacent = sqrt ((_x ^ 2) + (_z ^ 2))

_opposite = sqrt ((_hypotenuse ^ 2) - (_adjacent ^ 2))

hint format ["%1", _opposite]

<span id='postcolor'>

Basically I am using the distance function and my own distance function and extracting out the Y (altitude) value.

Set a Game Logic named SeaLevel at the shoreline, but not in water.

Doolittle

[Prospero 1]

Yup, but the distance command is rounding your result. Believe me, it's not accurate enough if you're trying to do attitude determination, for example.

This is why I recommend my method, even though it uses a trigger.

Prospero

PS: I seem to have deleted my second post in this thread by accident. Can't be arsed to rewrite it.

But for Suma, if he's out there: there seems to be a problem if getPos is used on an object which is above a slanted Roadway LOD on uneven ground. The z value returned does not seem to be accurate. Or at least, it's something like this. I've had enough of trying to figure it out.

Doolittle: Try my method. You will find that setPos and getPos work differently with triggers (well, setPos works differently, not getPos). That is why you are not understanding it at the moment.

[Doolittle 0]

Prospero, I see what you're saying now.  Wow that's a very wierd little quirk to find!  Interesting...!

Doolittle

[Prospero 1]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Prospero @ Dec. 08 2002,12:18)</td></tr><tr><td id="QUOTE">But for Suma, if he's out there: there seems to be a problem if getPos is used on an object which is above a slanted Roadway LOD on uneven ground. The z value returned does not seem to be accurate. Or at least, it's something like this. I've had enough of trying to figure it out.<span id='postcolor'>

Further:

What seems to be happening is something like this:

When one performs a getPos (i.e. getPos myobject select 2) on an object (myobject) that is positioned vertically above a sloping surface (let's say 0.5m above it) defined in the Roadway LOD, the height reported is not correct. The height is not the height of the object above the Roadway LOD, as it should be, but rather is the distance to the nearest part of the surface - i.e. the length of the normal to the suface which would intersect the position of myobject.

Something like this, anyway.

Please can we have a way of placing objects into the world at an absolute height (above mean sea level - or similar static reference plane), and also a way of determining an object's absolute height. Pretty, pretty please. It would really simplify a lot of scripts... artillery for example, not to mention all the stuff I seem to be interested in

Prospero

[Kermit 0]

Spitfire, there are also tides to account for.