Mouse Movement Problems in Star Citizen (and Other Games)

[andb52]

Gary,

As you undoubtedly know, VoiceAttack is quite popular with those of us who play Star Citizen (and thank you so much for creating such a wonderful program!). I don’t know if you have played the game, but there is a constant issue that—as far as I know—has not been overcome. In short, a VoiceAttack command that directs mouse movements does not work when actually flying a ship. If VoiceAttack mouse movements worked in Star Citizen, for example, a VoiceAttack command could allow the ship to make a 180 degree turn.

I just did a quick test of VoiceAttack in Battlefield 4 and Planetside 2, and the behavior is the same, as it will not turn your character. Thus, while this is specifically a post about Star Citizen, it has broader implications.

Here are some more specifics about how VoiceAttack’s mouse commands interact with Star Citizen. VoiceAttack can move the mouse in the menus. When flying, it is possible to make the mouse pointer visible by either holding down tab or pressing home. When the pointer is visible, VoiceAttack can move the mouse—but when the mouse is visible, it does not move the ship. VoiceAttack can also click the mouse, whether visible or not; as expected, this causes the ship to fire a weapon.

The problem is only when in actual flight mode (or, for that matter, when in first person mode in the hanger, which is essentially the same as any other first person shooter). When flying, moving the mouse steers the ship. When in normal flight mode, VoiceAttack appears to do nothing when a mouse movement command is given. I have determined that it does do something, however. When holding tab to make the pointer visible, its last position is saved when tab is released. Thus, if I move the pointer to a point on the right side of the screen and then release tab, it will be in the same position on the right if I press tab again. The really interesting thing is that, if a VoiceAttack mouse movement command is given while flying, the pointer is where VoiceAttack tells it to be the next time tab is pressed. So, for example, if I leave the cursor on the right side of the screen, release tab, start flying, and give a VoiceAttack command to move the mouse pointer to the top left of the screen, the next time I press tab the pointer will be at the top left of the screen. However, nothing appears to happen when the VoiceAttack command is given. It is as if all VoiceAttack mouse movement commands given while flying happen in the background, on a “sub” level accessible to the player only when tab is pressed.

If there are two “levels’ of mouse movement in the game, VoiceAttack is only interacting with one of them when moving the mouse. With respect to mouse clicks, VoiceAttack operates as expected. Giving a command to move the mouse pointer to a specific location and click only moves the mouse on this “sub” level, but the click occurs on the player’s level. (I tested this by giving a command that, in tab mode, would cause a weapon to be disabled; while the mouse moved to the correct spot, the click happened in the normal course of the game—weapons fired).

I have tested this by trying the commands to move the mouse to a “set position” and to move it based on a set number of pixels; the result is the same.

I can hazard only one hypothesis for why this occurs. When VoiceAttack moves the mouse to a specific location (and when moving a set number of pixels, that is essentially what it is doing), the computer sees the cursor disappear and then reappear in the new location. If a human were to move the mouse to a new location, however, it would have to be dragged over the intervening pixels—and it is this dragging that causes a ship to move in Star Citizen. If VoiceAttack is in fact not dragging the cursor, that would explain the issue, and, of course, beg the question of whether it can be changed to operate in a different manner.

The problem with this hypothesis, however, is that VoiceAttack’s behavior when in Windows suggests that it does drag the cursor. The simplest test is to fire up Microsoft Paint and hold down a drawing tool while issue a VoiceAttack command to move the mouse—a line is drawn between the old and new point. Windows therefore sees the cursor dragged across the screen.  

There is only one other potentially relevant piece of information to share: a command to, for example, zoom in in Star Citizen requires the scroll wheel to be scrolled ten “clicks.” Setting the “scroll wheel forward” option to 10 does not work; Star Citizen only registered one “click,” requiring instead that the one “click” be repeated ten times. This is not a problem—I simply note it because it’s another quirk involving the interaction between VoiceAttack’s mouse commands and Star Citizen that may or may not be relevant.

I apologize for the length of the post, but I thought it might be useful to provide you as much data as possible. If it’s simply a case of some strange interaction with Star Citizen/video games generally that is outside your ability to control, then it’s certainly no problem; I just want to make you aware of the issue and get your thoughts on the matter.

 Thanks again for a great program!

[Gary]

Just going to throw this out there, since I need to do similar stuff when woriking with WoW and moving using the mouse...  have you tried putting various pauses between actions?  Like move to position, pause (usually .01 seconds works), click down, pause, move, pause, release?  WoW uses a polling mechanism when checking mouse position.  So, if I want to move the mouse to my character on after login, I have to move the mouse, pause briefly, double click, pause briefly, recall mouse position.

Gary

<w:LsdException Locked="false" Prio

...

[andb52]

That's not an issue here, as Star Citizen acts like it's not receiving any mouse movement inputs from VoiceAttack when the cursor is not already visible (e.g. in tab mode).