0008108: Link number changes after reboot region

(0031518)
Mandarinka Tasty (reporter)
2017-01-01 13:29

Hello )

Yes, I confirm it, viewer shows inappropriate link number after region restart,

while using edit linked. But when you use, llGetLinkNumber, correct value is returned.

default
{
    touch_start(integer num)
    {
        llOwnerSay((string)llGetLinkNumber());
    }
}

Anyway, the viewer should show show correct link number, no doubts in it.

(0031575)
Total Sorbet (reporter)
2017-01-26 15:47

Ive noticed this on singularity 1.8.7 too :(

(0032063)
dz (reporter)
2017-06-24 10:35

Linksets are not "stable" in that way.

If you rely on the link number you need to label each of the linked objects and refer to it either by name, or through a table you build to associate the object name to its current link number...

Only the root prim of the linkset is guaranteed to remain as "0".

(0032067)
djphil (reporter)
2017-06-25 03:48
edited on: 2017-06-25 03:50

@dz: Sorry but for here the link number of root prim in a linkset is allways "1", NOT "0".

(0032071)
BillBlight (developer)
2017-06-25 18:35

And there is also the new function that Ubit added, osGetLinkNumber(string name)

http://opensimulator.org/mantis/view.php?id=8142 [^]

(0032077)
djphil (reporter)
2017-06-26 03:09

Thank you watcher64

I did not know the existence of this new OSSL function
It must be said that the Opensim wiki is so badly maintained up to date that this is not really surprising.

That said, even with osGetLinkNumber, the prim root in a linkset remains "1" and not "0".

(0033720)
Jim Tarber (reporter)
2019-01-05 11:33

"Yes, I confirm it, viewer shows inappropriate link number after region restart,
while using edit linked. But when you use, llGetLinkNumber, correct value is returned."

There is a well-known bug in Firestorm that it reports unreliable link numbers. There's a reason other viewers don't include this info, it's not reliable and will report the wrong ones. This does not appear to be a bug in OpenSim in any way, as the second sentence quoted above confirms, but rather that the user is using a buggy measuring tool (Firestorm in this case). The well-known Firestorm bug is documented here:
https://jira.phoenixviewer.com/browse/FIRE-4292 [^]
and originally here:
https://jira.phoenixviewer.com/browse/PHOE-1372 [^]
with a duplicate report:
https://jira.phoenixviewer.com/browse/PHOE-1848 [^]

Folks, you can probably close this one as a bug in Firestorm, not a bug in OpenSim.

(0033721)
UbitUmarov (administrator)
2019-01-05 12:00

link number is not a prim property transmitted on protocols
it is also only really defined for root, ie 0 on a single prim, 1 on a link set (or if a avatar sitting).

we can only expect good viewers close match with os region, on first login and with zero packet loss.

we try to keep coherence internally.
But even that is maybe not good enough for some scripts, reason why i added that function.

dj that function is at wiki http://opensimulator.org/wiki/OsGetLinkNumber [^]

(0033722)
UbitUmarov (administrator)
2019-01-05 12:12

well zero packet loss, and if udp packet order is by miracle preserved...

(0033724)
Jim Tarber (reporter)
2019-01-05 17:10
edited on: 2019-01-05 17:11

Exactly, it is not something the viewer can readily track reliably, thus any reports of incorrect prim link numbers need to be redirected to viewer bug reporting, as they are not OpenSim (or Halcyon) bugs. Anything else is implementation and network-dependent (i.e. unreliable).

My point was that this problem with Firestorm (specifically) reporting the wrong link number is a Firestorm-specific bug, actually the bug is reporting something coincidental as hard fact to the user in the user interface at all, when only the server is (and thus also scripts are) the only authority on link numbers.

(This is not an OpenSim bug. It is a Firestorm bug.)

Notes
(0031518) Mandarinka Tasty (reporter) 2017-01-01 13:29	Hello ) Yes, I confirm it, viewer shows inappropriate link number after region restart, while using edit linked. But when you use, llGetLinkNumber, correct value is returned. default { touch_start(integer num) { llOwnerSay((string)llGetLinkNumber()); } } Anyway, the viewer should show show correct link number, no doubts in it.

