Edit Dialog gives wrong link number

[Ilan Tochner]

Okay, good to know.

Thank you for helping us trace down the source of the problem Handy.

[Mike Lorrey]

It does seem to be client-side, at least according to this thread in the Firestorm JIRA. And it's not just Firestorm, but all viewers, and it's at least 7 years old. In fact, it's likely that the number shown never was reliable.

They mention that if a linkset is re-rezzed the link numbers are OK. That would explain why you weren't able to see the problems with Mike's test object.

Well I've rerezzed it twice and the link numbers the edit dialog shows still do not agree with the link numbers that llGetLinkNumber()returns and which the script must use to do any sort of prim manipulation function. I have given up on trying to use this keypad as a linkset, and am working on a 1 prim mesh keypad (which has its own issues, as it appears the llDetectedTouchedFaceUV indexing goes from bottom to top and not top to bottom).

[Handy Low]

There's no need to redesign the whole object just because of this bug!

As Ilan says, you just need to use the name of the prim instead of the link number. Name each prim with the number it represents, and use something like this (at its simplest, and untested since I'm not logged in):

Code: Select all

string name = llGetLinkName(llDetectedLinkNumber(0));
if (name == "1") {
    // Processing for 1 key
}
else if (name == "2") {
    // Processing for 2 key
}
[etc]


Besides, this method has the advantage that you don't need to worry about the link order when you change the prims in the linkset. I never, ever use hard-coded link numbers in my scripts.

EDITED TO ADD: UV coordinates do generally have their origin at the bottom left, not the top left, so llDetectedTouchUV is correct. See this document about OpenGL UV mapping.

[Mike Lorrey]

There's no need to redesign the whole object just because of this bug!

As Ilan says, you just need to use the name of the prim instead of the link number. Name each prim with the number it represents, and use something like this (at its simplest, and untested since I'm not logged in):

Code: Select all

string name = llGetLinkName(llDetectedLinkNumber(0));
if (name == "1") {
    // Processing for 1 key
}
else if (name == "2") {
    // Processing for 2 key
}
[etc]


Besides, this method has the advantage that you don't need to worry about the link order when you change the prims in the linkset. I never, ever use hard-coded link numbers in my scripts.

EDITED TO ADD: UV coordinates do generally have their origin at the bottom left, not the top left, so llDetectedTouchUV is correct. See this document about OpenGL UV mapping.

Hi Handy,
I generally don't like to add more coding to work around a bug, I find some other way to do it that isn't as processing intensive, one of the big problems with lag in opensim, as I am sure you know, is that people use way too many scripts with a whole lot of unnecessary coding, often due to amateur coding but also as often due to workarounds to get around bugs.

That said, I don't see any documentation that says you can use a prim name in llSetPrimitiveParamsFast() or other prim params manipulation functions, which is why I need link numbers to begin with. I could generate a list of link names from the start to generate each time its rezzed or state_entry, but list processing is also excessive computationally and memory wise. Going to a 1 prim mesh allows me to ignore this bug entirely, and eliminate all the link messaging going on in the old script, which saves even more on processing.

[Handy Low]

Hi Mike - sorry about the delay.

You can't use a prim name in llSetPrimitiveParamsFast() etc, so the best practice is to store the link number in a variable and use that. No need to use lists, just an integer for each key prim. I usually have a function that cycles through the prims in the linkset, testing the name of each prim and storing the link number of each necessary prim in an appropriate variable (the function is called at the beginning of the script and after a CHANGED_LINK event). Then you can use those values in functions and events that use or return link numbers.

This isn't just about coding round a bug, it's good practice. Especially if your users are ever going to relink the object, such as linking it into builds of their own (this happens a LOT with my products).