Note the following part of the code:
Code: Select all
if (flags & 2)
{ // Disable pitch/yaw scaling.
zoom = -zoom;
}
This logic handles the ZOOM_NOSCALETURNING flag. From the wiki:
ZDoom Wiki wrote:ZOOM_NOSCALETURNING: Player turning is normally scaled as well by this function. Use this flag to retain the player's unzoomed sensitivity while zoomed.
So, this flag (0x2) is handled in A_ZoomFactor by setting the zoom to a negative value, which is in turn passed to ReadyWeapon.FOVScale. So it appears that FOVScale is not only responsible for gradual zooming but also for mouse sensitivity.
Let's see how FOVScale actually works. It is handled in PlayerPawn.CheckFOV (
gzdoom.pk3/zscript/shared/player.txt). The FOVScale value is used to smoothly alter the player's FOV, but before it is used, the value is turned absolute. There is the following comment about it:
Code: Select all
// A negative scale is used to prevent G_AddViewAngle/G_AddViewPitch
// from scaling with the FOV scale.
desired *= abs(player.ReadyWeapon.FOVScale);
Aha! So that's what we should be looking for. G_AddViewPitch and G_AddViewAngle are in
g_game.cpp, and they indeed use the player's ReadyWeapon.FOVScale value to adjust the speed if FOVScale is negative. Unfortunately, this logic is hard-coded and altering the current behavior doesn't seem to be possible without changing the source code.
Conclusions:
- Player's mouse speed is tied to the player's ReadyWeapon.FOVScale. This means that altering it won't work without a weapon.
- To change the player's mouse speed you have to: A) give the player a weapon, B) set its FOVScale, C) override CheckFOV in your player class so that the player's FOV does not change.
This is a kind of a hack, since you need a weapon to achieve the desired effect, but logically, a weapon shouldn't be required for this. It might be a good idea for a PR to add fields to PlayerPawn / PlayerInfo that can be used to adjust the player's horizontal and vertical mouse speed instead.
EDIT: Or, even better, add a virtual function to Inventory to get the scaling factors so that they can be combined. This is also better than changing values directly on the player actor. The problem is, the developers appear to have a strong opinion against any kind of "interface screw", so I'm not sure if they will approve this. Inverting the player movement to simulate a drunk player would be fun, though.