Rotations Translation

Okay here is the setup. setup a bunch of boxes in a 4x4x4 pattern like in image provided.

Don't link them. Select them all. Rotate them by grabbing the axis rings or the white shaded area detween them. Most of the time they will rotate like they are one and the there are times when their rotation get all wacked as if they stand still and rotate on their own axis. And using Ctrl-Z will not Work to undo this mess.

Any one else get this. I have tried on three systems now and get the same thing. it is unpredictable and tend to really mes up builds. the rotation buggyness will not happen right away. you just have to keep playing with it.

Rotation error

Yep!

Just confirmed it. So that was what you were doing yesterday. Cool effect if it would have been planned for, but disasterous like this. It ends up looking kinda like something Escher would have been proud of.

I have seen this on the main grid.

Well it seems to be nothing more than packet loss on the server side. And have accepted it as a just live with it thing. Although have learned a few things along the way. When rotating multiple non linked objects only the rotations are being transmitted to the server then once you let on the mouse the positions are then sent. So there are two steps happening here rotations then positions. So if undo (ctrl-z) only the position will be set back and not the rotations. This can be useful if you have a bunch of objects and you want them to all rotate around their own axis at the same angle. so a bug? or useful building tool? I vote useful building tool.

I've dealt with this for most of the time I've been in SL. I think you're right on your analysis, and packet loss is the cause. This can really screw up a build if it happens when you're not expecting it, and since it only happens every once in awhile, you can be lulled into a false sense of security and then get slammed by it.

You need to be more patient when moving/rotating, and the problem will not occur.

The problem is that you are releasing the objects from Edit-Selection mode too quickly. As long as the objects are selected, the client will continue to work on moving and aligning the objects correctly.

Once you click off of the objects and deselect them, the client stops trying to position the objects and the server will "freeze" the objects in the partially-moved state.

This problem is more obvious when working with a huge selection involving hundreds of objects. When moving or rotating it is necessary to do it and then sit there and WAIT a good 20-30 seconds after everything seems to be done moving, to give everything time to solidify in the new position.

This problem is far worse on slow connections, and when trying to re-reposition an object that didn't quite go where you wanted. Now you're trying to move the objects even before the server managed to catch up with your previous move, and the objects can start jumping back and forth between the new and old positions, flip flop flip flop flip flop, until the whole build is wrecked.

The problem here is that the client is doing something that takes time and should not be interrupted, but the Lindens did not put in a needed pop-up warning that says "PLEASE WAIT. Moving object #xx of xx in your selection..." with an "<Abort>" button.

Deselecting the objects before the move is finished, is like doing an Abort of the operation, except the client as it is now gives no indication of how long it'll be before it is done properly aligning/positioning the objects.

What Scalar said.

I've noticed then even when just selecting a lot of objects, it pays to wait a little while to make sure they are all really selected.

There are a lot of such things where some sort of In Progress indicator would be very valuable.

This is part of another editing annoyance in SL that I don't really know how to demonstrate, but I think it amounts to the programmers of the client "cheating" to make the interface seem faster, better, and more responsive than it really is.

When you do something that involves moving or rotating, it takes time for your changes to get from you to the server.

But in order to make things seem more responsive, the client will instantly update the position of objects on your screen...... and then take its time sending and confirming the actual updates with the server, which refreshes the positional data occasionally.


So when you move either many objects on a fast connection, or a few on a slow connection:

- the object(s) INSTANTLY jump to the new location
- the client may spend several seconds updating the object positions with the server, but doesn't give you any status of what's happening
- if your upload speed is too slow, the server sends out a periodic refresh of object positions before the move is complete, and some of the objects are shown jumping BACK to the original location.
- when the server catches up, the objects again jump to the NEW position


Now, lets say you move 1000 objects, but don't like the positioning, and immediately move them again before the server update finishes. This mess looks like this:

- first move/rotation, and the object(s) INSTANTLY jumps to the new location
- the client may spend several seconds updating the object positions with the server, but doesn't give you any status of what's happening
- if your upload speed is too slow, the server sends out a periodic refresh of object positions before the move is complete, and some of the objects are shown jumping BACK to the original location.

Oh, but you didn't wait long enough, and moved the objects again before the first update finished. Only 350 of the 1000 actually got moved to the 1st move location, and the other 650 are still in the original position.

- 2nd move/rotation, all objects are shown INSTANTLY moving to the new 2nd move location.
- the client starts the update over again from the beginning, moving all objects from the beginning
- your connection is still slow to upload, so when the periodic server refresh occurs before the move completes, now the objects seem to be jumping around between three different locations: the original position, the 1st move, and the 2nd move

If you WAIT long enough, it will usually settle down and put everything in the final location, but if you release selection too soon, you will get a muddled mess of some objects still at the starting point, some at the 1st move point, and some at the 2nd move point.


A popup message that says "Please wat, moving objects.." would likely fix this annoyance.

Think there is a packet loss problem on the server side during the rotation process. And the positions don't get updated and only the rotations are sent and positions are lost. But the client side sees the position in one place while the server/sim think they are in another. So it appears correct to you untill you select the item again which forces the data to be sent from the server to the client which you then see where it is according to the server. The best thing to do if you can is have two computer running while you are editing the objects whatch what happen on the other screen while you are editing. After you let up on the mouse and both screens don't appear the same do a ctrl-z twice and try again. One computer will be client side and the other will be server side. As long as you keep everything selected Ctrl-Z should undo. Can try and run two clients at the same time on one computer but not recomended.

Yes, it should keep the selection or other operation in some kind of obvious "in progress" state... but because the operation of the abort is so dangerous I don't think there should be an "abort" button here. Maybe a "cancel" button, and a second dialog "PLEASE WAIT. Undoing move of object #xx of xx..." with the dangerous "abort" button on this second dialog.

The real problem here is that server does not know what you have selected, but only that the client is trying to do an iterative move of an unknown number objects in a long sequence.... and can stop at any moment when you deselect the objects you're trying to move.

It'd likely work better to use a method where the server DOES know the objects are grouped by the client and are being moved as a group:

1. User selects objects and moves them.
1. Client uploads list of objects to move/rotate and their target positions to the server
2. After upload complete, client issues a COMMIT command
3. The server itself now does all object moves using the uploaded list.

This would be less-prone to corruption problems since nothing moves until the entire list of changes is uploaded to the server. It would also allow the object alignments to survive events such as sudden client disconnection, since nothing in the group moves until the COMMIT is issued.


Hmm, speaking of uploading data.... does the upload speed for images and sounds also affect the upload rate of object-editor moves? Do editor problems decrease when higher upload speeds are permitted?