Changing mouse speed in ZScript

[Jekyll Grim Payne]

Is there a way to scale or change mouse speed temporarily? I need to create a melee weapon attack that limits the player's ability to turn around while it's performed but doesn't disable it completely.

[Enjay]

I wonder if investigating how [wiki]A_ZoomFactor[/wiki] does its thing? By default, it scales mouse sensitivity to reduce mouse movement speed when zoomed in.

[Jekyll Grim Payne]

I'm not sure any scaling is actually involved, but I couldn't find definition of A_ZoomFactor inside gzdoom.pk3 (and exporting Zscript folder from it won't help because, sadly, my OS is for some reason incapable of searching file contents...)

[ramon.dexter]

You need to enable searching inside file contents, I think it's not ON by default.

Anyways, A_ZoomFactor is defined in zscript/inventory/weapon.txt, here it is:

Code: Select all

action void A_ZoomFactor(double zoom = 1, int flags = 0)
	{
		let player = self.player;
		if (player != NULL && player.ReadyWeapon != NULL)
		{
			zoom = 1 / clamp(zoom, 0.1, 50.0);
			if (flags & 1)
			{ // Make the zoom instant.
				self.player.FOV = self.player.DesiredFOV * zoom;
			}
			if (flags & 2)
			{ // Disable pitch/yaw scaling.
				zoom = -zoom;
			}
			self.player.ReadyWeapon.FOVScale = zoom;
		}
	}

But looking at the code, there is no mouse movement scaling...

[Player701]

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:

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:

1. Player's mouse speed is tied to the player's ReadyWeapon.FOVScale. This means that altering it won't work without a weapon.
2. 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.

[Nash]

A_ZoomFactor's view sensitivity scaling is hardcoded in g_game.cpp, in functions G_AddViewAngle and G_AddViewPitch. Here are the relevant lines:

Code: Select all

look = int(look * players[consoleplayer].ReadyWeapon->FOVScale);
yaw = int(yaw * players[consoleplayer].ReadyWeapon->FOVScale);

You cannot hook in directly to these parts of the engine, but using the above information, you can extrapolate that all it's doing is multiplying the player's view and pitch with a multiplier (FOVScale in this case).

As for WHERE is the earliest point in the engine where you can intercept this via scripting... I don't have the answer. Maybe someone else knows.

[Caligari87]

I'm pretty sure it's in virtual void MovePlayer() for angle and virtual void CheckPitch() for pitch (relevant line numbers linked). No idea if overriding those messes with prediction/interpolation at all.

[phantombeta]

I'm pretty sure it's in virtual void MovePlayer() for angle and virtual void CheckPitch() for pitch (relevant line numbers linked). No idea if overriding those messes with prediction/interpolation at all.

Overriding those shouldn't mess with the MP player prediction, as it simply runs PlayerThink, I believe, which uses these.