Unreliable positioning bars

Now that's a very good analogy...and made it much clearer to me. I hadn't thought about the possibility that it might be a combination of build and bug. In that specific case, in Numbakulla when it first opened, we didn't change anything not because we were unwilling, but because no one could tell us what to change.

I am still struggling with the grid thing....
Cali

Having the chat bar move to the History window (if it's open) when you close it on the main window and move back when you hit return on the main window wouldn't violate that.

See, I ALWAYS have the chat bar up. ALWAYS. I don't EVER want to have to hit return to chat, it feels unnatural to me for "chat" to not just be another window. Having chat in its own window would change that so I could leave the chat bar down.

Contrariwise, this means I rarely think in terms of shortcuts. Almost always the menu items, so when people talk about control-thingy or shift-whatsit it doesn't mean anything to me... and when you're explaining something to someone, it's probably a good idea to use the menu items rather than the shortcuts when explaining it.

Ick. I was wondering about that, and assumed it was a Windows bug because CMD-Z on the Mac doesn't seem to have that failure mode (or at least I never noticed it).

How about just letting us change our own shortcuts?

Second. Do we have a motion?

This sounds dumb to me (sorry but it does).

The lines were fine before because they intersected objects and you could use that information in exactly the way in which people here have been saying they used it.

Then in 1.8 (even though I never heard anyone request it), they are changed so they go right over objects and don't intersect.

Why is the solution to this a *further* goofy interface dodge of making the lines "dashed"?? what is wrong with must making them intersect the object like they always did?

No offense but you guys are *always* changing things like this that no one asked you to change.

Why not just leave stuff the way it is if no one reports a bug with it or requests a change?

Why not base your decisions on what stuff to change *soley* on user feedback instead of on ideas that the development group gets that it "thinks might be keen" to implement??

- Did anyone *ask* for the "super glowing outlines" in edit mode?
- Did anyone *ask* for the extra tag for "editing appearance"??

Whomever is in charge of designing the UI at Linden labs lately seems excessively in love with their own ideas to me.

Interface problems that users have been complaining about for years that have simple fixes are not implemented, yet major changes are made all the time that seem to have their origins in one designers mind, not in the builders of Second Life.

Why don't you start a builders group and have some meetings to get feedback from actual builders as to how they would like to see the tools evolve?

Eek... I'm not quite sure why control-Z must fail when chat is up in order to follow this design convention. I don't even think it always was this way. Control-Z doesn't seem to undo anything in the chat window itself (does it?) so all that happens if I control-Z with the chat window up is .... nothing! Very confusing and disorienting.

For that matter, certain shortcuts DO work in the chat window... like the Del key, sometimes, which results in deleting your build rather than a hilighted word (!), much to my dismay.

Seconded!
Reminds me of the saying: there comes a time when you just have to shoot the engineers in R&D and get the product into production...

ZOMG I recall this one... it's an inconsistency.

I'm also bothered that shortcuts like Ctrl-A for Select All don't have any effect on building, and yet, they're grayed out when the chatbar is open but a prim has focus. Why? It's not like it'd interfere! ^.^ This has slowed my multitasking, because now, I have to move the cursor down, click inside the chatbar, and then use my chat-related shortcuts again.

Sometimes I type a line of text I want to clear, and there's no easy way to do it while building if the chatbar doesn't have focus. I used to be able to Ctrl-A and Backspace key, but no longer.

Also note that Ctrl-D works to duplicate prims, even when chatbar has focus. Hehehe.

However, about this...



Empathically, YES and YES! Some Resis, including those with visual impairments requested the former, and as for the latter, it was causing confusion because it isn't communicated clearly why an avatar is in an awkward pose and generally isn't particularly talkative. I saw this problem numerous times on the Orientation Islands, and more broadly, when you're starting out in SL. It's also connected to future possible status indicators.

It is truely a challenge: any feature implemented will not satisfy everyone. EVEN MY HATRED FOR FOOT SHADOWS. But I agree, actionability, to be able to grab the pulse and sprint with it... 'tis essential!

Also, there isn't a single person doing all that. As I've come to find, it's really a team effort...

I could put it no finer than what Kelly said here, a classic from a "settings.ini" thread.

For example, speaking personally, I send company emails with a lot of very childlike observations. They aren't terribly technical, they are a composite alloy of "enduser" perspectives. That's the way I've learned. So, if this is what someone relates to, fear not, your view is being represented @ LL. Ever got pictures stuck in a wall? Ever meant to move furniture but ended up sending it 500 m in the sky? Lose clothing because of bad texture bakes? That's me. Deleted an item when you meant to wear it? Lost something on the floor and wished there was an Undo button for it? Cried out when Local Lighting brought you to your knees? That's also me.

I think SL is particularly unique in how diverse the community is. I will not understate that, because many times when someone says "NO ONE ASKED FOR IT!" there infact someone who was--they just didn't hear it.

It can be extremely difficult, but also extremely rewarding!



Whatever I can snag--I put it in the queue for development with my comments. I also link to the SL Forums threads.

I've got a whole list right here! And am offloading it, hoping it will be of help.

To be inclusive, not exclusive, some of the Lindens, including the Content team, are quite the mad skillz builders. They may not be able to be inworld in a non-work capacity as much as they'd like, taking a cue from this... THUS, I HAVE STARTED TO BUILD MORE. It's really all quite connected.

But, not just about building...

ever wonder why there isn't a more self-explanatory way to Partner from inworld?

Yes, I am concerned with things like this.



Well I prefer big *huggerz* and encouraging them onwards ho! Good for everyone, no one loses life...

I know, sometimes it's like talking to an alien, or speaking a different language. I know all about what that's like, and to this day, I can be confused. It gets frustrating, it wears you down--but enthusiasm truely makes the difference! For everything we don't have, look at what we do have. I often see times where a fix for a long-annoying bug is put in, and hardly any cheering. It should be at least DOUBLE that of the complaints! Why not? Rejoice, celebrate, live... in Second Life!

We are all in this together. And gosh, I seriously wish the best for all of us.

Whenever you get irritated with something and want to rant and complain like an old codger, stop, file a simple and well defined bug report, and get on with your lives. If not you might turn into some smurf or something.

Is this our bug?

Well...although I can see that the dotted line is there to show where the positioning bar penetrates an object, because they are still behaving in the same way as before, as though they are 2d objects in a 3d world, they are still effectively useless.

I used to use the positioning bars a lot...and maybe my building showed that. I rather like building less than perfectly aligned things in the old way which was possible when the bars worked the old way. They have more character and look more realistic, I think.

But it is completely impossible for me to build the way I used to, with the positioning bars behaving as they do. In stead of moving through the world like 3d objects, they seem to be anchored to a vanishing point, and therefore to distort very badly - and move around when the camera moves.

Is this a bug? Or is it designed this way? It seems to me that this is a deliberate change to the way it works and a deliberate alteration to the tools which I don't remember seeing documented anywhere.

As I said to Vektor Linden yesterday, it become damn impossible to report bugs if you aren't sure whether something is a designed feature or a bug.

I can't imagine that a SINGLE builder or creator in SL would prefer the positioning bars to work this way...so I'd like to know why it was changed.
Cali

We're sorry you aren't satisfied with the solution we presented ! So Runitai and I got together, smacked some neurons around and came up with this little number. Let me know what you think.

Object axis guides will not be drawn inside objects when Show Hidden Selection is turned off.

See the image below, and take aim carefully. I'm a fast runner

I'm touched that you care . And I only have a bubble gun...Bub will tell you it doesn't hurt a bit....

This looks as though it might help, thank you...
Cali

Okay, now Cali and I just met in-world so I could have her show me the problems she still has. I think we've narrowed it down to something we can concretely describe. We've built a scene that shows the problem, with a "camera" object included that shows Caliandris' camera angle in the below shot:

http://www.lexneva.name/axes.jpg

Now, I think I can concretely describe the problem: See the dotted line that's pointed to? The axis doesn't actually penetrate the frame there, it's just occluded by the frame. There's no way to tell that, though... you get a dotted line in either case. What would be really really nifty would be if the line disappears if it's simply occluded, but goes dotted if it actually penetrates an object.

The problem here is that, just by looking at it in this picture, it's very difficult to tell where, spatially, the cube actually is. This is just a problem with 3d worlds in general, but from what I understand Caliandris saying (and what I vaguely remember), we used to be able to get more clues from the axis lines than we do now. Something changed...

With the dotted lines as they are right now, it can be difficult to tell on something as thin as this frame whether the axis line is occluded or penetrating. The only clue is if the closer solid part of the axis line comes out in the middle of the perpendicular face, but that can be very hard to see.

I've passed the above scene to Runitai and Brent Linden, so you can play with it and see what we're seeing.

Oh, one other thing. This one's hard to replicate, but if you play around with the axes, sometimes the dotted line part of the axis line doesn't match up with the solid parts. It seems to be specific camera angles, because if I zoom out and in using my scroll wheel, every time I get back to a certain zoom, the problem is still there.

You can just select the object you are trying to align to (ie, the frame), copy its position and put in the right number (X/Red axis) into the edit box for the cube, which will align the object perfectly. Of course, this is technical and not at all "by eye" so I offer the following solution that I use personally:

Warning: very wordy explanation below! The pictures should speak for themselves, but I wanted to make sure ya'll knew where I was coming from.

I shift drag my object I am trying to align and then reduce it's width to .010 while keeping it centered on the original object. In the top illustration you see that the object also has a darker side on the back side of the "center" X/Red axis. I cut the object to begin: 0.125 and end: 0.625, giving me two more faces to work with. I colored one to the dark red in the Color Picker and the face closest to me I colored bright red. This gives me a nice center line to work with, and I can visually see that the object's center is in front of or behind the object I am aligning to.

In the second picture you see the object properly aligned after I dragged both my object to be aligned and my object guide (the red prim) around until I visually saw them aligned.

This whole thread is hilarious.

It's great that Lindens are actually posting on it for a change and actually seem to be listening, (Kudos to Brent and Runitai for that), but what a colossal waste of time for all concerned. The change should simply not have been made in the first place. That's the problem.

If you read the thread it becomes apparent that this whole change arose because someone who thinks that we should be using the and "reference grid" alignment method ... had problems with the lines disspearing.

So the method that more people use (aligning by eye and then number), is borked over an internal request to change the behaviour for the small group of individuals that use the "reference grid" method.

It is also changed (apparently), because internally, they wish to promote this "better" method, even though they never asked us what method we prefer to use and why. I guess it never occurred to anyone that not many used the reference grid method cause they didn't like it? And not just cause it wasn't "explained to us properly" or because the lines disappeared? They seem to think that if we are forced into using it, we will eventually agree with them that it is the best tool, because... Maybe it's me but I think this shows a real blinkered mentality that is far too out of touch with the actual end users.

No offense to you guys for trying to help out here, but more and more I just feel that the developers at LL really just have far too much personal say so in what goes on and what gets changed. I think they really need an overall development plan that includes the users somehow, that figures what the builders and the creators that use the software actually want or need instead of what the Lindens think we "should" be doing.

Just because Lindens build, that doesn't necessarily make them "builders" or in touch with the concerns of average builders in SL.

I was offended by this. Smurfs are usually fun and friendly, and helpful. We don't rant and rave (much ), and although I myself don't file bug reports, but write here in the forums, I know my Smurfy friends do both. This is 'MY RANT"
As for the axes not intercepting the prims where they should, I have this problem too, and my eyesight is not good enough to differentiate between the broken/dotted line and solid line. This seems ironic because I make prim jewellery, and not by making big then shrinking (I find this method too difficult as it is hard to accurately size prims before shrinkage, thus having to resize as I go, so I build tiny from scratch). Thank the gods for Zoom
While building on a large scale eg: a house; I find myself looking directly down on the build to align prims that need to be between the grid snap lines, then I look at it from each side and pretty much position it by eye. I love the grid snap tool, and I use it frequently, but it is not always practical. This is why the axis lines are so important, that they penetrate the prims in exactly the place they are supposed to. I find builds take longer because of it, and it can get frustrating when you are working to a deadline. This may or may not help, but it is a concern I have.

I don't know what you lindens are having for St Patrick's day, but I want some too!
Tell me this was a joke....
Cali
xx

Sorry, Caliandris -- The uber-explanation was to explain how I made that particular object in which I highlighted the back-side of the highlight (whoa) with a darker color. Applying a texture would achieve the same. I offered this as a workaround for now, while we come up with something better. Here's a much-simplified version of that workaround:

- Create your object/cube, etc.
- Shift-drag a copy of it and hit Ctrl Z (which snaps it back to its original position).
- Resize it so it looks like my object in the image above.
- Use it as a guide.

Keep in mind I am not suggesting you use this solution forever -- just until we can get something that works for you all up and running. There are a lot of fires to put out post-1.9 release

LOL me too... Gimme!! Maybe the leprechauns slipped them a mickey? Where's mine?
Brents idea may work for large builds, but is totally impractical for small builds. Give us back the old axis format, PLEASE!!

Really, I thought it was a pretty nifty trick... it just took me a minute to get what you were saying.

At this point, I'm pretty sure that, despite how it looks, the lindens didn't make some horribly drastic change to the angles that the axis lines are drawn at, or at least that 1.9 fixes it. The problem is just perceptual: the current system (even with dotted lines) makes it hard to tell where the axis lines go through something, and where they simply go behind it. The display is ambiguous, and the brain interprets the ambiguity to mean that the axis lines are pointing off in some weird direction, when, in fact, it's simply that there's no way to tell where they're pointing given the limited information on the screen.

This is part of the problem of living in a three-dimensional world and trying to interact with another three-dimensional "world" through a two-dimensional screen. It'd be like having only one eye and no depth-perception: every once in awhile it'd be hard to tell where objects are in relation to each other.

Maybe I'm wrong here, but I don't have 1.6 to look back to. I'm pretty sure that the axis lines are angled correctly now, though, because I can see them penetrate a point on an object now because of the dotted line, and as I move my camera around, that penetration point doesn't move. The problem is just what I described above, that it's impossible to tell the difference between the axis line penetrating an object or simply being occluded by it, and this leads to ambiguities that are really distracting and difficult to deal with. My suspicion is that the change that started all of this might have been some kind of alpha-sorting bug, the same thing that makes it so that sometimes the grass behind a transparent object renders in front of it. That would mean this was an accident, Dianne, not a purposeful willy-nilly change