Links in a complex linkset are renumbering themselves - Help

[Malestorm1488303118]

Hi and in advance for any insight you might have with this problem.

I am building a scripted object that has about 150 links and is composed mostly of repeating units of 10 prims, each group containing scripts for that units operation with the root prim having a script that controls all the units.

The problem is that in the latest version of Firestorm and SL Viewers, the linkset is often getting renumber, even if I am just updating a script in one of the groups.     I use link numbers in my scripts, so the renumbering is really causing a problem.

Does anyone else have a problem with renumbering of linksets like this and if so, how is the best way to work around it?

[Rolig Loon]

If you are refering to the link numbers that you see if you Edit Links and look for the link number in your Edit tool, don't trust them.   Those numbers have been unreliable for several months.  Instead, put a scrtipt like this into your build.

 

default{    touch_start(integer num)    {        integer link = llDetectedLinkNumber(0);        llSay(0,"This is prim #" + (string)link + ". Its name is "+ (llGetLinkName(link) +".");    }}

The script I usually drop in pops up that information (and some other stuff)  in a dialog window when I touch a prim, giving me the option to delete the script if I no longer need it.   With the mini-version posted here, you'll have to remember to remove it manually when you are done.

 BTW, if you have that many links to keep track of, don't do it with link numbers.  Name your links and address them by name in your script.  That way you don't have to mess with numbers in your scripts if you relink your object. 

[Malestorm1488303118]

Thanks Rolig.   I figured addressing the prims by name rather than by link number was the answer.  I just have to redo several old scripts that were link dependent.   I wanted to make sure that the link numbers were no longer trustworthy.

[Malestorm1488303118]

Rolig, I had one follow up question. you said,

 BTW, if you have that many links to keep track of, don't do it with link numbers.  Name your links and address them by name in your script.  That way you don't have to mess with numbers in your scripts if you relink your object. 

 

So in the past, I have a fixed formula for where  a specific link should be in each group of prims.   I could set an attribute of a specific prim from my root prim using a setlinkedprimitiveparamfast using the formula ( initial-link-offset + ((#number of widget unit - 1) * number of prims in each widget unit ) + widget-offset-in-each-unit.

No that the linkset seems to be renumbering itself with it is edited, this fixed formula just does not work anymore.

How would you suggest that I now address prims by name in the script, since one cannot use a prim name in a setlinkedprimitiveparamfast.    

The only way I can figure out a way is that when the linkset is initializing, each prim sends out a message to the root identifying its unit group number (in the prim name) and its own link number.  The root prim can then recieved the messages and save the messages for future use.   (In my situation, the main prim of each group with also have to know the linknums of its constiuants.)

The negative of using this approach is that I  will have to add scripts into each prim (if  each prim does not already have one).

Is there a simpler way to address links by name? 

 

 

[Rolig Loon]

You can do it either of two ways.  One way, as you say, is to put a routine into state_entry that polls all of the prims to put them into groups...

integer i;while (i < llGetNumberOfPrims() ){    ++i;    if (llGetLinkName(i) == "Door")    {        gDoors += [i];    }    else if (llGetLinkName(i) == "Window")   {        gWindows += [i];    }}

Then you can use SLPPF anywhere later in your script to address all of the doors by referring to their link numbers stored in gDoors, and all of the windows by their link numbers in gWindows.

The other way is to poll the links as you need to.

integer i;while( i < llGetNumberOfPrims() ){    ++i;    if (llGetLinkName(i) == "Door")    {        llSetLinkColor (<1.0,0.0,0.0>, ALL_SIDES);    }}

 

The second way saves you having to use memory for global lists, but it means you're having to poll all the prims in your linkset every time you turn around.

Of course, if you don't want to change all of the doors at once but merely identify a particular door, all you have to do is ask

if (llGetLinkName(llDetectedLinkNumber(0)) == "Door")  // Do something to this link

which doesn't depend on either method.

 

 

[Malestorm1488303118]

Perfect.   Thanks you so much!!!

 

[Rolig Loon]

It occurs to me to point out that if you use the first method that I just outlined, you can simplify the way you use SLPPF by using PRIM_LINK_TARGET, as in ...

touch_start(integer total_number)    {        gON=!gON; //basic on/off switch        integer i =1;        list Params;        list WhichWay;  //Conditions which will change on touch        if(gON)       {            WhichWay = [PRIM_COLOR,ALL_SIDES,<1.0,0.0,0.0>,1.0]; // Red door        }        else       {            WhichWay = [PRIM_COLOR,ALL_SIDES,<1.0,1.0,1.0>,1.0];  //White door        }        while(i<llGetNumberOfPrims())       { //build the parameters list, in the format PRIM_LINK_TARGET, link number, parameters            Params+=[PRIM_LINK_TARGET]+[llList2Integer(gDoors,i)]+WhichWay;            i++;        }        llSetLinkPrimitiveParamsFast(LINK_SET,Params); //apply the parameters to all 'Door" prims    }