Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008108opensim[REGION] OpenSim Corepublic2017-01-01 12:102019-01-05 17:10
Reporterdjphil 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformPCOSWindowsOS VersionSeven
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0008108: Link number changes after reboot region
DescriptionWhen you create a basic linkset build, taking care to link the prims in a very specific order, After you restart your region and you find that the numbers of your link is no longer the same.

I use Firestorm viewer editor "edit linked" option to verify number and i notice that the numbers have changed.

OSgrid 0.9.1.0 (Dev) eabd8cb: 2016-12-18
git hash : eabd8cbe48b2b4af3fc9c04b695f4d5ebe561fcb
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineubODE
Environment.NET / Windows32
Mono VersionNone
ViewerFirestorm
Attached Files

- Relationships

-  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


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker