Okay, input methods and their balance. Wall of text approaching....
There have already been changes in at least one input device from retail to improve it. Namely, the joystick sensitivity settings have been changed to a more sensitive curve, which means that you actually can now use settings other than full sensitivity (although I still consider that the best if you have a stick with small enough deadzone). If we wanted to stay completely pure about how Volition balanced the input methods, this shouldn't have been allowed to happen.
Now, I realize that this issues isn't quite perfectly analogous - the sensitivity curve formula used to be absolutely horrible on any other settings than full sensitivity since it lowered the sensitivity around deadzone way too much and then had a sharp spike to the maximum input which actually made the joystick very, very impossible to use to any great effect - but it was still an improvement to one of the input methods from the retail. What it didn't do was give the joystick abilities it didn't use to have. The full sensitivity setting is still the most effective way of using the joystick, but the sensitivity settings change hopefully made it easier for people to start using it in the first place.
Then some technical stuff.
Currently, what the mouse input does is it reads the speed of the mouse, and translates that into the angular velocity at which the ship turns. It doesn't mean you can move your mouse to a certain position on table and the ship will move to pointing at certain spot, then move mouse back to original spot that it used to point at.
What this means is that there's a maximum speed at which you should move your mouse to maximize the effectiveness of your turns. If you move the mouse faster than the ship can turn, the only thing that happens is that you lose table space while the ship will feel like it turns very sluggishly (compared to your frantic mouse waving).
Mathematically speaking,
Input x = dx/dt * sensitivity | speed of mouse on x axis, multiplied by mouse sensitivity setting
Input y = dy/dt * sensitivity | speed of mouse on y axis, multiplied by mouse sensitivity setting
Don't know the exact code that defines the mouse control handling, but this is more of an idealized formulation of how it (supposedly) works.
What the proposed change would do is to assume a center position for the mouse, and poll deflection from that point of origin and directly (or as a function of that deflection) translate it into input strengt:
Input x = dx * sensitivity | location of mouse on x axis, multiplied by mouse sensitivity setting
Input y = dy * sensitivity | location of mouse on y axis, multiplied by mouse sensitivity setting
This effectively turns your table into an XY plane where the mouse moves in, defining the strength of X and Y control inputs.
The biggest difference here is that the latter scheme is actually less intuitive than the former. We have been indoctrinated to assume that when we do not move the mouse, the cursor does not move. Similarly, we assume that when we don't move the mouse, the target reticle will stop moving (ship will stop turning) and in current control scheme it does exactly that - you are required to move mouse to keep the target reticle (cursor) moving. But, instead of being able to move the cursor around at whichever speed you please, you are limited by ship's performance, which is independent of any control method you choose.
So, the big advantage of velocity polling mouse interface is that it is intuitive and accurate, which are both direct result of the fact that the movement stops when mouse stops.
This advantage is lost when the interface is changed to position-polling system, but it gains some of the advantages and all the negative aspects of a joystick. The advantage being that you now have analog control over two of the control axes while not losing table space with every movement, and you don't need to move the mouse over the desk to keep on turning.
And that's about it. It doesn't give you an analog Z axis as twist handle joysticks do. It does not give you a feel for what input you are giving to the game, because unlike joystick, the mouse's movements are only limited by the size of your desk space rather than the gimbal angles of a joystick, and this also means you do not gain a clearly palpable center zone, which would likely make aiming even harder than with a joystick. The mouse also does not automatically re-center, although to gain even marginal useability a centering function would likely be required (similar to the mouse script I remember having). Of course, that can also be seen as an advantage because centering springs in many sticks often cause mechanical discontinuities in the friction on moving the joystick, which on Queen's English means that the joystick's movement can become jerky over deadzone when the direction of resistance doesn't smoothly go to zero and start increasing, but instead has sharp "spikes" on it (this is a classic symptom of Saitek's centering mechanism, and one of the reasons I have removed all centering springs from my sticks).
The point of this rambling is that I don't see the "moustick" as an automatic game-breaker superior input mechanism, even combined with the current mouse control.
As such, I have no objections to it being coded in if some valiant coder samurai sees it fit to put in, but I also recognize the argument that switching between different mouse modes in-flight with a hotkey could be a recipe for disaster, and hence propose that either the change option is disabled during missions, similarly to difficulty options which would mean players would have to choose their method of input and stick with it for the mission. The idea of having it as a toggleable option in config screen is also valid as it too would prevent switching between modes during a dogfight.
Or instead of making it globally supported automatically, it could be a FRED flag for mission files, as in " moustic " (allows mouse joystick behaviour)...
Poll
