Build tools still hard to use


There are a couple of annoying bugs that i feel need to be fixed.
Building with entities is a very inaccurate process ATM.
Trying to move, lift or lower, and some other actions sometimes cause the entity to implode, instantly reducing it to 0.2 x 0.2 x 0.2, and I have to reset to original size regularly. Something causes it to shrink unexpectedly.
Trying to resize something is a frustrating experience, the rotate widgets are reacting to hover when the cursor is nowhere near it, no matter what action I want to do, the entity wants to rotate. Trying to grab the black squares to resize one side is really difficult, because the point to make the black dot go red is all over the place and sometimes impossible to get.
I have to zoom in so close to get out of the way of the rotate widgets that when I finally get the black dot to go red I am too close to do anything worthwhile.
The result is stretching by hand is almost completely futile and I resort to doing it by typing values into the edit window.

Summary: The rotate widgets are too sensitive and the stretch widgets arent sensitive enough.


I’m curious… how big are the objects you’re editing? Are they 1meter cubed? Smaller? Larger? Does the size of the object impact the usability of the tools? I would think different size objects may be more or less easier to edit.


Yes the size of the object makes all the difference.
Large objects pose less problems, there is room enough to grab a clear shot at moving the object, but the corner tabs are still quite elusive, they dont recognize that the mouse is on top of them.

Its the smaller objects which cause the most problems, and even bigger objects when zoomed out, the widgets just overwhelm the object and its impossible to get a clear shot at the object without fouling on one of the rotate handles.

In the image shown I want to simply move the cube across the road, I need to zoom out to this distance to see the destination.
At this scale it is almost impossible to move the object, it just wants to rotate.
The mouse pointer doesnt show up on the image but it is nowhere near the rotate handle, it is in the middle of the cube, yet the rotate handle is highlited.


I just noticed that the build tool is working wrong with moving. by accident i did something so my house moved. and now the not logic part.

To move the house closer you need to push the mouse away from you. Make no sense. Pushing the mouse away from you (the the screen, means you move the object away) But High Fidelity seems to have a weird logic in moving and zooming. it’s all reversed

Moving mouse to the screen is moving object to you.
Moving mouse away from the screen is moving the object closer to you.

This logic don’t make any sense. I bet more users are going te get stuck on this weird

Another thing, why you you move the building with the right mouse button, this created already the last days many unplanned object movments , because you want to move the camera with the right mouse button. Never allow to move a build with the right mouse button.


@Richardus.Raymaker I was going to report this yesterday and that is that the movements are local axis based. Once you rotate an entity off of 0/0/0, the mouse to entity movement mapping becomes rather unintuitive. Can we use some tried and true selection methods like that used by SL or Blender

I did notice however that build 2714 brings a lot of fixes to that problem, and it provides better selection, translation, and rotation methods. One suggestion is that all of the object editing widgets, the selection boxes, the rotation wheels, be placed in front of everything including the avatar.

I ran into nasty UI deficiency when trying to position a zone (or any other entity) over an existing build. Because the resizer widgets are on the bottom of the entity, they get completely obscured. I end up having a tedious workflow of raising the box, resizing it, lowering it, seeing that I didn’t quite get it right, raising, resizing, etc.

Another problem is editing the position of physical objects, which is presently quite spasmodic. Try it, create a box entity, make it move on collision to make it physical. Now click on it, move it, watch it spaz all over the place. Now I did notice one nice thing about that movement which is that holding the shift key permits up/down movement! Now can this behavior also be made part of entity editing? Again, this is the issue of independent development of two different but closely related entity movement modalities. Those two scripts need design coordination.

Here’s a video I made of physical object movement code I wrote for OpenSim derived grid. The OpenSim object movement was also a mess, so I rewrote that code. Damped movement is essential.