Limit on number of child prims with SetLinkPrimitiveParamsFast?

[Lilah Munster]

Hi. Clueless scripting neophyte here. I have a script that works beautifully in a 32 prim necklace, but not in a 176 prim belt. In the belt, it's applying the texture and color changes to the wrong link numbers in the set. I can post the entire script if needed, for now here's a segment from the texture change section: if (m=="black") llSetLinkPrimitiveParamsFast(1, [PRIM_TEXTURE, ALL_SIDES, black, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0]) ; if (m=="black") llSetLinkPrimitiveParamsFast(3, [PRIM_TEXTURE, ALL_SIDES, black, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0]) ; if (m=="black") llSetLinkPrimitiveParamsFast(4, [PRIM_TEXTURE, ALL_SIDES, black, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0]) ; if (m=="black") llSetLinkPrimitiveParamsFast(5, [PRIM_TEXTURE, ALL_SIDES, black, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0]) ; if (m=="black") llSetLinkPrimitiveParamsFast(6, [PRIM_TEXTURE, ALL_SIDES, black, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0]) ; Instead of changing link numbers 1, 3, 4, 5, & 6, it's consistently affecting 1, 42, 43, 44, & 45. ("m" is defined by a UUID at the beginning of the script.) Here's a snippet from the color change section: if (m=="silver") llSetLinkPrimitiveParamsFast(116, [PRIM_COLOR, ALL_SIDES, <1.00000, 1.00000, 1.00000> , 1.0]) ; if (m=="silver") llSetLinkPrimitiveParamsFast(117, [PRIM_COLOR, ALL_SIDES, <1.00000, 1.00000, 1.00000> , 1.0]) ; if (m=="silver") llSetLinkPrimitiveParamsFast(156, [PRIM_COLOR, ALL_SIDES, <1.00000, 1.00000, 1.00000> , 1.0]) ; if (m=="silver") llSetLinkPrimitiveParamsFast(162, [PRIM_COLOR, ALL_SIDES, <1.00000, 1.00000, 1.00000> , 1.0]) ; if (m=="silver") llSetLinkPrimitiveParamsFast(163, [PRIM_COLOR, ALL_SIDES, <1.00000, 1.00000, 1.00000> , 1.0]) ; if (m=="silver") llSetLinkPrimitiveParamsFast(164, [PRIM_COLOR, ALL_SIDES, <1.00000, 1.00000, 1.00000> , 1.0]) ; if (m=="silver") llSetLinkPrimitiveParamsFast(165, [PRIM_COLOR, ALL_SIDES, <1.00000, 1.00000, 1.00000> , 1.0]) ; if (m=="silver") llSetLinkPrimitiveParamsFast(167, [PRIM_COLOR, ALL_SIDES, <1.00000, 1.00000, 1.00000> , 1.0]) ; if (m=="silver") llSetLinkPrimitiveParamsFast(36, [PRIM_COLOR, ALL_SIDES, <1.00000, 1.00000, 1.00000> , 1.0]) ; Here, instead of 116, 117, 156, 162, 163, 164, 165, 167, & 36, it's affecting 70, 100, 101, 139, 166, & 170, and applying the wrong change to 116, 117, & 164. The script is in the root prims of both the working necklace and the wonky belt. I have checked, double checked, and triple checked my link numbers. I tried using SetLinkPrimitiveParams instead, thinking there was a problem with the lack of delay and so many child prims, and I have tried the belt in 2 different regions, one of which I was completely alone in - and 2,000 meters in the sky on a plywood platform. Same results. I am baffled. Any insight would be greatly appreciated while I still have hair remaining. :-)

[Darkie Minotaur]

Just a little remark: post code formatted as code - it makes it much easier to read it.

I haven't experienced any limitations to llSetLinkPrimitiveParamsFast yet - but I can't remember what the biggest object was I used it on.

How did you check the link numbers?

[Lilah Munster]

Argh. I thought I had formatted the code. Sorry about the giant chunk of text there I got the link numbers by checking "Edit linked parts" and selecting the prims one by one after it was linked up, and then after I found the script wasn't working, I went through it and looked to make sure I hadn't typo'ed anything.

[Darkie Minotaur]

Ok - I understand. I think that the number that are shown in the "Edit Linked Parts" view don't have to correspond with the link numbers.

I would follow a different path:

an assumption first: there are settings a user can make that afffect how some of the prims look (I guess variable m contains which choice the user has made). As an example, if the user chooses silver, certain parts change their colour accordingly.

 

• name the prims affectred in a certain way - eg, name all of them "colourchange"
• on a change, loop through all prims and apply the change to those named "colourchange"

Here's an example:

 

integer num = llGetNumberOfPrims();
while (num) {   if(llGetLinkName(num) == "colourchanger") {      llSetLinkPrimitiveParamsFast(num, [PRIM_COLOR, ALL_SIDES, <1.00000, 1.00000,
                                         1.00000> , 1.0]);   }   --num;
}

 

 

 

[Dora Gustafson]

Do you expect anybody to read that?:smileymad:

[Innula Zenovka]

I do that slightly differently.   I build, in state_entry, the attach event, the changed event and anywhere else that seems sensible, lists of prims I want to change, using something like this:

 

list leather_prims;list metal_prims;string leather = "leather";string metal = "metal";find_prims(){	leather_prims=[];	metal_prims=[];	integer max= llGetNumberOfPrims()+1;//link numbers start at 1, not 0	while(max-->1){        string s = llToLower(llStringTrim((string)llGetLinkPrimitiveParams(max,[28]),STRING_TRIM)); //LSLEditor doesn't know PRIM_DESC        if(s==leather){            leather_prims+=[max];        }        else if (s==metal){            metal_prims+=[max];        }     }}

 Then, when I want to change the metal prims, I say something like

 

max=llGetListLength(metal_prims);	while(max--){		llSetLinkColor(llList2Integer(metal_prims,max),colour,ALL_SIDES);	}

 I find that's far faster, in a large linkset, than checking the link name or description of every single prim each time (I'm in the middle of making a colour and texture changer for a ginormous jewellery set, so it's a matter much on my mind at the moment).

 

 

 

[Darkie Minotaur]

Nice - I got to remember that.

[Lilah Munster]

Thanks to everyone who offered help and suggestions. The problem turned out to be a region issue - the prims were showing different link numbers after a restart this morning, and the script is now working.

[Innula Zenovka]

I'm glad it's working again, but I would really strongly recommend considering some variation of Darkie's or my methods and  identifying the target prims by reading their link names or descriptions.    It's so much easier and less error-prone than hardcoding the actual link numbers, and you don't have to worry about having to redo everything if you decide later to alter the build.

[Void Singer]

there's also another option for storing prim identifiers that doesn't pollute the name/description fields, although it's a bit more involved.... and that to set their hovertext with an invisible value... it's not good for secure information, and it does require a little set up, but it leaves those other fields available and lets you store information that is discoverable by scripts in the object, but not outside of it.