llSetLinkPrimitiveParams() problem

[Phil Deakins]

I'm trying to use llSetLinkPrimitiveParams() to change the rotation of a linked prim.

It's a 6 prim object and the script is in prim #2, prim #1 being the root, and this is the line I'm using:-

llSetLinkPrimitiveParams(n, [PRIM_ROTATION, rot]);

'rot' is acquired from the root prim (the root prim's rotation) and it correct.

The problem is that it rotates the wrong prim (one prim down); e.g. if 'n' is 4, then prim #3 is rotated.

I'm trying to rotate the highest numbered prim (#6) but I can't rotate that one at all. If I set 'n' to 6, then prim #'5 rotates. If I set 'n' to 7 to allow for the 1-prim-down oddity, no prim rotates.

I think I'm right in thinking that, with multi-prim objects, the prims are numbered from 1, so instructiong prim #6 to rotate in a 6-prim object, the highest numbered prim (#6) should rotate.

Anyone got any thoughts?







[Dora Gustafson]

Prims are numbered a bit differently than what is used elsewhere in LSL

• An unlinked prim is number 0
• In a linkset the root is number one
  In a linkset with say 5 prims the prims are numbered: 1,2,3,4,5

But you have noticed that so my guess is that you have a logical error somewhere in the script:)

[PeterCanessa Oh]

Sorry Phil, can't re-create.  I'm going to have to say "are you sure n is correct".  More to the point, can you post the script so WE can be sure n is correct.

Tested link-numbers using the following script in both root and each child prim in turn:

 

vector Colour;integer Counter;default{	state_entry(){		Counter = llGetNumberOfPrims();		llSetTimerEvent(2.0);	}	timer(){		if(llGetNumberOfPrims() <= Counter){			Counter = 0;			Colour = <llFrand(1.0), llFrand(1.0), llFrand(1.0)>;		}		llSetLinkPrimitiveParams(++Counter, [PRIM_COLOR, ALL_SIDES, Colour, 1.0]);	}}

 

PS: http://wiki.secondlife.com/wiki/LlSetLinkPrimitiveParamsFast - save yourself a 0.2s delay every call (if you want to).

[Phil Deakins]

This is the code:

 

}else if(button == "test"){    rotation rot = llGetRootRotation();    integer n = llGetNumberOfPrims();    llOwnerSay("test button: " + (string)n);    llSetLinkPrimitiveParams(n, [PRIM_ROTATION, rot]);}

 

It's self-contained, so there's nowhere for there to be a logical error.

If I use an integer instead of n, the prim below the integer will rotate. E.g. if I put 4 instead of n in the llSet... line, prim 3 will rotate and not prim 4.

[Phil Deakins]

I use the fast version for actual use. This is just an extra test button to make sure the right prim is rotated. In use, the highest numbered prim will be an avatar but I wasn't having much joy with it, so I stuck that bit of code in to make testing the system simpler.

The programme is to rotate the av with respect to the root, plus the av's rotation. Using a prim to test with, I can set the prim's rotation much more easily, which makes testing the combined rotations much easier.

[Innula Zenovka]

I still can't replicate it.  This reliably turns the last prim in the linkset red.

 

default{    state_entry()    {       integer max = llGetNumberOfPrims();       llSetLinkPrimitiveParamsFast(max,[PRIM_COLOR,ALL_SIDES,<1.0,0.0,0.0>,1.0]);    }}

 ETA

And this reliably turns me round when I'm sitting on the object, while leaving the last prim unmoved:

 

rotation z45;default{    state_entry()    {       z45 = llEuler2Rot(<0.0,0.0,45.0>*DEG_TO_RAD);       llLinkSitTarget(llGetNumberOfPrims(),<0.0,0.0,0.5>,ZERO_ROTATION);    }    touch_start(integer total_number)    {       integer max = llGetNumberOfPrims();       rotation rot = llList2Rot(llGetLinkPrimitiveParams(max,[PRIM_ROT_LOCAL]),0);       llSetLinkPrimitiveParamsFast(max,[PRIM_ROT_LOCAL,z45*rot]);    }}

 

[Phil Deakins]

To try it without the rest of the script, I made another 6-prim object (just flat prims) and, with a few changes to make it stand alone, I put that tiny bit of script into the #2 prim (#1 being the root, of course), and I'm getting some strange results. I actually managed to rotate the highest prim by putting 2 instead of n in the llSet... line.

