Unexplained child prim movement

Are there any known issues where child prims move for no reason when linking/unlinking prims on a complex object (100+ prims)?

I am currently working on an object that requires absolute precision prim placement and whenever I add a new prim to the set, I find that other prims in the set have moved about 0.001m. When linking/unlinking objects a lot, the effect becomes very pronounced and everything ends up way out of alignment.

Has anyone else experienced this behavior? Should I submit a bug report? Any feedback regarding this issue would be appreciated.

Please, Apotheus...think! Have you ever TRIED to keep a child still? It, ain't possible. Maybe if you gave it a wee bit of valium, you could keep it still enough to put it in a child restraint device.

This is a known problem. Huns Valen pointed it out in another thread fairly recently.

It is most visible for objects with many primitives (100+), and can accumulate for objects that cross simulator boundaries frequently (such as a very complicated attachment).

Unfortunately the fix is not a simple matter and will take time to fix. So its safe to say that it won't be fixed in 1.3, but probably will be in 1.4.

The only advice I can provide is:

If it is a static object, like a house or sculpture, then get all the unlinked primitives where you want them and then link them all at once. If you _must_ move linked pieces around first, prior to the final link, then the fewer primitives in the pieces the better.

If it is a vehicle, or an attachment, then the pieces may gradually drift apart after each simulator boundary crossing. So, the best strategy is to rez a fresh copy of the object from a master copy in the inventory whenever you want to use it, then just delete the object when you are done rather than taking it back into inventory.

Excellent Andrew. I'm glad to know it's being worked on. I've found a workaround for the time-being.

Andrew,

Excellent advice for a way to maintain working while this bug is sorted out. However, my problem is that I sell vehicles. When this happens, or other simline related mishaps occur the vehicle that has been purchased it transformed into a POS that cant be used anymore. I realize that Its a bug being worked on but the majority of my customers are just left with the impression that my stuff sucks. so once this bug is fixed these people will never know it was fixed and just think "Hmm wow this new vehicle kicks arse, not like that POS i bought from Corn" and I become the first SL Welfare recipient because word of mouth will put me out of business. This scenario will also effect the other builders eventually hurt SL commerce. can you write ap a script for us builders that will rez new customers?

PS: Dont take this as a attack on you or LL. I'm just placing another portion of food on the same plate here. Simlines stop scripts, ruin second seats, trash vehicles and make unhappy customers who think its the car, not the road.

Hehehe...

Corn: Maybe a solution would be to make your stuff no-transfer, rather than no-copy. That way people could use the copies and just trash them when they're done or if they break. Any better?

Alright alright... please tell me this is going to be fixed before 2005...? It's really a bummer for a lot of people, particularly consumers who bought locked (pre-1.1) or no-copy (1.1+) objects.

I mean... wow. 1.4.

Thanks for responding to this thread. I was getting ready to post another asking whether there was an ETA for this particular issue. This changes a certain business decision I have to make, so it is good to know.

Maybe it would be prudent to get the word out somehow. I don't know the best way to go about doing something like that.

Andrew,

In light of this, something that I've been saying since 1.0:


Is there any possibility that we can have *local backups* of our inventory, in this case?

I've taken to giving 'backup-in-a-box' copies to many of my friends of my rather detailed av, just in case this does happen.

Is there any reason objects in our inventory can't be downloaded locally, and then re-inserted/uploaded from the copy on our own systems if they were to get corrupted/misaligned?

And, 1.4, is that even scheduled or does 1.4 basically mean "in the distant undetermined future" ?

** deleted **

Ok, I have a half-baked idea about how this might be fixable with less effort than I thought.

This is already classified as a Priority-1 bug and is on my plate, so as soon as I get a chance I'll try out my idea and if it works then I will include the fix in 1.3, if not sooner.

Incidentally, "1.4" means the following : based on the period between the various point releases (i.e. 1.0, 1.1, 1.2, 1.3) you will proabably see 1.4 arrive after a similar period. (Yes, I know 1.3 hasn't arrived yet, but you get the picture.)

Thanks for continuing to work on this, Andrew.

Sorry to bump this old thread to the top...but...

I'm still experiencing this bug with the 0.001 drift on static builds. The process is most pronounced after linking/delinking, followed by shift-copying any of the older prims from the linked set. The drift is variable, and affects all 3 axis.

Andrew, any update?

Thanks
-Bone

Wait, I thought this problem was fixed last year. Did it come back?

Yes. I've got examples if you want to see them.

It's alright, Huns, I've experienced it myself. What I want to know is, who unfixed it?

At least it's not like SL depends on objects we build. Oh wait, it does. Ever since 1.2 building has been broken in many ways for me. Sometimes undo works, sometimes it doesn't. Sometimes snap to grid works, most of the time it doesn't. I've resorted to aligning things with explicit coordinates for every...single...prim. This is slow and painful but it works. No, it doesn't, because then the parts drift apart.

Time to work on clothes until they fix this. Hopefully our crotches or some other part won't inexplicably break again.

This bug was never "unfixed". It's just that my last "fix" turned out to be merely a "reduction" such that it became noticable for fewer objects and only over longer time periods.

Anyways, I was able to fix it, but this is one of those changes that requires a fair amount of regression testing, so it probably won't make it into 1.3 until the first major patch after release.

Sounds great Andrew, thanks for the update

-Bone

not willing ot bother qnybody but 1.4 is here qnd i cqn still experience very noticeqble drift.

100 prims linked qnd craash you can be pretty sure the next unlink will make our house looks like a ruin...

How's 28 prims to an obbject, and CONSIDERABLE drifting every time I dare SELECT a prim?

What do you mean by "considerable"?

i probably shouldn't have sat on this bug, but one of the prims i torchered to death would drift in 1.4.3

i don't mean when it was linked or unlinked i mean when it was selected it would move; i had to put a script in it to move it back every few seconds. it might only move one centimeter per select...

I haven't seen it do it since. Might want to look into this if it hasn't been explicitly fixed already. (if you want to contact me about it IM me ingame, as i only read my email once in a blue moon)

I think some of the visual drift taht goes on when you edit an object, is due to the conversion for the rotation into Euler form.

Prim drift is still very much with us. It doesn't seem to be as height-sensitive as it used to be, but it is still cumulative, and still seems to be related to attaching and detaching, selection, rotation, and crossing sim boundaries.

Trust me, I know. I am the canary in that coal mine.

Ok, I REALLY fixed it this time. I swear!

I discovered that there were some quaternions that were not getting normalized after computation. Since the errors were getting accumulated eventually they would become very noticable.

The problem affects objects that are linked/unlinked/linked/unlinked a lot, but not objects that just cross region boundaries (such as attachments). Unfortunately, the quaternion magnitude error from any link/unlink cycle will persist until the object is rezzed/derezzed, crosses a region bounary, or the simulator is cycled.

The fix will be out in the next patch.