Project

General

Profile

Bug #477

Game stops responding to mouselook camera turns if mouse cursor leaves desktop (Multiplicity and similar) and returns to game window

Added by Jarnis about 11 years ago. Updated over 9 years ago.

Status:
Closed
Severity:
Normal
Assignee:
-
Category:
Controls and UI
Target version:
-
Start date:
03/22/2013
% Done:

100%

Version:
Platform:
Windows
Expansion:
Language:
English (US)
Mod Related:
No
Votes:
Arrow u r green
Arrow d r red

Description

Long explanation needed so bear with me;

Configuration; two separate PCs, two monitors, both connected to same LAN, both running Multiplicity by Stardock (http://www.stardock.com/products/multiplicity/) which allows main PC keyboard and mouse control a second PC which has only monitor attached to it. Think multi-monitor, except with two separate PCs running two separate monitors.

KSP running on the main PC. Second PC used for various tasks, VOIP - email - browsing etc.

If KSP is in fullscreen mode and I move the cursor over the edge of the screen (to control the 2nd PC), when I return back to main monitor and try controlling KSP, I can no longer turn the camera with the mouse. Game works otherwise, it just ignores right click/hold/move mouse.

If KSP is in windowed mode, same happens if I move the cursor straight from the monitor of the other PC to the window of KSP and click it.

However, if I carefully move the mouse right over the edge to the main PC desktop, click on the desktop first and only then move the cursor over to the KSP window, things work normally.

Once camera turning stops working, it won't work again unless KSP is restarted.

This is annoying as it pretty much restricts me to main PC only during KSP play or I end up having to repeatedly restart KSP. Windowed mode is semi-workaround but it is easy to fumble a bit and end up with mouselook not working. I would much rather run KSP in fullscreen.

Please look into correcting this or including a hotkey to reset the mouselook.

Hardware: Core i7-2600K, GeForce GTX TITAN, 8GB RAM main PC. Core i5-2500, GeForce GTX 560 Ti, 8GB RAM secondary PC. Both systems running Windows 7 Home Premium. KSP running only on the main PC.

History

#1 Updated by sr over 10 years ago

  • Status changed from New to Need More Info

From the sound of things, this is more a multiplicty issue than a KSP issue - as if it doesn't reinstate the mouse event handler properly on reentry to the first monitor. Did you file a report with stardock about this issue as well? How do other games respond to the mouse cursor being moved to the other machine?

#2 Updated by Jarnis over 10 years ago

95% of other games handle the mouse exit/entry just fine. There are a few RTS games that think the mouse is constantly at the right edge causing scrolling but that bit is understandable and whenever mouse returns, they still act normally.

99% of the remaining 5% can recover from any glitches by alt-tabbing the game to desktop and back (they seem to "reset" their mouse handling on alt-tab).

KSP being the 1% which requires complete exit and restart to recover from a buggered mouse. Alt tabbing doesn't do anything.

Again, if KSP window is not active, the issue doesn't happen. So my guess is that something in KSP code freaks out when Multiplicity moves the mouse to the other PC.

#3 Updated by Squelch over 9 years ago

This issue is more about interaction between programs.

A combination of some game or 3D renderers, especially x64 and non DX, and any form of software type kvm can have problems. The game is still responding, but mouse input is being masked/blocked, or the program does not expect the mouse to leave the screen boundary. Software kvm's work outside of the normal OS behaviour, so it is subjective whether they should be supported.

To mitigate the lost focus, clicking the desktop or alt-tabbing before leaving the screen puts KSP into a state ready to receive mouse input again. Tools like "Swap Screen" also help with lost focus from the mouse leaving the screen unexpectedly leaving other programs in an indeterminate state.

It is not unique to KSP, so I'm inclined to say it is outside the scope of this tracker.

#4 Updated by Ted over 9 years ago

  • Status changed from Need More Info to Closed
  • % Done changed from 0 to 100

I agree with Squelch. Unfortunately, there is a limit to what issues we can address here and some issues are just beyond our reach. Closing this one up. Thanks anyhow.

Also available in: Atom PDF