Solution for Ctrl-Z Bug?

[Shandon Loring]

will do... i'll create a sacrificial multi-prim object to test with.. LoL

will try Imprudence too

[Ilan Tochner]

Imprudence on Kitely would be problematic as it doesn't support HTTP assets IIRC. But you can try several viewers on OpenSim running on your local machine.

[John Mela]

If it's any help, I remember encountering this bug in 2008 on OSGrid.

[Ilan Tochner]

Thank you John, the question is whether it still exists in OSGrid now.

[Sirena Noel]

I use both Singularity and Firestorm, depending on what I am doing in a virtual world. I experience this fail in both Kitely and in Digi, but never in SL, with Singularity, Firestorm, and another viewer name not remembered but believe it began with a "T". In Kitely and in Digi it has never NOT happened when using the Crl-Z when editing anything attached to an avatar.

[Sirena Noel]

The only solution, and it works most but not all of the time, is to locate the item out there in the wild, edit it back to the exact coordinates where it came from (if able to), and pray that it goes where it is supposed to go back to. This, of course, means you must document those coordinates prior to messing with it in the first place.

Ilan, the only other OSgrid that I know of that does not do this or did not (have not been there in a while) is Utopia. Perhaps Mike might give some insight on the matter?

[Ilan Tochner]

Hi Sirena,

Knowing of an OpenSim grid where this is verified to work properly could indicate the issue isn't with the OpenSim version of the viewer but rather with some OpenSim bug.

[Snoots Dwagon]

Yes Ilan, I have come to believe this is an Opensim bug. The reason: I use Firestorm on SL and the Ctrl-Z bug doesn't exist. But as Sirena noted above, " In Kitely and in Digi it has never NOT happened when using the Crl-Z when editing anything attached to an avatar."

So although this effects Kitely builders, it's not specifically a Kitely error. Serena also mentioned this problem not existing on Utopia. So my question in that case would be what physics and script engine is Utopia using? Evidently they're doing something different that has overcome this error.

Follow-up immediately following up.... ;D

[Snoots Dwagon]

The follow-up:

I was doing some building yesterday and discovered the Ctrl-Z issue is not limited to items worn on an avatar. On an avatar, using Ctrl-Z on an object will cause it to move away from the avatar, or in the case of a multi-prim object cause the prims to "explode" and disperse (or may have no effect at all and leave the object sitting in its position without reverting).

On regular rez-building (rez prims and build) this is a bit trickier to explain. In one-sentence: Ctrl-Z seems to not understand where to quit.

For example, a person is creating a house with 4 walls, linked. One of those walls is moved, stretched, retextured and rotated.

On SL if one hits Ctrl-Z, it will un-rotate the prim and nothing more. The next Ctrl-Z may-or-may-not revert the texture (depending on texture state), followed by de-stretching it, followed by moving it back in place.

On Opensim it can (not necessary does but can) unrotate, un-stretch, and move back in the original spot all at once. It's like it's on a Ctrl-Z "high" and doesn't know when to stop Ctrl-Z-ing.

This not only applies to the object one is working on, but can apply to other objects as well... and this is complex enough that the best way to prove it is to show it done in-wold. As an attempt at description: When building a poly-sided building (6, 8 or 12 sides), builders will create one side linked to a central rotator prim. They will then duplicate that 2-prim object, rotate the copy, then stretch the walls until they align corner to corner. Once this is done, the original object (now resized appropriately to finish the build) is drag-copied, and CTRL-Z is used to center the copy and prepare for rotation. However, the moment Ctrl-Z is pressed, not only does the copied object revert to original size (un-stretched)... so does the ORIGINAL object. The Ctrl-Z is actually crossing over to affect multiple objects.

(I know this sounds complex, but I can demonstrate this visually as I've found it to have a 100% reproducible rate.)

So this Ctrl-Z issue takes on differnet forms, and can affect either an avatar attachment or a rez-build.