Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002298opensim[REGION] OpenSim Corepublic2008-09-29 12:032010-02-15 18:50
ReporterUrsula Matova 
Assigned ToUrsula Matova 
PlatformDediboxProXLOSLinux Ubuntu (32bits)OS Version8.0.4 TLS
Product Version 
Target VersionFixed in Version 
Summary0002298: Linked prims problem - link order
DescriptionWell, I'm trying to create a "texture viewer". I have tried in OpenSim SVN.6142 and in SVN.6559.

So, I have a master prim with the main script in it. And I also have 10 more linked prims. I could identify the "link" number with a small script ( this is working ). The master prims and linked prims are well comunicating with llMessageLinked & link_message event ).

BUT: if I take back the linked object to my inventory ( or simply take a copy of the object ) and then re-rez it, all the "link numbers" changed.

For now, you cannot use some constants like "LINK_ALL_CHILDREN" or "LINK_SET", even if you use their values ( -2 or -1 here). So the workaround is to properly link the prims in the right order, identify their "link number" and use these numbers in your script ... ... It's not very clean, but working.

The other problem, is if you logoff/login back, the link numbers changed ...

It's very strange, and also very anoying.

(( don't know if my explanation is clear :S sorry ))
Additional InformationHumm :S
Seems to be solved in SVN.6579
- Re-rezzing the object ( root prim + 14 linked prims ) : Ok.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineODE
Script Engine
EnvironmentMono / Linux32
Mono Version2.4.2
Attached Files

- Relationships
related to 0002353closed Copying a linked set of prims can change the link order 
child of 0002870new META - Linking issues 

-  Notes
Ursula Matova (reporter)
2008-09-29 13:27


- Logoff/Login : no change on the linkset order ( maybe my mistake ),


Restarting OpenSim server change the linkset order. :S
Ursula Matova (reporter)
2008-10-04 00:15

Well, find a workaround for this ...
It's a bit ugly, but working :)

- Name prims in the linkset ( each name need to be unique ).
- From the main script ( in the Root prim ), count the number of prims, and then get all linkNumbers ( llGetLinkNumber ).
- Create a list, with these link numbers and use them in the main script.

I'll create a Wiki page for this, something like "Scripts Example". Could help some of you. :)
rjs (reporter)
2008-10-24 01:58
edited on: 2008-10-24 02:00

Debian 4.0 Stable - Mono 1.9.1 - ODE source compile

I can verify this to be a real issue. Restarting the servers is breaking all the link orders for all off my work thus far. This really should be moved up to very important.

I use Xengine only. I don't think that the scripting is what is posing the issues however. The scripts remain in the prims they should be in, but the prim linking numbering isn't holding on a server restart as mentioned here.

I hope we can find a resolve for this soon. Much of my linked items are trashed on restart and the scripted items are broke on a server restart due to this issue.


melanie (administrator)
2008-10-24 03:55

This is strange. At one point, I invested a significant amount of time into link number stability, changing all the linking/unlinking functions to preserve link numbers and also changing the rezzing (from xml) to do the same. I guess it needs to be looked at again, then ...
rjs (reporter)
2008-10-24 12:53

This is something relatively new within the last 20 revs I think.

I have a simple 20 prim item scripted with various listeners etc.. I deleted the main script, restarted the servers, took another look, and not only were all the links renumbered, or re-linked? But the script that was deleted was replaced in the prim on restart. Not sure what this means at this point, but when verifying that a single linked prim has a script removed, then restarting restored the deleted script and renumbered all the prims, it makes you wonder if it's more or less just scripted items that are posing the issue. I have other buildings with over 200 prims etc.. all linked non scripted that I've not noticed any isses with yet, but I haven't verified if the non scripted items are relinking. It's just quite noticeable when you have scripted items due to the scripts not working right.

I usually tell the scripts which prims to speak to by logical numbering of the prims and giving a random individual channel for each of the communications. So obviously this method would produce visible results right off when prim link issues arise.

thomax (reporter)
2008-10-27 04:47


i like to confirm issues within the link order during region restarts. i made the following setup to test it:

ten boxes in a row with the following script:

default {
    state_entry() {
    timer() {
        llSetText("Link#: "+(string)llGetLinkNumber(), <1,1,0>, 1);

in each prim. i selected the prims from right to left and linked them. after linking them it shows the correct and expected link order like this:


i took it to my inventory, rezzed it three times and again all three rows showed the same correct and expected order. rezzing from inventory works well without changing the link order.

after a restart of the region i got the following link order for the individual rows:

row 1: [1]-[7]-[4]-[2]-[6]-[8]-[5]-[10]-[9]-[3]
row 2: [1]-[6]-[8]-[10]-[2]-[4]-[5]-[3]-[7]-[9]
row 3: [1]-[4]-[9]-[10]-[5]-[2]-[7]-[6]-[8]-[3]

the individual reordered link numbers keep it's state after sever reboots. it would be phantastic if i could get the expected link order after region restarts.


tx Oh
Michelle Argus (reporter)
2009-02-09 08:37

Have the same/similar problem. Rezzing or copying the Objects seems to have been fixed, atleast when i rezz or copy Objects the Linknumbers dont change :)

 However, when restarting/upgrading a Region the Linknumbers still/again change.

rev: 8284.
Debian 4.0
Mono 2.0.0
tested on sqlite and mysql with same result
melanie (administrator)
2009-02-09 08:39

Someone sems to thing that link order should be load order. I have now fixed this twice, to let the link nmber from the database be used instead of generating new ones. Could the person who re-broke it please re-fix it?
Michelle Argus (reporter)
2009-02-09 08:43

hihi, no comment to that melanie ;)

btw, forgot to add, the rootprim does not change
Ursula Matova (reporter)
2010-01-08 12:27
edited on: 2010-01-08 12:28

Wahou ... submitted on 2008-09-29

Seem to be ok now even with MegaRegion :)
( r/11866 - Linux64 / Mono )

Please re-open if needed, I'll close it for now.

- Issue History
Date Modified Username Field Change
2008-09-29 12:03 Ursula Matova New Issue
2008-09-29 12:03 Ursula Matova SVN Revision => 0
2008-09-29 12:03 Ursula Matova Run Mode => Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
2008-09-29 12:03 Ursula Matova Physics Engine => ODE
2008-09-29 12:03 Ursula Matova Environment => Mono / Linux32
2008-09-29 13:20 Ursula Matova Additional Information Updated
2008-09-29 13:27 Ursula Matova Note Added: 0005579
2008-10-04 00:15 Ursula Matova Note Added: 0005661
2008-10-15 12:18 HomerHorwitz Relationship added related to 0002353
2008-10-24 01:58 rjs Note Added: 0006511
2008-10-24 02:00 rjs Note Edited: 0006511
2008-10-24 02:02 rjs Priority normal => urgent
2008-10-24 03:55 melanie Note Added: 0006512
2008-10-24 12:53 rjs Note Added: 0006517
2008-10-27 04:47 thomax Note Added: 0006609
2008-12-18 13:13 Teravus Relationship added child of 0002870
2008-12-21 16:08 Teravus Mono Version => None
2008-12-21 16:08 Teravus Summary Linked prims problem => Linked prims problem - link order
2009-02-09 08:37 Michelle Argus Note Added: 0009268
2009-02-09 08:39 melanie Note Added: 0009269
2009-02-09 08:43 Michelle Argus Note Added: 0009270
2010-01-08 12:27 Ursula Matova Note Added: 0014731
2010-01-08 12:28 Ursula Matova Note Edited: 0014731
2010-01-08 12:28 Ursula Matova Mono Version None => 2.4.2
2010-01-08 12:28 Ursula Matova Status new => resolved
2010-01-08 12:28 Ursula Matova Resolution open => fixed
2010-01-08 12:28 Ursula Matova Assigned To => Ursula Matova
2010-02-15 18:50 chi11ken Status resolved => closed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker