Shift key blocks other CONTROL when avatar sits

Description

What steps will reproduce the problem?

Construct a device to take controls by touch or sit.

What is the expected output? What do you see instead?

When taking controls by touch, the result matches the lsl documentation. The Shif key has no effect on CONTROL_FWD | CONTROL_BACK | CONTROL_UP | CONTROL_DOWN. If does shift the CONTROL_ROT_* to CONTROL_* as expected.

When taking controls of a sitting avatar the behavior does not match the lsl spec. The Shift key blocks CONTROL_FWD | CONTROL_BACK | CONTROL_UP | CONTROL_DOWN, causing the control event in the script not to fire.

What version of the product are you using? On what operating system?
I tried this on two different alpha versions + the latest release on Linux x64

Original reporter: BlueWall...@gmail.com

Environment

None

Activity

Show:
Liru Færs
March 4, 2015, 4:18 PM

This is the way it's always been.
It doesn't block it, it's just not set up to do anything... it's not supposed to cause anything.. it's not a bug.

Anonymous
March 4, 2015, 5:10 PM

I tested on Kokua before posting this and the control event behaves the same regardless of whether the avatar elects to give controls by touch or by sit.

Why would sitting cause a different behavior? Why does the event continue to fire using Kokua when the shift key is held? Should the behavior not be consistent?

Comment by: BlueWall...@gmail.com

Anonymous
March 7, 2015, 11:10 PM

I'm not sure you understand. I know the shift key+Up doesn't trigger the control event. But, the shift+Left/Right does. And the event services multiple key presses. We check for all keys in the event in case there are combinations. It works properly if the script takes control with the touch event. If I press the Up key for forward, and I press the Shift+Left/Right key, then when I apply masks to test, I pickup all the keys. This is proper operation. However, when the script takes controls when an avatar sits, the only keys that make it to the control event are the CONTROL_RIGHT and CONTROL_LEFT. All others are blocked. This is wrong.

If it is right, then it needs to block the keys if control is take by touch as well?

Comment by: BlueWall...@gmail.com

Liru Færs
March 8, 2015, 5:02 AM

Again, it's not blocked, it's just not in the old control scheme, apparently LL updated it, so I'm adding the new keys, it'll be in the next alpha.

Liru Færs
July 25, 2015, 4:17 AM

I fixed this a few months ago.

Fixed

Assignee

Liru Færs

Reporter

Anonymous

Labels

None

Build Number

None

External issue ID

1849

Priority

Medium
Configure