llGround offset borked?

I'm working on a project with a floating vehicle type object and I want to be able to tell if the land up ahead is higher than it is right now. Theoretically, I should be able to do a check such as:

if (llGround(<2, 0, 0> > llGround(ZERO_VECTOR))
doSomthingAboutTheGround();

...Since offset according to all of the wikis is supposed to be in local coordinates like it is everywhere else, this should compare the current ground height with the height 2m in front of me.

However, it appears as if in this case, the offset is global and not local. <2, 0 , 0> will give the ground height to my North regardless of my rotation.

What I'm wondering is : is this broken? is this normal? should I be reporting it?

While I can calculate an offset vector based on global coords, why should I? Has anyone else run into this?

Thanks,
Sra

It has been like that for the last couple of years.

I think you either divide or multiply your world offset by your rotation (llGetRot) to get the wanted position. Someone else can probably clarify this.

A couple of years and no one has bothered to put a note in any of the wikis? Y'gods!

Thanks for the tip. I suppose there's no point in putting in a bug about it then.

O.o



Looks like it says it right there to me.



The only known bug in it was prior to 1.8.3, where it didn't work right in attachments, but that was fixed in 1.8.3.

I think what you are talking about is something different, though. No LSL function takes into account "current facing" when accepting a positional offset parameter. You always have to "translate" a position by a rotation to get something "ahead of you" or "in your line-of-sight", etc. Like so:

if (llGround(<2,0,0>*llGetRot()) > llGround(ZERO_VECTOR)) { // ground is higher 2m in front of me
}

From lslwiki.net:



It's quite clear that offset is about the local axis, not the global.

There's no clear explanation of offset on wiki.secondlife.com that I can find one way or another.

However, when dealing with llGetBoundingBox(), for example, the resultant information IS a pair of offsets referenced on the local axes, not the global. I only need to apply my rotation if I want global positional information from it. And, I've never in the last two years had to make a function call to llGetRot in order to apply a VEHICLE_LINEAR_MOTOR_DIRECTION. The X is always on the local axis, not the global.

So, again I say, either offset in llGround (and the other Ground functions) is borked, or the wikis are out of date/wrong. It seems to me that all offsets should either be global or local, not arbitrarily one or the other depending on each individual function. Having functions where you have to convert information form another function EVERY TIME in order to get a usable result, to me, means it's not working right.

I mean, is there a use for a function that returns a result based solely on an object's location where the offset is global? I can't think of any, but maybe I'm limited in my ideas by the types of things I do or want to do.

Works for me! A lot of stuff will bork if this is changed.

/me has a hard time finding that quote on the lslwiki.net page for llGround.

Where'd you find it?

(It's at , linked-to from the "offset" word on the llGround page.)

Ahh, I think I see your issue now. I've never really read the entry page for the "offset" keyword. I have no idea which functions it is meant to reference, as I don't know of very many which use that "definition". All the ones I know of which use a positional offset as a _parameter_ are object-relative, but on the global (ie, unrotated, irrespective of the object's rotation) axes.

The exceptions may be vehicles; I must admit I have yet to do a vehicle, but it makes sense that object facing is critically important, due to the fact that you are dealing with motion. Functions like llGround() don't make that assumption. In the case of llGetBoundingBox, it makes sense that the resultant box is rotated along with the object, since that is the most proper and concise description of what a "bounding box" is. It isn't meant to be "the smallest orthogonal box an object can fit in" because the size would constantly be changing as the object's rotation did, unless it was a sphere. That, and it really isn't in the same class as what we are talking about, since it doesn't take an "offset" as a parameter.

I figure that what happened was that someone found that offset was a defined keyword in the wiki and linked it (or the wiki did it automatically when the page was created), but the definition doesn't match the usage in that function.

At times, it doesn't seem like there is a lot of consistency across functions in terms of meaning, but there are also many different contexts that functions can be used in where different meanings are equally valid. As such, in the context of land functions, it really isn't a borked function, though the improper "offset" link reference makes it sound like it is.

in reality you have to get the forward pointing vector off your rotation like this:

vector front = llRot2Fwd(llGetRot());

This is a unit vector pointing directly in front of you. To get the distance 2 meters in front of you, simply multiply that vector by 2:

front = front * 2.0;

so the entire command could be written:

if (llGround(llRot2Fwd(llGetRot())*2.0) > llGround(ZERO_VECTOR)) // then the land 2 meters in front of you is higher than the ground under you -

I have used this extensively in a vehicle that I sell and it works perfectly