new building tools... ACK ACK ACK

Okay, I apologize for not checking these out sooner, but wtf...

is there ANY way to make the 1.6 build tools act like the 1.5 tools?

ie not hiding the build window when moving a prim around... turning off the intrusive and annoying rulers (without turning off snap to grid), and so on?

It's silly that I have to have a gigantic, white ruler take up 50% of my screen real estate when i want to move a prim. PLUS I can't just shift-move, I have to move it to the side and then over? brilliant...

guh.

*waits for RC2 to come on so he can fiddle more*

This bites!

At least the URL's for streaming video are hidden.

I definately agree about the auto-hide edit window thing.. I thought that was a bit of a pain.

Yes. Damnitall, I've said this before, and I'll say it again.

Lindens.

OPTIONS

Always options.

Just give me the 'Acts like v1.5 building tools, KTHX' option. Yes, including the camera, since I got used to the damn thing. This is gonna take a while to get adapted to.

Oh, and before someone says 'why didn't you say anything' ... I did. In preview and now. So, um...how about it?

Snap to Grid has changed in 1.6.. Many may not like the way it works now with the big rulers.

There are new handles in the new building tools, handles that allow motion constrained to a plane. They look like little triangles, two different colored triangles stuck next to each other. There are three sets of them. I was not able to intuit what they were, i had to ask.

Try using those "Constrain to Plane" handles with snap to grid turned on. it is possible you might think it works ok. It seems to be snapping to the grid, displaying a gridlike grid instead of rulers.

But it doesn't. Instead of snapping to .125, or .25, say, it snaps to .304, .578, and other totally not-awesome numbers.

Changing the grid interval also does nothing.

LF

There are many things wrong with the new edit tools. During the first Preview releases, I did an exhaustive test of what the three modifier keys (shift, control, and alt) would do when clicking or dragging various things and what would happen when you released or added them when dragging. The results lead me to believe that the code that manages these functions is a horrible mess of spaghetti code!

I sent my report to Philip who said he forwarded it to the right devs. I haven't spent enough time in Preview since to see if my observations helped nail down some of the random behaviors or not. I know a few things have been fixed, but others have not.

I'm all for moving ahead with the interface, change is good and people WILL complain about any change, but there are many aspects of the new edit tools that are a step backwards. There are things that could be done with the old tools that can NOT be doen with the new.

For the life of me, I can't see why these changes were made. Did people complain that the edit tools were too hard to learn? If so, how many? Do the devs think there will be FEWER complaints with the new system? I think it's not only has just as difficult a learning curve as the old one, but the changes were radical enough that now they'll have 20,000 existing members who liked the old tools better complaing too.

Editing in 3D is NOT as simple as dragging crayons over a placemat and connecting the dots. People WILL complain it is too hard. It is inevitable. But if you are going to turn the interface on its head, please do it CAREFULLY!!! Interface design can make or BREAK a program more that anything else!

And the 1.6 interface is broken.

I'll be going into Preview this evening once more and doing yet another detailed study of the flaws, and will report them once again. I don't want to be the only voice, however. I hope more people go into Preview and do the same BEFORE it hits the main grid and we HAVE to live with it. (But people won't... They'll wait till it goes LIVE to complain, I know it.)

Sorry if my hopeful suggestion was a washout, I noticed it just before I had to go to work and wanted to post it before I forgot about it.

Darn! I really don't like the rulers at all, I can see the positions of objects much more clearly in the numeric display fields in the edit box and at the top of the screen , and having to move the cursor to the ruler mark area each time makes using snap to grid take many more mouse movements than before, making it less intuitive, slower, more tedious, and increasing the risk of Repetitive Stress Injury.

I agree with Suezanne on all points but substitute "less accurate" instead of the oft-over-used RSI call, though give it props for humor value.

I could live with the rulers if I could add the ALT key to an in-process drag to do the same thing as moving the cursor AWAY from the object I want to move.

Having to move the cursor AWAY from the object in order to snap-to-grid is the WORSE interface snafu in the whole edit tools redesign. And I'd like to put my RL professional weight behind that comment.

I still say we only need a single, global modifier key (ALT) to toggle snap-to-grid in any and every tool, EVEN the numerical arrows in the Edit window. This way people can turn it on and off whenever they like, even in the middle of a drag.

I BEG whoever is working on this design to sit down with a Photoshop junky and have them demonstrate how the shift key is used for snap-to-grid! THAT'S the way to do it. Get your grid-snap for nothin' and your freehand for free. o/~

