llGetLinkName(LINK_THIS) doesn't work in the root prim????

In the root prim of a linkset this will not work:

default
{
    

    touch_start(integer total_number)
    {
        llSay(0,  llGetLinkName(LINK_THIS));
    }
}

But replacing LINK_THIS with either 1 or LINK_ROOT works fine. Per the wiki shouldn't all 3 of them be the same?

http://lslwiki.com/lslwiki/wakka.php?wakka=link
Notice at the bottom of that page, LINK_THIS is actually equal to -4. So, your script is trying to get the name of the prim, with link number -4. Instead, use:

llGetLinkName(llGetLinkNumber());

I could accept that, but that same script works fine when it is in a child prim
EDIT. If you put that script in a child prim, then it returns the name of the root prim.

From the wiki on Link:


So these are not link numbers, just ways to select various prims in a linkset for those three lsl opcodes.

Correct. But this should get the name of the prim it is in: llGetLinkName(LINK_THIS)); .

EDIT: Sorry if you put it in the root it will return the name of the child prim and if you put it in the child then it will return the name of the root. Very strange

No, as it says, it only works with llMessageLinked, llSetLinkAlpha, and llSetLinkColor, because those functions are designed to handle more than one link at a time. llGetLinkName only ever deals with one link at a time (llGetLinkName(LINK_SET) doesn't make any sense), so it follows that it shouldn't support multi-link constants (even though one of them is a convenience for specifying a single link in a function that can accept multiple links).

All of that makes no sense at all.
Get the script and throw it in a linkset and see the results. Try first in a root prim and then a child prim. Per the wiki llGetLinkName(LINK_THIS()) is a logical query and SHOULD return the name of the prim it is in. But it doesn't.

*shrug* makes perfect sense to me.

I could try to re-explain it using different words, but it really boils down to this:

Any link call which does not normally support handling of multiple links in one call (llBreakLink, llGetLinkName, et cetera) also does not support ANY of the LINK_ constants, including LINK_THIS, because the constants were made SPECIFICALLY for the multi-link calls. LINK_ROOT is a special case, since it basically just returns the normal value for a multi-prim object's root link number.

You could add it as a feature request, but I don't see why it is needed, when llGetLinkName(llGetLinkNumber()); will work just fine.

errrrrrrrrr!!!!
These work when placed in the root prim of a linkset. Root prim is named "root", child prim is named "child"

default 
{ 
    touch_start(integer total_number) 
    { 
        llSay(0,  llGetLinkName(1)); 
    } 
} 

Returns "root"

default 
{ 
    touch_start(integer total_number) 
    { 
        llSay(0,  llGetLinkName(LINK_ROOT)); 
    } 
} 

returns "root"



But this does not work!!!!!!!!

default 
{ 
    touch_start(integer total_number) 
    { 
        llSay(0,  llGetLinkName(LINK_THIS)); 
    } 
} 

returns "child"
Per the wiki : LINK_THIS The prim the script is in.
But the script is not in the prim named "child", it is in the prim named "root".
Furthermore if you take the script out of the root prim and put it in the child prim then when you touch it it will say "root". It is completely backwards.

It's already been said above, but in case you missed it:



They don't work with any other link function (ie, none of the other link functions support the NEGATIVE LINK NUMBER SPECIAL CASES), it is intended to be this way, it isn't a bug, and it makes sense (to me, anyway).

Scream at the Lindens if you must, but I don't see the problem.

Jesse, run your test in an object with more than two prims. You're testing with just a root and a child. Basically, you're doing a llGetLinkName(-4)... run your test with other negative numbers to see what other oddball results you get.

But, also test with a 3 or 4 prim object. It appears that the function doesn't recognize the negative value of the link constants. It returns non-expected results. You need to run llGetLinkName() with a valid link number to get a valid result. LINK_ROOT seems to work because the constant is equal to 1, a valid link number.

FYI, you also can't test a link message with the link constants. For instance, send a link message from one script in a prim to another script in the same prim using LINK_THIS. On the receiving script, test with if (sender == LINK_THIS) llOwnerSay("message received";. It doesn't work. You have to test with if (sender == llGetLinkNumber()) for a message sent to LINK_THIS to be received.

ah well I recognise the problem with it and can go from there anyway. Back in Beta. We have planar mapping and hide & seek fixed and waiting for tomorrow now!!!!

This pretty much looks like a bug to me; please report it.

Out of morbid curiosity, have you tried

llSay(0,(string)llDetectedLinkNumber());
If in the root prim it'll return 0, or 1..... but you can touch the other prims and usually get a reading.

Yep that works fine and returns the root number. I guess they were just kind of sloppy when they through LINK_THIS code together. It does work fine under the conditions it is supposed to. Under this condition, one would have expected it to either return a NULL_KEY or empty string or to work correctly, instead of working backwards.

Also tried with a 4 prim set. In the root it will say the name of the last prim #4. In any of the child prim, it will say the root prim name. Guess more of an Annoyance then a true bug and i'll add a note to the wiki sometime about it. Plus I encountered a Gotcha a couple of weeks ago and should add confirmation for it:

"Also, it seems that kinetic functions inside non-root prims in attachments are non-functional regardless. Not sure if this is new but I don't remember it being like that. Only tested briefly, so confirmation would be appreciated."

That statement is true. My Flight Assist works fine as a hud attachment but when I took that attachment and made it a child in a linkset, it refuses to work. Make it the root and it works fine.

The wiki SPECIFICALLY SAYS that the LINK_xxx constants are "used by the functions llMessageLinked, llSetLinkAlpha, and llSetLinkColor."

So it makes PERFECT sense that it doesn't work in llGetLinkName.

If you observe, LINK_ROOT works in llGetLinkName in a link set because it just HAPPENS to have the value of 1. However, it will NOT work in a lone prim, because its link number is 0.

Constants are constants. They aren't intelligent or adaptive. It's the programmer's repsonsibility to know what values he's passing.

"It does work fine under the conditions it is supposed to. Under this condition, one would have expected it to either return a NULL_KEY or empty string or to work correctly, instead of working backwards."