[A16] Middle Mouse Button Map Panning in Linux

Started by CephalopodDarius, March 12, 2017, 09:52:59 PM

Previous topic - Next topic

CephalopodDarius

Tested Version: 0.16.1393, OS: Linux (Arch, Antergos, Debian, Ubuntu, Xubuntu, Gallium OS, Kali, Manjaro)

Holding on the middle mouse button and moving the mouse does not pan the camera in Linux.

This had previously been submitted to the bugs forum (link) but was closed as it was suspected to be a bug in Unity.

I used the developer tools to monitor input events, found that the middle mouse up/down events do get picked up by RimWorld in Linux, and I wrote a mod which checks the state of the middle mouse button and handles camera panning to verify that the middle mouse panning issue isn't happening on Unity's side (source code for the mouse panning logic can be found Here ). Hopefully that can help you zero in on what's causing this issue. It's jarring to have the middle mouse panning not work in Linux after playing in Windows for a while, so I'm sure a fix for this would make a lot of Linux users happy =)

Thanks in advance for taking a second look at this!

DanielCoffey

I have just had a look at my game on Mint 18.1 which has a normal mouse and a Wacom Intuos4 tablet and checked which buttons do what.

I can confirm that LMB selects, RMB moves the camera and opens menus on objects (such as Prioritize Hailing and similar) and MMB on both devices does nothing. Scroll Wheel on the mouse zooms of course but not the Scroll Ring on the tablet because it is not recognised in Mint.

What is the expected behaviour then?
Caselabs S8 : Intel 7700K 5.0GHz 1.30V / 32Gb DDR4 3000 / ASUS 780 Ti 3Gb 1274 boost, 7800 mem / Samsung 850 Pro 256Gb, 2x Samsung 840 Pro 256Gb / Dell U2715H 27" 2560x1440 / Corsair AX860I / APC SMT1000I / Linux Mint 18.1 64-bit

CephalopodDarius

#2
According to the in-game Learning Helper, panning the camera is the intended behavior of the middle mouse button. In Windows holding the middle mouse button and dragging the mouse pans the camera appropriately. It's similar to the right mouse button, except it moves the camera by about the same distance as the mouse cursor moved (right mouse button panning barely moves the camera at all--kinda useless IMO). Also, the middle mouse button doesn't have any other behavior assigned to it, so you won't open a context menu and accidentally assign orders.

ison

Right mouse button shouldn't pan the camera.

It looks like on Linux some MonoBehaviours do not receive the OnGUI() events. I have no idea what could cause this.

DanielCoffey

Is there anything we can do to help narrow it down for you?
Caselabs S8 : Intel 7700K 5.0GHz 1.30V / 32Gb DDR4 3000 / ASUS 780 Ti 3Gb 1274 boost, 7800 mem / Samsung 850 Pro 256Gb, 2x Samsung 840 Pro 256Gb / Dell U2715H 27" 2560x1440 / Corsair AX860I / APC SMT1000I / Linux Mint 18.1 64-bit

CephalopodDarius

#5
Huh, I actually hadn't noticed before that the right mouse button doesn't pan in the Windows build. The Learning Helper in the game says that panning can be done by holding down the middle or right mouse buttons, so I thought that was universal.

Since there's a Mac build and Macs usually don't have a middle mouse button maybe there's an Application.platform check somewhere to see if it's running in Windows, and if not the MonoBehaviour that handles middle mouse panning is not attached/has enabled set to false, and a MonoBehaviour intended for Macs is attached/enabled instead?

ison

The whole camera input handling is done in one place, so if zooming works then panning should also work. The problem is that the panning code is very simple, it's just:

if( Event.current.type == EventType.MouseDrag && Event.current.button == 2 )
{
    mouseDragVect = Event.current.delta;
    Event.current.Use();
}


So either:
1. MouseDrag event is never generated (input logging doesn't log this event though, so you won't be able to check it)
2. MouseDrag event is generated but it's consumed by something else for some reason on Linux
3. MouseDrag event is generated for buttons 0 (left) and 1 (right), but not for 2 (middle).
4. MouseDrag event is generated but Event.current.delta is always 0

I think it's 4. But no matter which one it is I'm not sure we'll be able to solve it, because it's handled internally by Unity.

Quote from: CephalopodDarius on March 13, 2017, 06:42:15 PM
Huh, I actually hadn't noticed before that the right mouse button doesn't pan in the Windows build. The Learning Helper in the game says that panning can be done by holding down the middle or right mouse buttons, so I thought that was universal.

Could you please attach a screenshot? I've just tried the tutorial and it didn't say anything about panning with the right mouse button. Thanks.

CephalopodDarius

#7
Found the issue. I added an OnGUI handler to check out the MouseDrag event. The event is raised and has a non-zero delta, but for some bizarre reason the event is using the wrong code for the mouse buttons. Event.current.button is 1 when holding the middle mouse button down, and 2 when holding the right mouse button down (which explains the weird right mouse panning).

I made a test scene in Unity 5.6.0b10 and in this version the MouseDrag event has the correct button code for the middle mouse button (2), so it does seem to be specific to the version of Unity RimWorld is using.

Since Input.GetMouseButton isn't affected by this bug, this should fix it:


if (Event.current.type == EventType.MouseDrag && Input.GetMouseButton(2))
...



[attachment deleted by admin due to age]

b0rsuk

On my machine - Debian Linux (Jessie) with KDE - middle mouse button doesn't do anything. However, I can pan with right mouse button, but it toggles (not disables or enables) the Architect menu each time I press it. The sound and blinking menu is distracting.

ison

Thank you CephalopodDarius, very interesting!

So it looks like there's a bug in the Unity version we're currently using (5.4.1f1).

Unfortunately we can't use Input.GetMouseButton(2) because Input returns real-time input which can be different than the event's input.

I'll leave this thread open for Tynan.

CephalopodDarius

#10
Ah, fair enough. Since it only affects one client type you could also just change the button definition for Linux in this Unity version, eg:

private int MiddleMouseButtonCode = (Application.platform == RuntimePlatform.LinuxPlayer && Application.unityVersion == "5.4.1f1") ? 1 : 2;
public void OnGUI()
{
if (Event.current.type == EventType.MouseDrag && Event.current.button == MiddleMouseButtonCode)
...


It would only affect Linux clients and wouldn't break anything when you update Unity. Pretty much any workaround for this is going to add code that will become dead-weight once Unity is updated, though, so I totally understand if you all would rather wait for an engine update :)

Tynan

It does look like it's a Unity bug.

The simplest solution does seem to be to make the mouse button codes into static readonlys somewhere, and have the game set them differently on Linux.

Unless Linux is actually combining buttons 1 and 2, which would be a real problem...
Tynan Sylvester - @TynanSylvester - Tynan's Blog

Tynan

Okay, we'll update Unity for the next alpha (not A17). That should solve it. Thanks.
Tynan Sylvester - @TynanSylvester - Tynan's Blog