I removed the script from prim #2 and put it in the root. I still get the same oddities; e.g. setting n to 2 rotates prim #6.

I should say that I'm getting the prim numbers from the Edit box in Phoenix, but prim #6 was the last to be added to the object so it should be #'6 and phoenix reports it as being #6.

If anyone fancies playing with this test object and script, you are more than welcome to do so. Right now, it's a mystery to me.

[Phil Deakins]

I tried just changing the highest prim's colour, as per you first bit of code, Innula, and I get the same results as I do with rotations. To change prim #6, I have to set n to 2. Setting n to the the primcount (6) changes prim 5.

I'm at a complete loss.

ETA: I should say that avs on the object have been working fine. It's just that I want to do it with actual prims for ease of testing (me needing a fair amount of testing when it comes to placing a prim/av in a rotation with respect to the root prim, regardless of the root prim's rotation), and it's just not working.

[Innula Zenovka]

I think the clue to the problem is that you're relying on the numbers in the Phoenix edit box, which are unreliable.  

Use this script to test what the link numbers actually are, as opposed to what you may think they are:

default{	state_entry()	{		//llSay(0, "Hello, Avatar!");	}	touch_start(integer total_number)	{		llOwnerSay("You touched link number "+(string)llDetectedLinkNumber(0));	}}

 

[Phil Deakins]

Bloody hell! That's the answer, Innula. Thank you!

When operating avs on the main object, I used the prim count, which is fine. When an av gets on, it becomes the highest numbered prim. I assumed that adding a real prim to an object causes that last addition to be the highest numbered as well, but it doesn't. The test object is working as expected. The last added prim is actually prim #2. Phoenix reports the wrong link numbers. I wonder where it gets them from - and why, since they don't have any use.

[PeterCanessa Oh]

In normal editing the last prim included in a linkset becomes the root (link 1).

[Innula Zenovka]

It's a long-standing, and known, issue:http://jira.phoenixviewer.com/browse/PHOE-1372

The most recent comment from one of the Phoenix team is

---

Link order isn't something the sim keeps the viewer updated on the exact link order of since it wouldn't normally make a difference.

---

This might cause you to think, as it did me, "but, if someone wants to know the link number, then it's probably not because of idle curiosity but because it does actually make a difference to whatever they're trying to do".   

Whatever Phoenix are thinking of, it's best to ignore the numbers there and test by script (or, which I usually do, forget about link numbers altogether and use the prim descriptions instead).

[Phil Deakins]

Sorry. My brain went out briefly. Yes, the last one to be selected, when linking a whole set, becomes the root. I worded it badly, but I was meaning when adding a prim  to an existing link set. I expected that last one (the added one) to have the highest prim number like an avatar has, but it doesn't - at least not necessarily.

[Phil Deakins]

Interesting, Innula. Thank you for finding that.

Having link numbers in Phoenix turns out to be a negative aspect of the viewer. It certainly wastes people's time occasionally, like it did today. I treated it as a big positive, which I'm sure it was at one time. If they do another Phoenix update, which is probably unlikely, they need to get link numbers up to date or remove it altogether. As it is now, it can mislead people into wasting their time - and not just a few minutes of time.

[Rolig Loon]

I've been fooled by that one more than once too.  I've taken to dropping a handy code snippet into scripts temporarily while I still need to figure out which face is which. 

[Innula Zenovka]

A voice from beyond has drawn my attention to the specification note to llCreateLink :

---

The prims for the child object (target if parent is TRUE, script's object if parent is FALSE) are inserted into the parent object's link set starting at link number 2. For example, if the link order for the parent object is A1, A2, A3 and the link order of the child object is B1, B2, B3, then the link order of the resulting object will be A1, B1, B2, B3, A2, A3.

---

So it seems that linking prims manually works the same way.   That is, the link number of any single prim you later add to a linkset is going to be 2.

[Phil Deakins]

That's interesting, Innula. An avatar goes to the end of the object's links list but another object in inserted right after the root prim.

For me in this case, having the added test prim as #2 instead of going to the end makes no difference, as it doesn't matter which number I specify as long as the test prim is the one acted upon. But it was darned confusing, particularly since Phoenix shows the wrong number until the whole object has been taken into my inventory and rezzed again. But I won't do that. I'll just work with prim #2.