GetMousePosition - top and left edges

Development Platform & Builds
, , ,
1

Hi,

Myself and loads (if not all) of our linux users are getting a problem with the cursor position along the top and left edge of the screen.

To recreate, set up a new template C++ project (I went with TopDown) and insert this code somewhere (PlayerController’s Tick for example):

CursorLocResultReturned = this->GetMousePosition(CursorLocResultX, CursorLocResultY);

with the associated variables (bool CursorLocResultReturned, float CursorLocResultX, float CursorLocResultY) defined elsewhere such that they can be inspected in a packaged game. For example, I had them as PlayController variables and made a UserWidget blueprint that fed their values to Text fields on the screen.

Then package this project for Linux and run it on a reasonable end-user distribution. At full screen (default) everything is fine, until you give the window focus (by clicking on it). Then I always find that at x=0 or y=0, GetMousePosition, returns false and the CursorLocResult are not filled. Again - before I click it is returning true and they are being filled, it’s only once I click in the game world that this behaviour changes.

Why is this? Is there anything I can do stop our users experiencing this? We run an RTS and measuring the cursor location is key to screen-edge map scrolling.

Look forward to hearing suggestions.
Matt

2

I’m also experiencing this issue in Linux, but for me it also happens on full screen. When the mouse is at X=0 or Y=0, GetMousePosition returns false.

3

Dear valued Unreal Engine user,

Mouse and gamepad input has always been a tricky area for non Windows platforms on Unreal. Yaakuro has been doing an exemplary job of patching mouse input from the platform layer. Unfortunately, there are fundamental differences between how other platforms work compared to Windows and the Slate framework in UE4 is purely based on how Windows works. To fix this reliably, the Slate and Windowing system really needs to be redesigned with cross-platform in mind.

I am sure Steel Wool would be really interested in fixing this on behalf of Epic Games. However, I am currently stuck in Canny Valley so unable to reach Lars, Syd or Carlos. Any chance you could help?

As this does not really help you solve you issue, here are some tips to debug:

The first port of call would be to test with Github master (4.27) to see if this bug has already been solved. If it has not then you are probably going to have to find a work around.

One area you could look into is if you are correctly locking the cursor to the viewport (e.g. EMouseLockMode::LockAlways). If not, you may have unexpected behavior between different platforms, as the mouse co-ordinates leave the viewport.

Your best bet here would be to add a conditional breakpoint into APlayerController::GetMousePosition(float& LocationX, float& LocationY) in Engine/Source/Runtime/Engine/Private/PlayerController.cpp, for example only break when bGotMousePosition is false. Alternatively add a UE_LOG macro with the value of LocalPlayer->ViewportClient and bGotMousePosition. Then drag the mouse cursor to the X=0, Y=0 position and it should break in the debugger or print out the values at that point. You could then look to see if LocalPlayer->ViewportClient is nullptr or if simply UGameViewportClient::GetMousePosition returned false. If UGameViewportClient::GetMousePosition is returning false, it would seem like the most obvious case is that FSceneViewport::GetMousePos is returning negative co-ordinates, likely because the system is running with some kind of global coordinate system. If that is the case, a work around may be clamping the results of FSceneViewport::GetMousePos to >=0 e.g. min/FMath::min, and probably wrap that with a Linux only macro and only when not running via the editor.

Hope this gives you some pointers, and please do write back or submit a github pull request if you find a solution.

Thank you for your continued support,