Sequences:

1. hold down a modifier chord of shift and control... either, neither, or both
   
2. (note, not ALT, which starts alt-zoom in any and every mode)
   
3. position the mouse over target object
   
4. press and hold the mouse button
   
5. (the modifier keys can now be optionally released and reused, even ALT)
   
6. pressing and holding ALT forces the object onto the nearest gridded position/rotation/scale
   
7. releasing ALT allows the object to go exactly where the mouse indicates
   

The new grid rulers are fine, but make THEM the checkbox, not the snap-to-grid.

The ALT SNAP mindset can be applied to other areas. In the Edit window, each numerical value has a pair of up/down arrows next to it. Clicking these arrows increments or decrements the value by one small step. I say hold down ALT before clicking them and they will jump up/down to the nearest gridded value. If the text insertion point is in one of these text fields, the up and down arrow keys on the keyboard should do the same thing as the up/down arrow buttons, and typing ALT-up-arrow or ALT-down-arrow would also move the number to gridded values.

ALT SNAP can be use in ALL situations.

"Ask your Linden for ALT SNAP!"

TWO SNAPS UP!
*snap* - *snap*

First let me endorse Tiger's suggestion.

Second, the role of bad interface design in RSI is not a joke. I have had numbness and mild paralysis symtoms in my right little finger caused solely by the use of the mouse, and shoddy, poorly thought out interface design that multiplies the number of mouse movements needed to accomplish a goal one needs to perform hundreds or thousands of times a day contributes just as much to RSI as the design of the mouse and one's posture. My RSI problems were caused by my constant mouse use at work, not SL, and fortunately abated by carefully avoiding the use of "ergonomically" designed mice.

Good feedback,

Max, The camera: edit auto positioning now has a toggle in preferences > input/camera.
Hope that Helps!

As for the rest of the changes, I have been told that we will be looking into whether the new features and behaviors can be made optional.

Ok, first things first. I will add back the snap to grid as an independent option from show grid. I consolidated the two initially to minimize the number of options a builder had to manage and because the new rulers had to be visible to be used. It was an oversight of mine to not put back in the ability to work with a hidden grid. I will also add a grid "opacity" option so that the rulers won't be so intrusive.

As the rulers stand now, they don't represent the complete feature as designed...but they *should* provide the same functionality as before, with the caveat of having to move the mouse off-axis to activate them.

So why did we make the change? Well, it started with the desire to have a way of snapping objects together and lining them up with some reference point that isn't an arbitrary coordinate in the world. For those who learned to build and design everything on a grid, the old method mostly works, but we wanted more flexibility. What if I'd like to hang picture frames at even intervals on my wall, or build a staircase and make all the steps line up, and once that's done, scale the entire thing to fit the empty space in my building (so one side touches the first floor, and the other touches the second, without overlap)? And all of this without worrying about making every object line up with a predefined world grid.

So what we need is a set of reference points that are somehow useful in aligning objects with each other (the point in space where this object just touches this other object, etc.) or spacing them out in a well defined way. And we wanted these reference points to be always visible and usable, without getting in the way if you don't want to use them. That's where the "ruler" metaphor came in. We could add a variety of tick marks and reference points such that you can see what your snap options are at all times, but, because they are placed off the axis you don't have to use them. The rulers are, in UI terminology, "modeless."

In their current, incomplete, form they allow translating and scaling of objects at defined intervals: world coordinates, multiples of current object extents, or multiples of another reference object extents. With sub-unit snapping turned on, you can also snap to sub-intervals (half a meter, a quarter of a meter, an eighth, etc.). The size of the ruler ticks should indicate which are the requested grid units and which are the sub-units.

There is a lot of more work to be done on the tools, and I hope that they turn out to be a step forward for SL builders. If not, we will get rid of them. But it is important that we give them enough time, fix the obvious bugs, and gather enough feedback before making that decision.

Richard Linden

Yeah.. I happened to actually like the new rulers. A rather intuitive system actually. If they get better... well I think you'll find a few happy ducks among the flock.

I am in preview right now moving an object with the plane-constraint handles.

Use grid is turned on.

The world-local-reference dropdown list is set to world.

On the Grid Options box , grid unit is .5 , grid extent is 1 and enable sub unit snapping is off.

With the grid extent set down to 1 the grid does not take over the whole screen.

