Cool VL Viewer forum
http://sldev.free.fr/forum/

of by one error in xml import, link heirarchy
http://sldev.free.fr/forum/viewtopic.php?f=4&t=454		 Page 1 of 1
Author:  Void [ 2011-02-08 18:34:00 ]
Post subject:  of by one error in xml import, link heirarchy
minor really... when importing an xml object previously exported, the import links the prim after the original parent (in the xml file) as the root. probably erronously uses the count number to specify the index number.

export format looks good (correct parent is targeted)
Author:  Henri Beauchamp [ 2011-02-08 18:55:47 ]
Post subject:  Re: of by one error in xml import, link heirarchy
What difference does it make ???... As long as the re-imported object is identical to the exported one, the linking sequence does not matter.

Not a bug, as far as I am concerned.
Author:  Lance Corrimal [ 2011-02-09 07:10:52 ]
Post subject:  Re: of by one error in xml import, link heirarchy
the linking sequence does matter... a script using llSetLinkPrimitivePararams() or llSetLinkPrimitiveParamsFast() would not work in the imported linkset since the link numbers wouldn't match, unless the developer when through some extra pains to find the link numbers based on prim names.

imagine you're working on making something. as the prudent do-not-spend-on-uploads you're working on the beta grid since you like your peace and quiet, and temp trextures go away too fast / after a relog.

so now you're done, and you export your work, and relog to main and import, and your scripts for your creation stop working because the link numbers do not match anymore...
Author:  Henri Beauchamp [ 2011-02-09 10:22:22 ]
Post subject:  Re: of by one error in xml import, link heirarchy
Lance Corrimal wrote:
the linking sequence does matter... a script using llSetLinkPrimitivePararams() or llSetLinkPrimitiveParamsFast() would not work in the imported linkset since the link numbers wouldn't match, unless the developer when through some extra pains to find the link numbers based on prim names.
Any scripter relying on the linking order of an object to find out the link number of a child prim is so poor a scripter that they don't deserve being taken into account, since any modification to their scripted object (removal or addition of a child prim, for example) would break their poorly written script. I use heavily ll(S/G)etLinkPrimitivePararams() in my scripts, but I never make any assumption on the link prim number and never hardcode them in my scripts, instead using prim names to find out what is their actual number.

I'm sorry, but I'm not going to make the life of poor scripters easier: they have got to learn scripting properly !
Author:  Void [ 2011-02-26 12:56:02 ]
Post subject:  Re: of by one error in xml import, link heirarchy
while it is possible to get updated link numbers for parts dynamically, there can be a lot of overhead involved in some cases, as well as extra processing. and often unnecessary for no-mod objects like huds or vehicles trying to be as slim as possible in script overhead, in addition to the poor differentiation of root vs child. that's neither here nor there though. I only mentioned it because it is a bug, and may cause other unexpected behaviors.

but like I said... minor really, in fact it only occurs when the parent isn't in the last position (I didn't look at ordering, I'm guessing it's prim creation date?). at any rate it's easy enough to work around if someone needs a particular order, by reselecting the preferred order. just thought you might want to know

PS
sorry for the slow reply
Author:  Henri Beauchamp [ 2011-02-26 14:25:10 ]
Post subject:  Re: of by one error in xml import, link heirarchy
It is in NO WAY a bug: prim linking order cloning was simply deemed UNNECESSARY to the object backup feature, and I DO AGREE with the original author on this point (since adding or removing a single prim can completely mess up the link order anyway). Decent scripting skills is required to produce decent products, and the burden should not be put on viewer developers to try and plug holes in poor scripters' code.

The code of the Cool VL Viewer will NOT be changed to address this NON-ISSUE. Period.
Page 1 of 1 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/