Hey guys,
We’re currently working off of 4.8.2, and I’ve found that when re-sizing the View-port in the standalone version of the game, it causes the mouse input to be offset in UMG/Slate.
It seems as though the new view-port size/Resolution is not being updated in Slate/UMG, and is using the old size to calculate the mouse location, which is incorrect.
Has this been fixed at all in newer versions? if so, what change-list in the Git Repo is the fix?
Cheers.
Hey -
I addeda UMG button to the center of the screen and then using the “setres” console command I tried setting the standalone window to different resolutions. Each time the UMG button would respond to my click when I clicked the center of the screen. If this is not the behavior you’re seeing could you provide reproduction steps for me to create the same setup that you’re using.
Cheers
So after doing some playing around, swapping between full-screen and windowed mode seems to be the actual issue.
So for example, Swapping between the commands “setres 1024x768f” and “setres 1024x768w” causes the issue to happen.
Specifically on the window mode the game did NOT start in. (so if we started in full-screen, then windowed mode has offset issues.)
I’m guessing this might have something to do with Linux not handling Full-screen correctly. (I’ll enter it as another bug.)
Also forgot to mention in the original bug that i’m working on Ubuntu 14.04 LTS.
NOTE: This is easier to see if there is a button highlight on hover over (Something we have in our game)
Hope that helps. 
Hey -
I was able to reproduce this on both Linux as well as Windows and I’ve entered a bug report (UE-19988) for further investigation.
Cheers
I still have this problem. My Unreal Engine version is 4.17.2
Probably a good idea to start a new question in the bug reports section with a link to this question.
Also include the repro steps so they can fix it.
same problem here
So apparently they can’t reproduce this issue…
You’ll need to probably submit a bug and create a new answerhub post.
Hopefully you’ll have better luck getting them to fix this issue than I have…
Why was this marked as “cannot reproduce” when said he could reproduce it?
Can we get more information on this? Are you chalking it up to an issue with Windows and not UE4?
This is still a problem, i’d like to know as well
Bumping this: from my testing it seems that this issue only occurs if you are using a second monitor? When I run my game on my main monitor, it behaves fine, but if I move it to my second monitor and start changing resolution, then the mouse gets super offset.
From what I can tell, whatever is in charge of mouse position uses the resolution of the first monitor, even when the game is running on a different one with a different resolution?
@Devolution.exe I’m having big troubles with this still. I have two monitors, where the primary one is a high-DPI model. My issue, in case you (or someone) else discovers a solution:
It is exactly as you describe:
I can start the application perfectly fine on the primary monitor. But if I start on the secondary monitor the mouse coordinates are just wrong. If I switch monitor then sometimes this also messes up the mouse coordinates when switching to the secondary monitor.
There are quite a few variables involved here: UGameUserSettings, the UGameViewportClient, FSlateApplication, the GEngine->GameViewport, and I’m not quite sure where to look.
Any help is appreciated. And I will post here if I discover a solution.
@Devolution.exe I might have found a solution to the problem. The full discussion is in the thread I mentioned. The “fix” is adding these lines to <project>/Config/DefaultEngine.ini:
[ConsoleVariables]
Slate.Transform.FullscreenMouseInput=False
The real fix is probably to fill a bug report to the engine team.
Thanks! That worked for me. Although if Epic wants to fix the underlying bug i have a 100% repro case without this courtesy of our QA. Open in full screen mode on dual monitor, then switch to Windowed. Drag the window to the other screen, switch to Windowed fullscreen and then Fullscreen. Then switch to a lower resolution and apply it (it seems to be any lower resolution). I figured out that switching back to the highest resolution using controller fixes it, so the mouse seems to think it’s in that resolution no matter what you switch to.
Yikes…
Once you get deep enough inside the engine code you discover that many things is a big spaghetti mess. But at least the artists are happy, no? ^^
if Epic wants to fix the underlying bug
This is the problem, isn’t it? Apparently SlateApplication has a lot of bugs (I have heard), and there are other input-related things with how Slate works with GameViewportClient. I’m beginning to understand why big game companies compile Unreal themselves.
Also, if I was in Epic’s shoes - I would probably be really afraid/careful in starting to mess with these things. I’m not confident these things are going to get fixed