This is working in a useable manner. Not an excellent manner, but not a terrible or broken manner. The positions are going to the grid unit positions, not to funny positions like .387 when you have the grid unit set to .5. The positions are all multiples of .5, just as they ought to be.

If you enable sub unit grid snapping then you do get some funny looking numbers because it is snapping to fractions of the grid unit size, and the numeric fields do not have enough digits, and what you are seeing is a rounded off version of a fractional unit.

For example I see .563 in a field because that is 5/16 , which is .5625, rounded off in SL manner.

If one is going to be snapping to 16ths, then the numeric fields need to display enough digits to display 16ths.

If one is going to have sub unit snapping, then one needs to be able to set the resolution of the sub units, that is, be able to set whether the sub unit size is one half, one fourth, one eighth, etc.

One should be able to set the value which is used by the triangular increment controls to the right of numeric fields.

The numeric fields should be able to perform simple arithmetic and be large enough to display both the current value and the operator employed and and the value by which to change.

In other words, in a numeric field that shows 7.4567 one should be able to increase the value by one by adding "+1" to the number displayed, thus causing you to see 7.4567+1, and then when you press enter or tab, the number should change to 8.4567.

To scale a value by 125 percent , one should be able to add *1.25 to the value displayed in a numeric field , press enter, and see the previous value multiplied by 1.25.

It is quite annoying having the grid appear and disappear every time I let off the handle.

It is also annoying having the obect editor dialog vanish while I am editing the object.

If the object editor were designed in a more rational and efficient manner it could be in a horizontally arranged box that could sit at the top or bottom of the screen, being both moveable and hideable by the user. An option could allow the dialog to either cover the world beneath it or alter the world's display to fit in the space not occupied by the object dialog.

Enough , it is late. Good luck to all the SL programmers, and thanks to the customers who have tried to get 1.6 debugged.

I spent another 15 minutes in the preview fiddling, trying to show people what was going wrong, but uh... it worked this time. Weird...

I think my main beef was that the grid changes intervals depending on the camera angle relative to the prim in question... it makes sense, but it's hard for me to wrap my head around.

Philip also seems pissed I'm robbling about the building tools now... sorry

LF

after reading Richard's post i realize that we are all trying to make the new build tool work like the old ones. mostly cause we know how to *use* the old ones. we played in sandboxes, or spent lots of time at the ivory tower, or both. and none of us want to repeat that. so instead of sending us all back to square one can a Linden maybe write up a read-me just about the new build tools written with references to the 1.5 build tools, where they have the same functions, what functionality has changes, and what is new. i see plenty of possible advantages to the new grid, but i don't know how to use it. and until i, or anyone else who uses the grid to build, learn we aren't gonna be creating much.


jester



.

The grid options box should be incorporated into the object editor dialog.

Okay, so you want a better way to snap stuff. I get that. Did you fix prim drift first though? It makes this entire process of adjusting the tools to make things easier to build stuff by snapping them somewhat pointless if your perfectly aligned stairs all drift out of alignment later on.

umm........people have been complaining about things wrong with the build tools since the first week of preview. it's not like Lordfly just woke up this morning and finally got the energy to post about it.

Honestly, I don't see what the big deal is. I spent a while in the preview today, and I found the new build tools to be perfectly intuitive, certainly no rocket science involved. Everything seemed to make plain sense. (Well, everything except the reference thing. I still have yet to figure that out, but that hardly seems to be a big deal.)

I for one love the new movement handles. In my opinion, this is perhaps the single most important building tool that SL has been lacking up until now. Before this point, it's been entirely too easy to move things by mistake, simply by dragging the mouse. There's not another 3D modeling program on Earth that allows that kind of margin for error, and it's about time it's been fixed in SL. Every other modeling package requires the use of manipulator handles to move objects, and I'm thrilled beyond belief that SL finally requires this as well.

Previously, being able to move an object without having to click specifically on a handle was dangerous and annoying at best, and potentially devestating at worst. Anyone who lives on the coast as I do knows all too well the frustration and horror that ensues when a complex project falls off the world because you tried to do a prim count and you accidentally moved the mouse while you had 700 objects selected. Now that kind of accident can't happen. I'm happy, happy, happy.

You guys are scaring me. I've built so many things it's instinct to me now. Is the upgrade really that different that I am going to have to learn to build all over again?

Yeah, this is crazy.

Suddenly it's an emergency because someone tested something the day before release?

This only makes sense in the LL world of software development.