Slider bars on HUDs

Okay, I've made myself a nice little HUD which uses slider bars for various things, and it works great in-world. However, I'm trying to use it attached to my HUD and the values it's returning are unusual.

The sliders are using llDetectedGrab(), and the results it's getting SEEM to be related to where my avatar is, at least the heights are nearly identical. However, the x and y co-ordinates bear little resemblance to the place I am, e.g they may be <82, 120, 700> but I'm at <202, 212, 700>.

Does anyone know what EXACTLY llDetectedGrab() is returning on a HUD item, if I could figure that out I might be able to go about getting values that don't change with rotation and the like.

I recently tried to do a llDetectedGrab()-based HUD test, and the results were rather dismal. I was using a "floater" which was a child prim, but used coordinates from the root prim. The numbers were all in the 0.0 to +-0.1 range, but they didn't correspond to the directions I was moving it.

I might fiddle with it more later, but it didn't seem to be working at all.

from http://rpgstats.com/wiki/index.php?title=LlDetectedGrab

Note: Unlike the other llDetected* functions, llDetectedGrab will only return a meaningful value in the touch() event.

HUD Attachments
In the case of HUD attachments, llDetectedGrab will always be relative to the direction the avatar is facing. This means that you can produce a script that will allow you to use llDetectedGrab in HUD attachments; however, it will not perform correctly if you move the camera around. Regardless of where they appear to be on your screen, HUD attachments are still attachments, which are fixed to the avatar's rotation, despite appearances to the contrary.

Q: I can't get this to work. What's going on?
A: Is llDetectedGrab inside your touch() event? If it's within touch_start() or touch_end(), it won't work.

It doesn't help though, the results returned don't seem to bear any really meaningful information when taking into account the avatar's current facing either. e.g:

vector g = llDetectedGrab(0) / llGetRootRotation();

Even keeping the camera 'locked' to avatar facing it doesn't seem to return consistent values when facing different directions, which a truly avatar relative function would.

As such, if the llDetectedGrab() result is relative to the avatar, then it must be affected by some other factors as well, but I don't know what, and the Wiki entry is very vague/gives no examples for HUDs. I mean, it might be that the result is relative to the camera rotation AND avatar rotation as well for example, and I'm going to try some combinations, but I was hoping someone might already know. I'd rather not track camera variables but if I have to I will.

There seems to be no real issue in using this with root prims in HUDs, but I still can't figure out what in the heck the numbers I get from child-prims actually mean. Even if I put the touch() event in the root prim, the results from llDetectedGrab() when dragging child-prims makes little sense. It still gives results as a strange region co-ordinates, ie height is roughly where your avatar is, but the X and Y values don't seem to bear any relation.

This may help
It's a bit involved so I had to use notation - here's the notation used - P or R refers to Position and Rotation - then the prim to which the P or R refers i.e. avatar, parent (attachment root),or child prim(s). Finally, the letters in parentheses refer to the REFERENCE FRAME defined and can be world, avatar, parent, child

R.child(parent) should be read as "the rotation of the child relative to the parent's reference frame".

Whew.... sooooooo....

for a CHILD PRIM IN AN ATTACHMENT...
llGetLinkNumber() returns 2...n (ERRONEOUS)
llGetPos() returns P.avatar(world) + P.child(parent) * R.avatar(world) (ERRONEOUS)
llGetLocalPos() returns P.child(parent) (ERRONEOUS)
llGetRootPosition() returns P.avatar(world)
llGetRot() returns R.child(parent) * R.avatar(world) (ERRONEOUS)
llGetLocalRot() returns R.child(parent) (ERRONEOUS)
llGetRootRotation returns R.avatar(world)
llSetPos() sets P.child(parent) = value (ERRONEOUS)
llSetRot() sets R.child(parent) = value * R.parent(avatar) (ERRONEOUS)
llSetLocalRot() sets R.child(parent) = value (ERRONEOUS)

Amongst these values llGetLocalPos/llGetLocalRot and llSetPos/llSetLocalRot, though erroneous in a formal sense, should get you where you need...

Thanks for that list, very informative! However, I'm still unsure how it relates to llDetectedGrab()? llGetLocalPos() and llGetLocalRot() are returning values as I would expect for my HUD attachments (90º rotation around Z to get them to face the right-way, with an offset to position them).

I've been trying various combinations of applying avatar rotation and HUD rotation but they aren't really changing the values much.

The wierdest thing is, when I went to the bottom corner (almost <0,0,0> in the region I was in then flew diagonally to the opposite corner (where my land is) the results I got corresponded to the coordinates I was located at. ie when I was at <40, 40, 200> the results would be something like <42, 42, 200> when I dragged up ('forward') and <38, 38, 200> when I dragged down ('back'). It was even fine when I arrived at my land, but then for unknown reasons went all to whack again. I thought it would just be my rotation but I couldn't get the values back again, this with an unmodified test HUD comprosing two boxes, each with a script which returns the llDetectedGrab() values for touch() events to see the difference between root and child.

I'm attempting to get a hold of a Linden to see if I can get to one who can give me an indication of what the values returned actually are, and why they differ so completely from those of a root prim. It seems very much as though we're looking at bug, which is not good, but it means my HUD is almost completely useless as the slider bars now only go up

No Linden response, so I've posted this to the Second Life Jira. Please log-in to it here:
https://jira.secondlife.com

Then go to this link to vote on the issue, which details my findings and proposes that this be fixed, as it is useless for attachments otherwise:
https://jira.secondlife.com/browse/SVC-265

I have been using a slider system for a while. works great. Hint it this the cameras roation which you have to take account for when worn and teh Huds Root Local Rotation . I'll give ya the code once I edit it strip it down. And when are they going to re-enable the VB code. this is nearly impossible to read code here.