Associate Prim in Primset to Call

[EnCore Mayne]

i have a primset that turns a light on with a touch event. unfortunately, the light is associated by its link number and i keep adding new prims to the set and that breaks what the link number was. so...is there a more clever way of associating any prim within the primset that remains constant no matter how many times i add/subtract prims to it?

at present, i have the touched prim associated because it's the touched prim (llDetectedLinkNumber) but, of all the primparams (and my limited knowledge) i can't seem to find a way to associate a seemingly random prim (named Light, description lensR) to the event:

if ( (string)llGetLinkPrimitiveParams (llDetectedLinkNumber(0), [PRIM_DESC] ) == "onoff" )

llSetLinkPrimitiveParamsFast( >here's the problem<, [PRIM_POINT_LIGHT, 1, <1,1,1>, 1.0, 4.0, 0.0]);

instead of >here's the problem< is there a llGetsomethingorother to put in there that can associate the proper prim to turn on?

[Wulfie Reanimator]

If you've already checked for "onoff" in the description with llDetectedLinkNumber, you can use llDetectedLinkNumber again to set the touched prim's light params.

[Myrmidon Hasp]

If your light and switch are different prims you'd need to search for the light. 

You'd could step through the link numbers and test for the description of the prim you want to light up like you've done with the switch, then store that number in a variable and feed it into your llSetLinkPrimitiveParamsFast().

Use llGetNumberOfPrims() to set the high end of your loop.

[Love Zhaoying]

Could also put a different script in prim needing the light, and send a linked message on touch. Script in light prim catches message, turns on/off.

[Rolig Loon]

There are two ways to do this.  Either will work, depending on how your script is designed.  First, give the prim that is meant to light up a name, like "Light".  Then you may either write
 

if (llGetLinkName(llDetectedLinkNumber(0)) == "Light")
{
    //Stuff to make the light work
}

and put that in the touch_start event, or ...

you can put this code in your state_entry event
 

integer i;
while ( i < llGetNumberOfPrims() )
{
    ++i;
    if ( llGetLinkName(i) == "Light" )
    {
        iLight = i;     // iLight is an integer variable.  Make it global by puttting it at the top of your script
    }
}

Then, in your touch_start event, you can write
 

if (  llDetectedLinkNumber(0) == iLight)
{
    // Stuff to make the light work
}

The second method is especially attractive if you will be adding other scripted functions that affect some of the additional child prims you are tacking onto your object.  You can identify all of them with integer variables like iLight so that you can always identify them by name rather than by link number.  If your script will do nothing but turn the light on/off, then you probably want the first option.

 

Edited September 13, 2018 by Rolig Loon

[Xiija]

here is a small example to play with?

If your lights are named with the convention:

light, sw1

light,sw2

 and your switches are named

sw1

sw2

you could do something like...

list lights;
integer k;
getLights()
{
      integer prims=llGetNumberOfPrims();  
      integer x;
      for(x = 2; x <= prims;++x)
      {  string lName = llGetLinkName(x);       
         list tmp = llParseString2List(lName,[" " , ","],[" "]); 
         string name   = llList2String(tmp,0);        
         string switch = llList2String(tmp,1);       
         if ( name == "light")
         {  lights += x;        // store link number of the light  
            lights += switch;  // store the switch name which operates this light    
         }         
      }      
}
doLights( integer linkNum , string linkName )
{
    if( ~llListFindList( lights, [linkName]) )
    {  integer index = llListFindList( lights, [linkName]);
       string lite =  llList2String( lights, index - 1) ;
       llSetLinkPrimitiveParamsFast( (integer)lite, [PRIM_POINT_LIGHT, ( k = !k), <1,1,1>, 1.0, 4.0, 0.0]); 
    }
}
default
{
    state_entry()
    { getLights();
    }
    touch_start(integer total_number)
    { integer link = llDetectedLinkNumber(0);
      list params  = llGetLinkPrimitiveParams( link, [PRIM_NAME]);
      string linkName = llList2String(params,0);    
      doLights( link, linkName );
    }
}

Although using the integer .. k .. as a toggle might need some changing heh

Edited September 13, 2018 by Xiija

[EnCore Mayne]

38 minutes ago, Rolig Loon said:

 or ...

you can put this code in your state_entry event
 

integer i;
while ( i < llGetNumberOfPrims() )
{
    ++i;
    if ( llGetLinkName(i) == "Light" )
    {
        iLight = i;     // iLight is an integer variable.  Make it global by puttting it at the top of your script
    }
}

Then, in your touch_start event, you can write
 

if (  llDetectedLinkNumber(0) == iLight)
{
    // Stuff to make the light work
}

The second method is especially attractive if you will be adding other scripted functions that affect some of the additional child prims you are tacking onto your object.  You can identify all of them with integer variables like iLight so that you can always identify them by name rather than by link number.  If your script will do nothing but turn the light on/off, then you probably want the first option.

 

i thought this is what i was going to have to do. having it articulated with an example is way better than getting completely confused and frustrated with the immense maze the Wiki is to me presently. thanks Rolig. this will go a long way to optimizing my kluge.

[Phate Shepherd]

For the examples above that look for the named prims and assign the link number to a global, I would highly recommend adding the following as well:

default
{

  // All yer other default state code

  changed(integer change)
  {
    if (change & CHANGED_LINK) 
    {
      // Either reset your script or call the routine that scans for link names
      llResetScript();
    }
  }
}

The point of this is: If you unlink/relink your object and don't update the globals that are holding the link numbers that you are changing, your script will make changes to the wrong prims. This prevents that from happening by updating the stored link numbers any time the linkset is changed.

Edited September 15, 2018 by Phate Shepherd

[EnCore Mayne]

19 hours ago, Phate Shepherd said:

The point of this is: If you unlink/relink your object and don't update the globals that are holding the link numbers that you are changing, your script will make changes to the wrong prims. This prevents that from happening by updating the stored link numbers any time the linkset is changed.

brilliant! i coulda used this before seeing all sorts of random prims getting turned into lights ad infinitum with seemingly no apparent reason. thank you.