Search Unity

Input.GetAxis("Mouse X") and Y-axis equivalent don't work in Remote Desktop

Discussion in 'Editor & General Support' started by GCarty, Dec 14, 2011.

  1. GCarty

    GCarty

    Joined:
    Oct 20, 2011
    Posts:
    1
    I am currently using these functions to move and rotate an object, but they don't work for some reason over a Remote Desktop connection (they always return zero) -- any ideas?
     
  2. CSharpCoder

    CSharpCoder

    Joined:
    Feb 12, 2013
    Posts:
    1
    Is there a resolution or workaround to this issue? I'm seeing the same problem in Unity 4.0.
     
  3. jwesolo

    jwesolo

    Joined:
    Nov 23, 2012
    Posts:
    1
    I'm also experiencing this...mouse works fine in scene view but not in game view. This is a big deal for me as I do much of my work remotely. I'd love to know if anyone has found a solution.
     
  4. Arcanor

    Arcanor

    Joined:
    Nov 4, 2009
    Posts:
    264
  5. MasterLu

    MasterLu

    Joined:
    Nov 23, 2012
    Posts:
    2
    I had the same problem. This workaround works for me.

    Vector3 axis = new Vector3(-(lastAxis.x - Input.mousePosition.x) * 0.1f, -(lastAxis.y - Input.mousePosition.y) * 0.1f, Input.GetAxis("Mouse ScrollWheel"));
    Vector2 lastAxis = new Vector2(Input.mousePosition.x, Input.mousePosition.y);
     
  6. Annihlator

    Annihlator

    Joined:
    Oct 15, 2012
    Posts:
    378
    Thanks for posting the workaround!
    To get a little more into the problem though;
    (I'm assuming we're talking about windows' standard RDP platform)
    When connecting through windows remote desktop most functions are virtualized.
    This makes multiple problems arise where applications normally rely on their hardware counterparts.

    Some of the examples in these limitations are the limitation in use of graphics acceleration, but also other hardware devices aren't accessed/translated directly.

    Normally unity will request Unity's pointer location based on hardware information while the RDP fuels the mouse using this function; http://msdn.microsoft.com/en-us/library/windows/apps/hh994980.aspx while in the virtual environment the link to the hardware that unity's so desperately looking for likely doesn't excist since actually the mouse is remapped from relative movement to resulting location. (Basically unity is at this moment looking for the wrong type of values)

    To illustrate a little different;
    Like as if using a touchscreen, if i tap the screen in a different location the mouse pointer is moved, but unity shouldn't respond. (Because it is simply set to a new location)
    A normal mouse movement would instruct windows to "move that much and that much in that direction" instead of "be here"

    using the workaround MasterLu suggested uses the on-screen-location of the mouse rather then the relative hardware position adjustment for it's input, thus working around it.

    Want to simulate this behaviour? We can use AutoIt.
    Try make a script that places the mouse from one location to the next, and one that MOVES the mouse from one location to the next.
    Unity then should behave like i just described.
     
  7. Gary Li

    Gary Li

    Joined:
    May 20, 2013
    Posts:
    1
    thanks for posting this! could you please also talk more about how to implement this in your script? Thanks in advance