Edit Commit

The single most important suggestion I can make (IMO) would be that SL start using SINGLE PASS EDIT COMMITS. In otherwords, that edits to objects or linksets NOT be saved to the asset server until the edit is completed. (ie the edit dialog is closed)

I for one am getting really tired of the "rubber band" effect while building. Three times tonight dragging an object to position it the object suddenly "snapped" back about 5 seconds worth and I suddenly found the wall of my cabbin moving because it got grabbed as my mouse was no longer on the object I was editing.

Who really cares if the people around you see you moving an object 0.010m 3 times instead of just seeing it go to it's final position?

The savings in network bandwidth would probbably not only massively reduce the asset server load but the lag we all get in SL now.

YES! Plus a 'save/cancel' dialog on exiting.

(pause for reality hitting like a wet fish)

There's just one problem... prims in-world are in the sim, not the asset server (though of course their contents are pointers to objects in the asset server) and that's where the editing happens: the client application doesn't actually hold the object and upload modified prims, it makes requests to the sim to do it.

If the whole editing process could go on in the client with a bulk "rez" operation when you save, this would be easy... but since the edit actually happens in the sim at the client's request the sim would need to make checkpoints.

Personally, I'd love to just be able to "checkpoint" an in-world object. The checkpoint would necessarily be discarded when a new checkpoint was made, when the object left the sim, possibly at a sim restart or if the object was unlinked or relinked.

That would let you checkpoint a build, and try variations on it, without worrying about how to get it back to where you started.

I guess this could be implemented using something like rez-foo... it'd be easier if they had llGetLinkParams and llSetLinkParams so you could save the status of a whole linkset from the root...

They have to be in the client already.... I spent 5 minuites editing the positions of my dining room chairs early this morning and didnt know I was disconnected... Of course, once it told me I had been disconnected and then I logged in three of the chairs were back where they were originally... becides... haven't you heard to clear YOUR cache when something goes wrong in SL with an object? They never say "we need to clear the server cache" ....


Second... several lindens have said the "rubber band" effect (and the texture "some sides dont texture" bug) is because the asset server cant save the change... so the prim snaps/rubberbands back to what the asset server has saved.

I dont think even a checkpoint or save button is needed.... Shoot, even if it were checked every 15 seconds to see if it had been edited instead of saving on every change.

It seems silly to me (and a waste of both net bandwidth AND HDD seek time on the servers) to save a prim 10 times in 3 seconds while the person editing it spins one of the size spinners from 0.500 to 0.600 (and usually 12 times because you ALWAYS miss and get 0.610 and have to go back... and thats without it jumping back to 0.540 then 0.550 then 0.580 because the data cant be saved)

o_O;;;

I've had editing attempts fail because I was disconnected. Possibly it's different when you're editing one link of a linkset, or perhaps some operations (moving) are local, while others (linking) are global?

No idea... only the SL software people know for sure (maybe!) ...


If the objects are server side editing ... then there is a far more massively serious problem since the sims I build in are usually empty so there isnt anyone else editing anything and it should update/save correctly without rubberband or snapping back.

Either way, having to click a texture select over 100 times just to get the f'in thing to STAY on all sides of a prim is just not gonna cut it anymore for me.

I've found rubberbanding (except during sim crossings) is more often a sign of packet loss than sim performance problems. Particularly in editing, it would take a seriously overloaded sim to lose enough messages to notice.

And, yes, there *is* a massively serious problem. It's called "SL uses UDP for all transactions". Using UDP for real-time control and lossy streaming (like movement, physics, music) is great. Using it for commands and supervisory control (chat, editing) is marginal, and if you do you need to implement a robust error detection and sequence mechanism on top of it (which they don't do). Using it for bulk data transfer (asset and object downloads) is nuts.

I second that!