(0031575) Total Sorbet (reporter) 2017-01-26 15:47	Ive noticed this on singularity 1.8.7 too :(

(0032063) dz (reporter) 2017-06-24 10:35	Linksets are not "stable" in that way. If you rely on the link number you need to label each of the linked objects and refer to it either by name, or through a table you build to associate the object name to its current link number... Only the root prim of the linkset is guaranteed to remain as "0".

(0032067) djphil (reporter) 2017-06-25 03:48 edited on: 2017-06-25 03:50	@dz: Sorry but for here the link number of root prim in a linkset is allways "1", NOT "0".

(0032071) BillBlight (developer) 2017-06-25 18:35	And there is also the new function that Ubit added, osGetLinkNumber(string name) http://opensimulator.org/mantis/view.php?id=8142 [^]

(0032077) djphil (reporter) 2017-06-26 03:09	Thank you watcher64 I did not know the existence of this new OSSL function It must be said that the Opensim wiki is so badly maintained up to date that this is not really surprising. That said, even with osGetLinkNumber, the prim root in a linkset remains "1" and not "0".

(0033720) Jim Tarber (reporter) 2019-01-05 11:33	"Yes, I confirm it, viewer shows inappropriate link number after region restart, while using edit linked. But when you use, llGetLinkNumber, correct value is returned." There is a well-known bug in Firestorm that it reports unreliable link numbers. There's a reason other viewers don't include this info, it's not reliable and will report the wrong ones. This does not appear to be a bug in OpenSim in any way, as the second sentence quoted above confirms, but rather that the user is using a buggy measuring tool (Firestorm in this case). The well-known Firestorm bug is documented here: https://jira.phoenixviewer.com/browse/FIRE-4292 [^] and originally here: https://jira.phoenixviewer.com/browse/PHOE-1372 [^] with a duplicate report: https://jira.phoenixviewer.com/browse/PHOE-1848 [^] Folks, you can probably close this one as a bug in Firestorm, not a bug in OpenSim.

(0033721) UbitUmarov (administrator) 2019-01-05 12:00	link number is not a prim property transmitted on protocols it is also only really defined for root, ie 0 on a single prim, 1 on a link set (or if a avatar sitting). we can only expect good viewers close match with os region, on first login and with zero packet loss. we try to keep coherence internally. But even that is maybe not good enough for some scripts, reason why i added that function. dj that function is at wiki http://opensimulator.org/wiki/OsGetLinkNumber [^]

(0033722) UbitUmarov (administrator) 2019-01-05 12:12	well zero packet loss, and if udp packet order is by miracle preserved...

(0033724) Jim Tarber (reporter) 2019-01-05 17:10 edited on: 2019-01-05 17:11	Exactly, it is not something the viewer can readily track reliably, thus any reports of incorrect prim link numbers need to be redirected to viewer bug reporting, as they are not OpenSim (or Halcyon) bugs. Anything else is implementation and network-dependent (i.e. unreliable). My point was that this problem with Firestorm (specifically) reporting the wrong link number is a Firestorm-specific bug, actually the bug is reporting something coincidental as hard fact to the user in the user interface at all, when only the server is (and thus also scripts are) the only authority on link numbers. (This is not an OpenSim bug. It is a Firestorm bug.)

Issue History
Date Modified	Username	Field	Change
2017-01-01 12:10	djphil	New Issue
2017-01-01 13:29	Mandarinka Tasty	Note Added: 0031518
2017-01-26 15:47	Total Sorbet	Note Added: 0031575
2017-06-24 10:35	dz	Note Added: 0032063
2017-06-25 03:48	djphil	Note Added: 0032067
2017-06-25 03:50	djphil	Note Edited: 0032067	View Revisions
2017-06-25 03:50	djphil	Note Edited: 0032067	View Revisions
2017-06-25 18:35	BillBlight	Note Added: 0032071
2017-06-26 03:09	djphil	Note Added: 0032077
2019-01-05 11:33	Jim Tarber	Note Added: 0033720
2019-01-05 12:00	UbitUmarov	Note Added: 0033721
2019-01-05 12:12	UbitUmarov	Note Added: 0033722
2019-01-05 17:10	Jim Tarber	Note Added: 0033724
2019-01-05 17:11	Jim Tarber	Note Edited: 0033724	View Revisions

Relationships