integer llDetectedLinkNumber(WTF!)

Good day,

I am trying to modify a freebie bike to have a headlight beam that turns on and off when you click on a switch prim. I'm having two problems with this jolly little endevor.

Firstly, HOW THE HELL DOES llDetectedLinkNumber() WORK!? I can't make sense of the documentation on the subject, and I've tried it every which way I can think of.

I've looked over the smidgeon of commentless example code:

touch_start(integer num_detected)
{
integer i = 0;
for(; i<num_detected; ++i)
llWhisper(0, "Link number clicked: " + (string)llDetectedLinkNumber(i));
}

I've even used the code verbatim to figure out which link number the switch, and two cones of the headlight beam are. I've also tried to torture the function into a cornacopea of other arrangements to the tune of type mismatches, oh so many syntax errors, and the ever lovely no error but no do-y what I want-y.

I can't wrap my head around why the programmer used a for() loop, or why I can't seem to get the function to function in a similar way outside of a for() loop, or, indeed, at all.

All that I want to do is have the root prim have a touch state that checks to see which prim was clicked, put that link number into a variable, run the variable through if elses to see if it's the switch being clicked and if the headlight is on or off, then llSetLinkTexture accordingly.

Secondly, I tried throwing ideas of efficiency, and figuring out the detected link number thing for future projects, to the wind, and put a script into the switch itself. It used a touch_start. touch_start had one if(headlighton = FALSE) set the linktextures such that the headlight looks on and set headlighton to TRUE, then an if that goes the other way. When I clicked the switch it turned the headlight on then off in the same click.

I presume this is because one if follows the other, so it goes through one, setting headlighton to FALSE which means the next if is entered too, since it's right after. I tried to use else if, but that said either syntax error or just made the entire script do nothing. I even tried to use jump so that if it goes into one if it jumps past the second if, but that just turned the headlight on and off again with one click...which doesn't imply it checks the conditions of all the ifs before it goes into them, or it will have gone into only one, since headlightson is either TRUE or FALSE, not both at any given time...

Perhaps I've been at this too many hours in a row, but any perspective that can be shed on the nature of these two problems, especially the first, would be met with showers of roses and fond wishes.

Events like touch and sensor and collision are capable of getting triggered by more than one thing. These events are given a count of how many things triggered the event - this is the "num_detected" parameter in the code you posted.

The for loop in that code just goes through each thing that triggered the event. If two people had touched the object at the exact same time (which doesn't happen often in reality) the "num_detected" would be set to 2. If just one person touched it, it would be set to 1.

The loop is for the case where multiple residents touched the object at the same time (in the same server frame; normally one 45th of a second). The argument num_detected (or whatever else you choose to call it) to the touch event handler is the number of touches that occurred, and if you give a value N (between 0 and num_detected-1) to the llDetected*() functions, they will give you information about that Nth touch. So llDetectedLinkNumber(3) would be the link number of the prim that the fourth touch landed on (remember they start at zero like a list). You'll find that often only one touch happens at a time, but that's not always the case.

EDIT: In other words, what Meade said while I was taking my sweet time writing. LOL.

As I've waited, and I use the term "waited" loosely, using the term "loosely" to mean "not at all representative of what I was actually doing", I found the LSL help group in world, and found someone quite happy to banter in my flighty, subject-skipping sort of way. So far, the only thing I've heard consistently about llDetectedLinkNumber's integer arguement is that it allows you to tell the function which...which...

Dropping that line of description abruptly, I'll start somewhere else. From what I can interpolate from all the sources so far, the server cycles through things at a variable rate. In between each of these cycles, a detection event can be triggered multiple times. each iteration of the event being triggered is ordered into an index...spose that's not quite a function if a triggering entity can be mapped to two different index numbers after triggering the event multiple times...*pulls out discrete and foundational mathematics text book* not a function, which is more specific, aaa...relation: a set of ordered pairs. How non-sequitar of me to care.

Anyways, for each "server cycle" as you called it, thank you, I love jargon, there is one set of ordered pairs for each triggered event. The relation is the set that chronologically maps triggering entities to the applicable iteration number(s), N, of the triggered event. llDetectedLinkNumber returns the link number of the prim that was touched/collided with/etc. by the Nth entity to touch it/collide with it/etc...

Alright, peachy. and you catch the value it returns either by sticking it somewhere a variable or constant might go, or by saying such-and-such variable equals llDetectedLinkNumber(N)?

Hmm. Let's put it this way. If someone clicks on an object to touch it, that generates three touch events: 'touch_start' (on mouse down), 'touch' (on mouse down and periodically until mouse up), and 'touch_end' (on mouse up). For now let's say we only care about the 'touch_start' event. For this event, there is a set of data available about what happened. This event data includes such things as the key and name of the resident who did the touch, the position, rotation, and velocity of that resident's avatar, a boolean indicating whether the resident's active group is equal to the object's group, and the link number of the actual prim that was touched (see http://www.lslwiki.net/lslwiki/wakka.php?wakka=detected).

Now it turns out that 'touch_start' events aren't always delivered to your script individually. Instead, the simulator collects them over a short period of time (let's just call it the minimum time between events, which is 0.05 seconds by default, but might be longer depending on sim lag and the use of llMinEventDelay()) and sends them to your 'touch_start' event handler in groups. The integer parameter to your event handler is the number of events you are being given for processing. The llDetected*() functions each give you a piece of data FOR ONE OF THE EVENTS, and you tell it which event you are interested in using the parameter to the function.

For example, say Mary Lixample, Joe Lixample, and Fred Lixample all click on the object at very close to the same time, then a little while later Joe touches it again by himself, then Mary and Fred decide to follow suit but wind up touching the object at the same time again some time after Joe. The following code:

default
{
   touch_start(integer nDetected)
   {
      integer i;

      string message = "Touched by "+llDetectedName(0);
      for (i = 1; i < nDetected; ++i)
      {
         message += ", "+llDetectedName(i);
      }

      llOwnerSay(message);
   }
}

Then the output should be something like:

[1:23] Object: Touched by Mary Lixample, Joe Lixample, Fred Lixample
[1:25] Object: Touched by Joe Lixample
[1:26] Object: Touched by Fred Lixample, Mary Lixample

I hope that helps.

I was there, this one is with two prims

default
{
    touch_start(integer num_detected) 
    {
        if ( llDetectedLinkNumber(0) == 1 ) llRegionSay( kanal, sayon );
        else if ( llDetectedLinkNumber(0) == 2 ) llRegionSay( kanal, sayoff );
    }
}

happy scripting

the topic is llDetectedLinkNumber(), is'nt it?

Another way to get a better understanding about llDetected might be to play with sensors instead. Touch is a bit of a special case since it's almost always generated by a single avatar doing a single action. That and most examples of using it hardcode a (0) in there..