llDetectedTouchPos in a HUD

for making something as simple as a slider, having this function return region coordinates is fine, I was able to make a nice sliding bar effect using this, but why on earth does the return value have to change when the script is in a HUD?

The wiki says '...unless it is attached to the HUD, in which case it returns the position relative to the attach point...' and the link from there reads '..Objects that are attached are positioned local to the attach point; their global position and angle are affected by the position and rotation of the avatar..' but at no point does the wiki tell me what the positions of the attach points actually are ...

How on earth can this be used to find the relative position on a child prim on a HUD that dosn't require a degree in advanced mathmatics?

Heres the script i wrote, which works fine in-world

Ok, so there are 3 prims ..
Main prim ( the body ) is <0.01,0.2,0.25>
the first child (which contains the script ) is the background to the slider,
named 'Altitude' is <0.02,0.1,0.225>
the second child, is a bar i iwant to move up and down the slider, as i move the mouse,
named 'AltitudeSlider', is <0.05,0.08,0.01>



as i say, it works great on a normal prim, but try adding one onto a HUD, where the slider isn't positioned in the center, and the wierdness strikes.

Any suggestions greatly appreciated.

Edit. I originally wrote this with the intention of posting it in the JIRA http://jira.secondlife.com/browse/SVC-1902, but then thought maybe i should post it here instead ..

That I know, there isn't a way JUST from the child prim. It'll require a little bit of help from a script in the root prim, to figure out where the object is relative to the attach point.

Here is an example (NOTE: scripts have not yet been compiled; some syntax fixes may be required):

Root prim:

integer ROOT_POS_QUERY_LINK = -1755723941;
integer ROOT_POS_NOTIFY_LINK = -1755723940;
float TIMER_PERIOD = 2.0;

vector rootPos;
rotation rootRot;


sendRootPos()
{
   llMessageLinked(
      LINK_ALL_CHILDREN,
      ROOT_POS_NOTIFY_LINK,
      llList2CSV([ rootPos, rootRot ]),
      NULL_KEY);
}

refreshRootPos()
{
   vector newRootPos = llGetLocalPos();
   rotation newRootRot = llGetLocalRot();
   if (newRootPos != rootPos ||
       newRootRot != rootRot)
   {
      rootPos = newRootPos;
      rootRot = newRootRot;
      sendRootPos();
   }
}


default
{
   state_entry()
   {
      rootPos = llGetLocalPos();
      rootRot = llGetLocalRot();
      sendRootPos();

      llSetTimerEvent(TIMER_PERIOD);
   }

   timer()
   {
      refreshRootPos();
   }

   link_message(integer senderPrim, integer cmd, string stringParam, key keyParam)
   {
      if (cmd == ROOT_POS_QUERY_LINK)
      {
         sendRootPos();
      }
   }
}

Child prim (snippit):

integer ROOT_POS_QUERY_LINK = -1755723941;
integer ROOT_POS_NOTIFY_LINK = -1755723940;

vector rootPos = ZERO_VECTOR;
rotation rootRot = ZERO_ROTATION;


default
{
   state_entry()
   {
      llMessageLinked(LINK_ROOT, ROOT_POS_QUERY_LINK, "", NULL_KEY);
   }

   link_message(integer senderPrim, integer cmd, string stringParam, key keyParam)
   {
      if (cmd == ROOT_POS_NOTIFY_LINK)
      {
         list params = llCSV2List(stringParam);
         rootPos = (vector)llList2String(params, 0);
         rootRot = (rotation)llList2String(params, 1);
      }
   }

   touch_start(integer nDetected)
   {
      vector childPos = llGetLocalPos();
      vector childRot = llGetLocalRot();

      integer i;
      for (i = 0; i < nDetected; ++i)
      {
         vector touchPosAttachRel = llDetectedTouchPos(i);
         vector touchPosRootRel = (touchPosAttachRel-rootPos)/rootRot;
         vector touchPosChildRel = (touchPosRootRel-childPos)/childRot;

         // ...
      }
   }
}

You COULD also try llGetObjectDetails() on the root prim, but I suspect that will return exactly the same value as llGetPos() would from the root prim (the avatar's region position).

So what your basicly saying, is that the values of llGetLocalPos() and llGetLocalRot(), when called from a script in the root prim of a HUD, will constantly change depending on the avatars position and rotation?

My tests suggest this is not so, but thanks for giving it a go

*facepalms*

I wonder why you never considered the simple use of llDetectedTouchUV, that would have solved all your problems in the first place. How did you come to llDetectedTouchPos first? Did you never check for alternatives?

I just can't believe you are capable of writing all that and being absolutely oblivious to a better linden function alternative, I am the one who even put every single llDetectedTouch* function on each LSL Portal page to make sure people see the alternatives.

Oh! yes, llDetectedTouchUV is exactly what i was after .. thanks for that Nexii .. couldnt see the wood for the trees..

Just a side-question:

These functions don't work in the public viewer, yet, right? They're just working in the RC-viewer?

How long will it take until they find their way into the public-viewer?

Nope..they are there in the stable 1.21.x viewers, which have been available for about a month. See http://wiki.secondlife.com/wiki/Release_Notes#New_features:

llDetectedTouchUV() may not be suitable for some applications. Glad it worked for this one, but the question of how to use llDetectedTouchPos() from a child prim in a HUD attachment is still a valid one, and one that is unfortunately difficult to deal with because of the solution LL chose for that function.

No, it won't change based on the avatar's position. But it is possible the attachment might be moved, which is why I threw a timer in there to check for changes.