Handy Low wrote: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).

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):

Handy Low wrote: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):

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.

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).