Quick Q: Does removing a link from a linkset just drop all the higher link numbers down one?

[Rick Nightingale]

Hopefully someone will know the answer to save me doing hours of testing to confirm it...

If I remove a linked item from its linkset (using llBreakLink if it matters) do all the link numbers above that one simply drop down by one?

So... if I remove link number 6, then what was link number 7 will now be 6, 29 will now be 28, etc.

It will save me having to relist the whole linkset every time.

Edited April 10, 2023 by Rick Nightingale

[Rolig Loon]

That's the way it is supposed to work, but I don't think I have ever trusted it.  If I anticipate changing links, I put code in a changed event to grab all the numbers of the important links on CHANGED_LINK.  A little bit of OCD saves a world of worry later.

[Rick Nightingale]

Thank you. Yeah, I know what you mean!

I've gone ahead on the basis that I'm right and so far it all works, inserting added prims at index 2 in my table (as per the wiki) and deleting them using llDeleteSubList() for removal. I'm just doing one prim at a time to save headaches although I might upgrade to adding whole linksets for more speed.

I'll let it run for a while and watch it. I guess it only takes a bit of a second to rescan the linkset after each change, but with script injection, link breaking, rezzing, link making, positioning and other stuff for up to twenty prims or so it already takes a while to reconfigure the object.

Edited April 10, 2023 by Rick Nightingale

[OptimoMaximo]

16 hours ago, Rick Nightingale said:

Thank you. Yeah, I know what you mean!

I've gone ahead on the basis that I'm right and so far it all works, inserting added prims at index 2 in my table (as per the wiki) and deleting them using llDeleteSubList() for removal. I'm just doing one prim at a time to save headaches although I might upgrade to adding whole linksets for more speed.

I'll let it run for a while and watch it. I guess it only takes a bit of a second to rescan the linkset after each change, but with script injection, link breaking, rezzing, link making, positioning and other stuff for up to twenty prims or so it already takes a while to reconfigure the object.

I would not trust any system that does not implement a basic hierarchy to begin with.

In my opinion, you'd be safer and better off making a few sorting methods in order to collect the link numbers of key elements based off some properties.

[ChinRey]

On 4/10/2023 at 2:15 AM, Rick Nightingale said:

If I remove a linked item from its linkset (using llBreakLink if it matters) do all the link numbers above that one simply drop down by one?

So... if I remove link number 6, then what was link number 7 will now be 6, 29 will now be 28, etc.

I did a quick test with a six prim linkset and yes, this is how it worked in that particular case. But just Rolig and Optimo, I do not trust it, at least not until we have a lot more test results.

Btw, as a bonus I think I stumbled across a pattern in Firestorm's incorrect link part numbering. Maybe we can finally get that old bug fixed now?

[Rick Nightingale]

Hmm... I certainly understand the feeling. It seems half my LSL code at times is to check for and mitigate things that don't go as expected or suddenly take 30 seconds instead of a millisecond.

I'm going to roll with it as is though (appropriate since it has wheels). So far, maybe a hundred automatic reconfigurations in the beta grid, premium sandbox and my home have all gone perfectly. There are about 50 mesh objects in the linkset, about half of which can be replaced at the press of a button, up to twelve at a time the way I've set the command HUD up.

3 hours ago, ChinRey said:

Btw, as a bonus I think I stumbled across a pattern in Firestorm's incorrect link part numbering. Maybe we can finally get that old bug fixed now?

Do you mean the in-world numbering not matching the script-reported numbering? That is somewhat annoying at times.