Chat focus, arrows keys, av movement

Are people having weirdness with chat focus, arrow keys moving the av when they wouldn't use to have, stuff like that?

Yeah, its happened to me a couple of times earlier today. It must look odd to people for me to suddenly do a little jig on the spot then jump up in the air all of a sudden!

Yep, it does that every time I "cam around". If I dont click back on the chat bar, thats what happens... annoying as heck, considering I cam around a LOT. =\ Hoped that would have been fixed when we got back, but I s'pose I should just be glad game is back up lol.

I filed a bug report about not being able to use "Enter" for bringing up the Chat bar while the Chat History has focus.

One that I noticed was that if you have chat open, and then use the chat button to close the chat entry field, it doesn't quite release focus. The rim of the chat button remains highlighted, and if you type "m", you don't switch to mouselook as you should. Selecting Mouselook from the menu bar does work, and also fixes the focus glitch temporarily.

This was annoying the heck out of me last night! I kept going to type something and instead involuntarily launching myself into the air. I thought I was going crazy until someone told me it was thanks to the patch...I really hope this gets fixed soon. It's not exactly an earth-shattering issue, and certainly paled last night in comparison to the random, frequent crashes so many of us at the shelter were experiencing, but it's still an easily-fixable inconvenience.

This update has made content creation far more annoying, frustrating and time consuming than before. Now that the Edit window Name and Description Fields can no longer be used correctly, it takes about three times as long to rename, set descriptions and permissions as previously.

Before this update, if I needed to edit the name of an object I was working on...say because I made a red version retextured from a previously named brown version...all I had to do was put my cursor in the Name field of the edit box and sweep the mouse to the end and the text in the box would scroll along automatically when the mouse got to the end of the box. That made it very fast and easy to get to parts of the Name or Description fields that were off the visable end of the box. No more. Now you sweep the mouse to the end of the box and...it stops dead. You can only access the rest of the text by using the arrows keys...which is hugely clumsy and time consuming in the extreme. This needs to be put back the way it was ASAP.

I don't know what development platform LL uses, but if it's like 90% of the Windows packages out there, it sounds to me like someone just forgot to set the properties correctly in the Name field element. It's a simple thing to forget, kinda like when we forget to set permissions on an object we make before we give it away But it shouldn't happen.

I too, was launching myself around while chatting last nite... seems the way open chat functions has been altered on a basic level. I am REALLY hoping this is not a "new feature".

I have asked about it:

/139/9b/122588/1.html#post1160447

I, too am having this problem along with many others since the updates yesterday. i hope they get it fixed soon.

I, too am having this problem along with many others since the update yesterday. i hope they get it fixed soon.

My AV is possessed now. Aside from this kind of strange change they made to chat, I seem to get into states where clicking any of the buttons on the bottom (like Search), editing anything, etc. turns her in a counter clockwise spin. I'm not sure if that or the jumping, turning, and having nothing I am typing being captured is more annoying.

Happening to me as well.

At first I thought maybe I had checked/unchecked something in preferences that was making the chat bar disappear after hitting return.... but now that I hear other people are having the same problem, I'm not feeling so bad for not being able to find the option to re/uncheck it.

Seems to me this update has been more messed up than usual... and this is after it was set back a week... wonder what the deal is.

-Ghoti

Reading... thread aggregated. It's in my queue now to check out. I'll post back with an update of what I find.

[UPDATE] Found out from Quality Assurance that "Hitting enter while chat history has focus should focus the chat bar" is a bug we've got entered. Apparently one that woke back from the dead after being fixed before.

So, it'll hopefully be fixed soon.

This is also known about--and we're also aware of the suggestions from earlier: when scrolling while dragging the mouse *did* work, that it was also too *slow*. Scheduled to be fixed.

Thank you for your attention to these matters.

Part of the new enter-key behavior is actually a feature:



The problem is that it's totally confusing, disorienting, and really makes things a lot more difficult... at least for me. Was this addition actually helpful to some people?

As far as I understand it, there are two ways people use the chat bar in SL. One is that they turn on the "[x] hitting enter closes the chat bar" option, which has been around for awhile (and which some people might have seen get reset because all preferences were wiped). Whenever they want to talk, they press enter, type, press enter to send, and then the chat bar goes away. With the new behavior in 1.11, my assumption is that if they press enter, decide not to talk, and press enter again, the chat bar goes away.

I do things differently. I turn that option off. Whenever I want to talk, I press enter and type, and press enter again to send. I might immediately type more lines... sometimes I get long-winded. Whenever I want to walk, I press escape first. I press enter before talking and escape before walking no matter what, even if it'd end up being unnecessary... ie I've looked away at my other screen, come back to chat something, and I'm pressing enter before chatting but my chat bar was already up. To me, pressing enter or escape before my action is a catch-all that gets SL into the mode I want it to be in.

Now, though, it doesn't work like that. Half the time I press enter before chatting, the bar is already up, and my enter closes it on me, and I noob-hop (ie my keystrokes become av commands). This is a huge, confusing departure from previous behavior, and it's going to take me a long time to relearn patterns, if I ever do.

Worse yet, what's happening here could be described as "hitting enter closes the chat bar". However, I have that option off: "[ ] chat bar closes after pressing enter". The new functionality has basically changed the behavior of that option to this: "[ ] chat bar closes after sending text". It closes after pressing enter if it's empty, and I don't have a choice on that.

So the new behavior is completely confusing. It assigns multiple behaviors to the enter key that won't map easily in a user's head. It directly contradicts what seems to be the spirit of an option in preferences. Does anyone benefit from this new behavior? It'd be interesting to hear from you what your interaction patterns are in the SL client.

^ Got it. WOW what an excellent digest! Including it in our feedback for the developers.

Thank you Lex,
I couldnt for the life of me figure out how to word what i was experincing. That is it excactly! It is VERY frustrating LOL.

Yup yup. I couldn't even SEE the entire description; had to try to remember what it said and erase the whole thing to put in the extra words I wanted to. I will try the arrow keys trick.

And it seems to me that in changing the numbers, say, wanting to make something 93.456 instead of 93.452, I used to just highlight the individual number I wanted to change and change it.

Now it highlights the whole thing. I can either retype the whole number, or do this little extra step to get it to highlight the sole number.

A little thing, but multiply that extra step by the number of times a builder wants to do that action, and you have yet another thing that unnecessarily adds time to building.

I also recall - or THINK I recall - that a few updates ago, you used to be able to change the texture on a new face without getting entirely out of the texture/color box to do it. Now I have to get out of it, put it back up, refind the texture, and apply it to the next face. That problem is still there.

I hate it when something that once took one step now takes two. I realize they are bugs and not intentional, but this sort of bug seems to be very low on the priority list to fix, like, not within this lifetime. And they add up, so that building takes longer and longer.

coco

P.S. Torley, I see you're here - maybe you could add that individual number behavior, and the texturing one, to your list.

Instead of using the left / right arrow keys to get to the end or beginning of a text box, try using the down arrow to jump to the end and the up arrow to jump to the beginning.

Here's another problem: I clicked an item and "select texture" to put the same texture on another box.

It wouldn't tell me what it was!

I had to search for it (I had done that build a long time ago). Fortunately, my inventory is fairly organized, so I was able to find it by going through only one folder and clicking on the textures within.

I hope this is a bug. I would rather NOT have the eyedropper than have the eyedropper but no way to identify textures.

coco