|Anonymous | Login | Signup for a new account||2020-02-23 02:55 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002298||opensim||[REGION] OpenSim Core||public||2008-09-29 12:03||2010-02-15 18:50|
|Assigned To||Ursula Matova|
|Platform||DediboxProXL||OS||Linux Ubuntu (32bits)||OS Version||8.0.4 TLS|
|Target Version||Fixed in Version|
|Summary||0002298: Linked prims problem - link order|
|Description||Well, 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 Information||Humm :S |
Seems to be solved in SVN.6579
- Re-rezzing the object ( root prim + 14 linked prims ) : Ok.
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)|
|Environment||Mono / Linux32|
Ursula Matova (reporter)
- Logoff/Login : no change on the linkset order ( maybe my mistake ),
Restarting OpenSim server change the linkset order. :S
Ursula Matova (reporter)
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. :)
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.
|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 ...|
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.
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:
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: ---------
row 2: ---------
row 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.
Michelle Argus (reporter)
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.
tested on sqlite and mysql with same result
|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)
hihi, no comment to that melanie ;)
btw, forgot to add, the rootprim does not change
Ursula Matova (reporter)
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 220.127.116.11 )
Please re-open if needed, I'll close it for now.
|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|