some questions about linksets

Hi, This is not for a specific project. It is just to widen my understanding - so, Imagine the wellknown 'magic teacup fair' : Some persons enters a 'cup-like' cart and are spun and rotated on a curvy base path.
If we model this is sl, it would be a root as the 'base' and 1..n child 'cups' with 1 seat-target each.
At least this simplification is sufficient to descripe the model and the questions that this rises.
My understanding of the dynamic linkset is that when an avatar (av) sits on the target, the av will become a 'child' of the -root-!
The ROOT, Correct?
If we have a linkset with one root (duh..) and 5 child-prims we will have a 1+6 linkset when an av sits in a target.
How would we get the linknumber -dynamically- for the new child, that is in fact the avatar, at the change (& CHANGED_LINK) event?
llAvatarOnSitTarget() will return a key, not a linknumber..
llDetectedLinkNumber(0) from the 'change' returns '0' -that seams to be the whole linkset?
so -how do we obtain the specific av's linknumber?
Will the av at all 'respond' -as- a child to llSetLinkPrimitiveParams..?
If not, can we manipulate (rotate/move) the av at all?

tyia
ab

Just some speculation...

You don't rotate/move the Avatar, but the Prim it's sitting on. Thus, you don't have to worry about the AVs linknumber. And - I believe an Avatar won't become a «child» of the linkset...

But I'm quite sure that you could only attach 1 Avatar per cup, since otherwise, you would have to have poseballs in the teacup - which brings up the old problem of not being able to make child-child-linksets.

But then again - I think I might just read my printout again

The llDetected* functions only return information about sensor, collision, and touch events. So, it won't work properly in the changed event.

// Returns a list containing the link numbers of all avatars sitting on the object.
list GetAgentLinks()
{
	list lLinks = [];
	integer a = llGetNumberOfPrims();
	if(a > 1)
		while(llGetAgentSize(llGetLinkKey(a)))
			lLinks = (lLinks=[]) + [a--] + lLinks;
	return lLinks;
}

Yes, you can use llSetLinkPrimitiveParams to modify the avatar's position and rotation.

Thank you for your replies!
I am however now a litle confused.
In this thread
/54/16/266064/1.html
It is stated that rotation of an av is not posible.
I am on the other hand very happy about the posibillitie to se a list over links for a linkset -That will be neat!
Thanks Cory!
Haruki, it is true that it is the prim that has the seat target that can be moved, but when the av sits on a child it is bound to the root, in respect to motion, so moving the child (could be a poseball) will not -dynamically- infuence the -sitting- av. Only if the av 'unsits' and 'resits' the difference will be showed.
If we on the other hand moves the root, then the sitting av will dynamically move with all the roots movements -Or..? Correct me if i am wrong :)
BR ab

When an avatar sits on a linkset, said avatar becomes part of the linkset and thus can be moved and rotated within the constraints of said linkset.

Also, Avatars are added at the end of the link chain. So if you know your number of prims in the linkset you can assume that any number higher than that is an avatar that is sitting on the linkset. llgetAvatarOnSitTarget() will always only return the key of the first avatar to sit on the linkset and will return NULL_KEY once they stand up. No matter whether there are other avatars present which sat down after the first one on the linkset.

To make things really easy, refer to avatars using negative numbers. -1, -2, -3 and so on. Like, if you have a 6-prim linkset which now reports 9 prims in the linkset, you can refer to the avatars via -1, -2, -3 or 7, 8, 9. Either will work.

I hope this doesn't confuse you too much.

See /54/b2/265500/1.html#post2036869

Thanks for your inputs! cant emagine it is as simple as just referring to the linkcount+1 to get the actual av's linknumber :)
Using negative indexes is real clever! -and Squirrel, you definately did not confuse anything , you nailed it ;)

I would however like to ask about two lines in the function:
'while(llGetAgentSize(llGetLinkKey(a)))..'
That 'llGetAgentSize' that would be a way to check whether ot not an agent is part of the linkset..? -yes, but

'lLinks = (lLinks=[]) + [a--] + lLinks;'
so..
'lLinks = (lLinks=[])'
the list lLinks is initialized -in fact 'emtied' -right?
'+ [a--]'
is added the post decremented integer.. Why?
'+ lLinks;'
and -then- added its current total content once more? Why?
Is the purpose to only 'keep' the last seated avi?
Hewee does something similar in the script he referes to (thanks Hewee:)
'sitters = (sitters=[])+sitters+[ linkKey ];'
again the list is initilized in the loop
hmm..

Actually, no. This is a receipe to fool the stupid LSL cook. When you write:

myList = myList + [something];

The stupid cook behind the screen do it very literally. He makes a copy 'myList' to which he adds 'something'. And if your list is big enough, there isn't enough room in the LSL kitchen for all this and you got the cryptic message: "Your heap collided with your stack"... (more or less). In clear, there isn't enough memory left.

When you write:

myList = (myList=[]) + myList + [something];

The cook --who is very literal-- begins with a copy of an empty list to the end of which he attaches 'myList' and 'something'. So the result is what we want... minus the unnecessary copy of 'myList'.



This is another trick to keep the memory use under control. The less instructions you use, the more memory remains. So instead of 2 lines:

myList = (myList=[]) + myList + [variable];
--variable;

One is enough:

myList = (myList=[]) + myList + [variable--];

So, 'variable' is used (added to the end of the list) and then decremented. That's what the word "post-decremented" means.

In Cory code, the list is built backwards --from the end-- so the resulting list will be in ascending order. In verbose memory-hungry style:

lLinks = [a] + lLinks;
--a;

*IF* what I know about the linksets also applies to sitting avies, the last sitted AV will be the first in the list. So you can use negatives indices:

llList2Integer(lLinks, -1) will be the link number of the first sitted AV.
llList2Integer(lLinks, -2) will be the link number of the second AV, etc.

If you re-build your list every time an AV sits or stands up, no problem... *IF* I'm not wrong about how newly sitted avies are inserted in the linkset.

It checks whether the key represents an avatar. If llGetAgentSize() returns ZERO_VECTOR, I assume it is a normal prim in the link set and that we have already found all avatars (who are all added at the end of the link set). I do wonder how that is going to perform at region boundaries though. Might be worth some testing.

Anyway, if you already have an avatar key from a sit target, you can skip that step and just look for the known key in all the link set members from 1 to llGetNumberOfPrims() (link sets are one-based when there is more than one member, not zero-based).

Kaluura, Hewee, Thank you to both of you for explaining these isues!
BR ab.