Objects that won't stay in place

I have a clock I've made that consists of 3 prims -- the face, the hour hand, and the minute hand. The prims for both hands rotate to show the current time. The face, which is the root prim, displays a menu when touched allowing the user to change the timezone. Everything works fine except that over time, the object slowly changes its physical position. The only movement within the scripts are the two prims which rotate about thier axes. Has anyone else had this same experience with objects with moving parts?

I have another object which has 2 child prims that change size over time and it has a tendency to "walk off" as well, so I don't think the issue is related simply to the clock's script.

Any help would be most appreciated!
-Ryas

I've had this problem with other things, it's do to prim drift. For your clock use llRotTexture if your not useing it, that won't cause the prims to drift. As for the other thing, I for it into place every time, to keep if from drifting, and that has seem to do the trick

I have been experiencing this as well.

I have created a simple butterfly object which flaps it's wings. There are only calls to lllSetLocalRot in the child prims - but the linked object drifts away slowly. It moves at maybe .001 meters a minute. Very odd.

I've seen these things happening for a long (long) time (prob. since v.1.4).

Rotations and prim modification on linked parts can throw the linked object off, and can cause position shifts, even when there are no scripted positional changes in them.

I think it has something to do with the way that rotations/positions are translated when going from a single prim to a linked object. It think this translation process can be buggy when the internal prims are being changed at the same time, causing weird jumps of individual linked prims, or the whole link set. (I've bug reported it back then several times...)

Similar effects because of this problem i have encountered:
1. Objects 'breaking' up, individual linked parts moving out of position. Sometimes causing complete delinks when the individual prims move themselves out of max-link-distance
2. Slow movement over time, sometimes extreme movements. Sim resets/grid updates etc. make this effect worse.

I tend to fix positional/rotational problems with linked prims in stationary objects by recording the position of the object (using llGetPos) on end_move and rez_events.
And do a llSetPos to that position again on a timed basis. (You can just put this in a separate script in the object)

Excellent. Thanks for the info, Damanios.

I realized after researching a bit more that this is an old problem that I have been lucky enough to avoid until now.

I have fixed my drifting problem with some llGetPos and llSetPos calls, but I like your idea of a separate script with that triggers on Rez and Movement.

Actually, most of it is floating point drift. Computer mathematics are inaccurate, as they rely on rounding values.

What I do is I use llSetRot with a new rotation from scratch, calculated using llRotBetween if I want things to point ways, or by calculating the values from scratch (which doesn't take any longer than getting the rotation, incrementing it, and setting it).

I try to never, ever rotate any linked things unless they share the same axis.

This problem was exhaustively covered here

About the only way to keep things in place is to have the script take its start position when it starts up and use Set Prim Parameters which will allow you to set the rotation and position at the same time. This drift is very annoying. I once set up an experiment in the beta and had a single prim alternate between two rotation every 0.5 seconds after 15days of running it Drifted over 30m from its start position.

Not only rotations cause drift but every time a sim is Restarted the prims drift a little in different directions some more than others or not at all. Prims with in a link set do not drift but the link set as a whole can drift. We have never gotten any feed back as to how things are stored on the server or to the exact reason as to why this happens. We most likely think the center of mass or center of the link set is being stored. So when the sim restores the position it taken this center and calculates the root position and then places the object. In doing so the small amount of floating point error add up over time.

Basically live with it get over it or Drive yourself crazy trying to get it fixed or get a real answer as to way prims drift and not just from rotation scripts.

Would the SL changing of floats fall under the IEEE issue, or normal float inaccuracy? What I'm talking about here is the situation in which an object with parameters set to some things, 0.45 for example, will often change themselves to much harder-to-deal-with numbers, .449 in our example.