[BUG-11703] OS X El Capitan: Left-click on avatar then moving mouse causes camera to fly directly over the avatar pointing down to the ground

[sl-service-account]

Steps to Reproduce

My normal method for navigating my avatar through a scene is to primary-click (left-click) on it with the mouse in my right hand and, while holding the primary mouse button down, use the W keyboard keys with my left-hand to propel the avatar forward, steering the direction of it by simply moving the mouse. I have been doing this to move the avatar forward since the days of the V1 viewer and, until very recently, have been able to do this with the V3 viewers. I can still do this using a V1-UI viewer, such as Singularity or Cool VL Viewer.

Actual Behavior

When left-clicking on the avatar, then moving the mouse while keeping the primary mouse button held down, the camera shoots directly overhead of the avatar and points straight down toward the ground. This behavior started right after I reset the CameraOffsetRearView and FocusOffsetRearView debug settings back to default. Previously I had used custom settings for the past year when moving from version to version of the SL viewer so knowing exactly when this bug appeared I cannot say. All I can tell you is that once those debug settings were reset, the camera now exhibits this strange behavior.

Expected Behavior

What I expect is to be able to steer the avatar the way I always have, guiding it in any direction with the primary button on the mouse held down on the avatar while moving forward with the W key.

Other information

I first noticed the peculiar behavior when I installed the Alchemy 4.0.0 beta viewer from a fresh install (no left-over ~/Library/Application Support/Alchemy/* directory). Until that point, the Alchemy 3.8 series of viewers had been working fine. I did not see this behavior with the Kokua 4.0.2 build either but Kokua versions had been updated while maintaining the same ~/Library/Application Support/Kokua/* directory over the course of many versions. I also kept the ~/Library/Application Support/SecondLife/* directory hanging around for the SL viewer since the early 3.6 series of viewers. Only after I reset the CameraOffsetRearView and FocusOffsetRearView debug settings for SL viewer did this camera behavior manifest itself. Why the V1-UI based viewers are unaffected by this behavior I do not know but if given the choice, I would dearly love to be able to keep the behavior of being able to steer the avatar by using the mouse.

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-11703 | | Summary | OS X El Capitan: Left-click on avatar then moving mouse causes camera to fly directly over the avatar pointing down to the ground | | Type | Bug | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | SappadilliDallagio (sappadillidallagio) | | Created at | 2016-04-04T12:11:13Z | | Updated at | 2016-04-14T14:40:37Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2016-04-04T12:20:34.718-0500', "Is there anything you'd like to add?": 'I first noticed the peculiar behavior when I installed the Alchemy 4.0.0 beta viewer from a fresh install (no left-over ~/Library/Application Support/Alchemy/* directory). Until that point, the Alchemy 3.8 series of viewers had been working fine. I did not see this behavior with the Kokua 4.0.2 build either but Kokua versions had been updated while maintaining the same ~/Library/Application Support/Kokua/* directory over the course of many versions. I also kept the ~/Library/Application Support/SecondLife/* directory hanging around for the SL viewer since the early 3.6 series of viewers. Only after I reset the CameraOffsetRearView and FocusOffsetRearView debug settings for SL viewer did this camera behavior manifest itself. Why the V1-UI based viewers are unaffected by this behavior I do not know but if given the choice, I would dearly love to be able to keep the behavior of being able to steer the avatar by using the mouse.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'When left-clicking on the avatar, then moving the mouse while keeping the primary mouse button held down, the camera shoots directly overhead of the avatar and points straight down toward the ground. This behavior started right after I reset the CameraOffsetRearView and FocusOffsetRearView debug settings back to default. Previously I had used custom settings for the past year when moving from version to version of the SL viewer so knowing exactly when this bug appeared I cannot say. All I can tell you is that once those debug settings were reset, the camera now exhibits this strange behavior.', 'What were you doing when it happened?': 'My normal method for navigating my avatar through a scene is to primary-click (left-click) on it with the mouse in my right hand and, while holding the primary mouse button down, use the W keyboard keys with my left-hand to propel the avatar forward, steering the direction of it by simply moving the mouse. I have been doing this to move the avatar forward since the days of the V1 viewer and, until very recently, have been able to do this with the V3 viewers. I can still do this using a V1-UI viewer, such as Singularity or Cool VL Viewer.', 'What were you expecting to happen instead?': 'What I expect is to be able to steer the avatar the way I always have, guiding it in any direction with the primary button on the mouse held down on the avatar while moving forward with the W key.', 'Where': 'http://maps.secondlife.com/secondlife/Long%20Lake/25/210/22', } ```

[sl-service-account]

SappadilliDallagio commented at 2016-04-04T12:23:17Z

Additional information found in the OS X console log messages; an error which corresponds to when I was attempting to guide the avatar with the mouse: 2016-04-04 07:30:06.000 kernel[0]: AMDRadeonX3000_AMDAccelDevice: IOUserClient outputCount count mismatch

That error gets written to the log every time an attempt is made.

[sl-service-account]

Kyle Linden commented at 2016-04-04T17:20:35Z

Hello SappadilliDallagio,

Are you using Second Life on a second monitor when this happens?

This is a possible duplicate report of BUG-6760 or BUG-3860.

Please update this issue with any new information and press the Info Provided button.

Thank you

[sl-service-account]

SappadilliDallagio commented at 2016-04-04T17:48:03Z

Thank you Kyle for responding.

I am not running a secondary monitor. This is an iMac running SL viewer on its inbuilt display.

On the face of it my issue may appear to be similar but not exactly. In the two other issue reports, the users were attempting to Alt-Click, Option-Click, or some other similar combination. My case is just a simple PrimaryMouseButton-click on the avatar then attempting to move the mouse. Perhaps that uses the same set of code as in the other two reports, maybe it does not.

Since posting my report earlier today I tried a couple of things. Some caused the behavior but the final thing I tried seems to have squashed it (for now).

The first thing I did was to clean out the Second Life viewer's files from ~/Library/Application Support/SecondLife/ (but not the subdirectory entirely as that is shared with two other viewers, Singularity and Cool VL Viewer). After reinstalling the SL viewer and running it, the misbehavior remained. I even removed the entire Alchemy Viewer and Kokua viewer support files from ~/Library/Application Support/ knowing that they should not have any bearing on the SL viewer. As I suspected, the misbehavior remained in SL viewer.

Manually purging the files of Cool VL Viewer and Singularity from the Application Support folder and rerunning SL viewer did not change the situation either.

I decided to use AppCleaner (from FreeMacSoft) to remove all viewers entirely. That little app scours the system level places not accessible to users for various files applications put there and sure enough, it found some .playlist and /var/db/ files belonging to each viewer. Those were deleted and SL viewer was reinstalled. Running it has cured the misbehavior (for now). Apparently whatever caused the issue had something to do with those .playlist or /var/db/ files belonging to SL viewer.

That is where it stands with me for now. I can use the mouse to guide the avatar again. As for the mouse actions of those other two issues, I also seem to have no problem moving the camera around via panning, orbiting, or zooming use those actions.

Thanks again and hope this helps.

[sl-service-account]

Kyle Linden commented at 2016-04-04T21:06:22Z

Hello SappadilliDallagio,

I believe I just reproduced your issue.

Will you please go into Me > Preferences > Move & View, then under Single click on land: select No Action.

Now if you click on your Avatar does the camera go totally vertical looking straight down at your head?

Please press the Info Provided button and let me know what you find.

Thanks!

[sl-service-account]

SappadilliDallagio commented at 2016-04-05T00:43:17Z

Kyle,

I always have "No Action" as the selection for Single-Click under move and view. As of right now, the viewer is behaving itself so no, the camera did not go vertical pointing downward.

I even revisited the debug settings CameraOffsetRearView and FocusOffsetRearView by customizing, relogging, then changing them back to defaults (which was the trigger I assumed to cause the misbehavior in the first place). No change; the camera behaved normally and as I expected.

As I was clicking on the avatar and twirling it around, I did notice something bizarre and not seen before... the avatar started the default typing animation as I was spinning it around with the mouse. That is even with the typing animation turned off in Preferences. No big deal but it does seem strange.

If you think of anything else you wish me to try, let me know. I am a pretty decent crash test dummy. :)

[sl-service-account]

SappadilliDallagio commented at 2016-04-05T00:48:51Z

Well, spinning the avatar with the arrow keys or the A & D key will also put the avatar into the default typing animation, regardless of whether the typing animation option is enabled or disabled in the Preferences > Chat section. Truly strange.

Not sure what that has to do with my original report. I just mention it as it is something that seems to have just started while I try to repro my original problem.

[sl-service-account]

SappadilliDallagio commented at 2016-04-05T03:14:07Z

A couple of relogs later (one of which I had to force quit because the viewer hung on exit), the avatar no longer types as it spins. Everything seems fine.

I have no idea...

[sl-service-account]

Gavin Hird commented at 2016-04-05T06:09:16Z

I see you have a quite new iMac, which mouse do you use?

I cannot repro the issue both in our latest Kokua 4.0.2 build that has a LL commit to change the OS X Mouse behavior on drag, or on the LL Second Life 4.0.3 (312816) build I believe has the same code change.

Link to the changed code https://bitbucket.org/lindenlab/viewer-lion/commits/81cbd9151dca3bd0268e16ff3b12385c4a185edb

The only issue with that portion of code is that it cause a kernel panic with the Steermouse driver installed on OS X 10.11.4 Steermouse is a 3rd party driver for gaming type mice. Because of this I believe Apple must have made changes in the 10.11.4 release that affects mouse behavior.

[sl-service-account]

Whirly Fizzle commented at 2016-04-05T06:28:18Z

LL Second Life 4.0.3 (312816) is default release & it does not include https://bitbucket.org/lindenlab/viewer-lion/commits/81cbd9151dca3bd0268e16ff3b12385c4a185edb. That changeset only seems to be in Bear, Lion & Lynx currently.

[sl-service-account]

Gavin Hird commented at 2016-04-05T06:38:21Z

OK, thanks Whirly. Perhaps he can try the latest Kokua 4.0.2 build (this will be the release) and see if it behaves different. https://sourceforge.net/projects/kokua.team-purple.p/files/Kokua-4.0.2/Kokua_4_0_2_38137_i386.dmg/download

This is built with Xcode 7.3 with deployment target OS X 10.9 and the OS X 10.11 SDK.

[sl-service-account]

SappadilliDallagio commented at 2016-04-05T23:46:13Z, updated at 2016-04-05T23:47:43Z

Another day has gone by with nothing of the problem of my initial report. Either it was a one-off issue fixed by something I did yesterday or it is one of those head-scratching, very intermittent gotchas. I will keep an eye on things and report back if the problem returns (or open a new issue if this one ends up being closed).

I use two mice: the bluetooth Apple Magic Mouse that came with the iMac and an old but very usable Logitech Cordless Trackball FX. The issue showed up using both of those devices. I think the trackball uses whatever mouse driver that comes with OS X as I have not installed any third-party drivers for it.

Will give Kokua a try. I stopped using the 4.0.1 version because it would not refresh my view of the scene after I detached attachments. Others saw they were detached but I never could until I relogged. That got old when in roleplay scenes.

[sl-service-account]

Kyle Linden commented at 2016-04-05T23:53:02Z

Hi SappadilliDallagio,

This issue has been accepted based on the easy repro on my end. New information always welcome.

Thanks!

[sl-service-account]

SappadilliDallagio commented at 2016-04-07T02:13:10Z

Just an update for today. The SL viewer camera did not exhibit the weird camera motion I described when opening this issue. However, I took Gavin's advice as posted in an earlier comment and tried the Kokua version for the URL he supplied. That DOES exhibit almost the same camera weirdness as I first reported for the SL viewer, with the exception that Kokua drops the camera below the avatar and points directly upwards. Kokua also exhibits the same type of camera misbehavior as found in the other two JIRA reports that Kyle asked me to check into from his first comment.

I know this is not a trouble tracker for Kokus (I will visit their bug tracker and enter appropriate comments there) but I am posting the About Kokua... info here in case it will help LL track this peculiar bug down:

Kokua 4.0.2 (38137) Apr 4 2016 09:17:43 (Release) Release Notes

Kokua support group on Second Life: Kokua

You are at 102.4, 185.8, 22.1 in Long Lake located at sim9174.agni.lindenlab.com (216.82.42.110:13029) SLURL: http://maps.secondlife.com/secondlife/Long%20Lake/102/186/22 (global coordinates 202854.0, 343994.0, 22.1) In region Long Lake at (792, 1343) Second Life Server 16.03.04.312045 Release Notes

CPU: Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz (2500 MHz) Memory: 4096 MB OS Version: Mac OS X 10.11.4 Darwin 15.4.0 Darwin Kernel Version 15.4.0: Fri Feb 26 22:08:05 PST 2016; root:xnu-3248.40.184~3/RELEASE_X86_64 x86_64 Graphics Card Vendor: ATI Technologies Inc. Graphics Card: AMD Radeon HD 6750M OpenGL Engine

OpenGL Version: 2.1 ATI-1.42.6

RestrainedLove API: Disabled J2C Decoder Version: OpenJPEG Runtime: 1.4.0 Audio Driver Version: FMOD Ex 4.44.61 LLCEFLib/CEF Version: 1.5.3-(CEF-OSX-3.2171.2069-32) Voice Server Version: Not Connected Built with Clang version 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.29) Packets Lost: 81/27321 (0.3%)

[sl-service-account]

SappadilliDallagio commented at 2016-04-07T14:00:32Z

And, just like what happened with the SL Viewer, Kokua no longer shows the weird camera behavior after a system restart. SL Viewer still working normally too. Just a wild idea buy maybe something with how the viewer first initializes that is not picking up the mouse driver in OS X correctly until after a system restart?

[sl-service-account]

SappadilliDallagio commented at 2016-04-14T10:40:52Z

After updating the LL viewer to Second Life 4.0.4 (313869) Apr 12 2016 10:57:22 (Second Life Release) yesterday there was one brief moment where the camera flew directly overhead of the avatar when clicking on it with the Magic Mouse primary mouse button. It was a very brief moment though as the camera settled back to its normal position behind the avatar. Otherwise the camera has behaved as expected when using the Magic Mouse or the Logitech Optical Trackball FX.

[sl-service-account]

SappadilliDallagio commented at 2016-04-14T14:40:38Z

Doing some more playing/debugging of this issue with both the latest SL viewer and the latest Kokua release and was able to, for a little while anyway, repro the original problem about 90% of the time. Here is how:

1. Start the viewer with a window size of 1280x720, with its window positioned in the lower right corner of the display (which is a non-Retina 1920x1080 resolution on my iMac 12,1 model). Log into SL.

2. Click on my avatar with the primary mouse button and move the device with that button depressed. For the SL viewer, that pretty much makes the avatar move as I expect; it twists left or right or the camera moves above and below the avatar, depending upon the direction the device is being moved. Press the ESC key to reset the camera view. (For the Kokua viewer, it immediately throws the camera beneath the avatar looking straight up and only the slightest movement of the pointing device causes the avatar to twist extremely rapidly.)

3. Reposition the viewer window to the top left of the iMac display and click on the avatar again. For the SL viewer, the camera is immediately thrown above the avatar looking straight down and the avatar only twists left or right kind of at a normal speed no matter which way the pointing device is moved while the PMB (primary mouse button) is held down. (For Kokua, there is no change in how it behaves; doing the same thing as point #2 in this comment.) Press the ESC key to reset the camera.

4. Move the viewer window to the top right of the iMac display and click on the avatar again. With the SL viewer the camera flies overhead of the avatar looking straight down, and it twists rapidly left/right no matter which direction the pointing device is moved, with the PMB depressed. (For Kokua, similar to how it behaves from the previous two points). Press the ESC key to reset the camera.

5. Move the viewer window to the bottom right corner of the iMac display and repeat the PMB/pointing on the avatar. The SL viewer does not fly the camera overhead but it is instead "locked" on the horizontal plane for which it is set. The avatar spins rapidly left/right no matter how the pointing device is moved. (The Kokua viewer showed no difference from its previous tests, doing the same as it has.) Press the ESC key.

6. Move the viewer window to the relative center of the iMac display and repeat the PMB/pointer test. The SL viewer throws the camera high overhead looking straight down and causes the avatar to spin rapidly left/right. (For Kokua, no change from its previous behavior.) Press the ESC key.

7. Use the OS X window "Zoom" button to take the viewer to full-screen OS X style. Retry the test. The avatar and camera move as expected, i.e., when clicking on the avatar and moving the pointer, the avatar will turn and the camera will move up and down depending upon which direction the pointer is being moved. This behavior happens with both the SL viewer and Kokua. Press the ESC key to reset the view.

8. Return the viewer into windowed mode and retest. In about 90% of the times I have tried, the results will be as points 2-6 in this comment have shown, for both viewers. Sometimes, though, the weirdness does not return once the viewers are back into windowed mode. Log out of SL.

9. Relog into SL; both viewers should start up as the previously sized windows. Retest. In about 90% of the times I have tried, the viewers will exhibit the same weirdness as the previous points have detailed. Sometimes, though, both viewers will have no weirdness.

If I keep the viewers in the OS X full-screen mode, the camera behaves as I expect it to when moving the avatar via pointing device; behaving as I have always seen it behave dating back to the SL 1.23 viewer. What I am gathering is what I call the weirdness happens when the viewer is framed within an OS X window (but only for a majority of the time, not every time).

Why do I use a window? Simply put, the GPU in my iMac has a history of under-performing when in full-screen mode, no matter if it is installed in a linux, Windows, or OS X system. The "sweet spot," as far as FPS response is concerned, for this GPU is found in a usable window resolution size between 1280x720 to 1366x768. Much of what I do in SL can be done in full-screen mode but when I go to a live music event, for example, where there are more than a handful of avatars, being able to drop into a window with the viewer allows me to see the movement in the scene at a decent frame-rate without the stuttering stop-motion rate that full-screen mode presents to me in those cases.

Now that I know how to work around this camera weirdness, I can more or less control its annoyance factor. If I find a more refined way to repro the condition 100% of the time I will post it for sure. But until that time, I hope this info helps to bring some potential causes for it into focus.