Dancing Prims

Everytime i transform a prim in any way, (position, rotation, size texture, etc.) it follows up with a series of random changes for about a minute or so. it's like i have to westle and hold down the prims till they agree to stay in place, EVERY SINGLE STEP of the process.

It's gotten so bad, the only way to hold it down is to enter the transform data by measurements and hit the enter key repeatively until the prims stop moving.

Building has become nair-impossible as of late. I thought it was just my connection messing with feedback but i had it on my broadband as well. i also heard of others getting the same effect

And sadly, no. After the prims stop moving around. they don't end up where i intended, so patience rewards nothing in this case.

Is there a work around to this problem? i don't mind lag but screwy stuff like this just isn't helping...

Sorry you're having this type of trouble, it sounds like "prim drift" - I've moved this over to the Resident Answers forum to see if anyone has some tips on how to help with this.

Ru, your problem sounds less like prim-drift than problems associated with packet loss and/or bad internet connections. This is something that frequently affects me while building. OTOH, prim drift is insidious and slow over an extended perios of time. That said, it's often first noticable when seams start appearing in builds while they're still under construction in the form of millimetre and fractional degree shifts from their original positions & rotations. I once had an extended reply explaining why prim drift ocurrs. It's causes by math rounding errors in the most part.

As for that 'dancing' and snap-back it's another problem altogether, one that i hope can be cleared up soon.

Sorry for the confusion in bug nomenclature; I meant dancing and snap-back.

The most likely explanation for snap-back is that the client issues a update request (move from P to P') to the sim DB and updates the client view. The sim-DB (or some component of the asset system) drops the modification request because it is overloaded. On the next update, the sim tells the client that object X is at P and not P'.

This is likely due to a coding expectation that database modification were never expected to fail so there is no re-commit logic in either the client or server. Evidence which is compellingly supportive of this guess is the texture snap-back where changes will take an arbitrary number of OK's until they "stick". This problem has existed for more than a year and gets consistently worse with additional load.

If my guess is correct, this is unlikely to be easily fixed, requiring every DB modifying action to be confirmed; such would be a mammoth code change.