detecting/calculating mouse yaw movement?

[pitchatan]

[Spike]

try these two lines:
dir = v_right*self.oldv_forward;
self.oldv_forward = v_forward;

a result = 1 means they turned left (the right direction now faces towards where we were looking last frame). a result of -1 means they turned right (right now faces behind where they were). 0 means no change. dir===sin(theta).

[pitchatan]

[frag.machine]

[pitchatan]

[Cobalt]

Shouldnt it be self.v_angle or self.angles , not v_forward? I thought v_forward supplies the current direction the ent is moving, based on makevectors .... ?

[Spike]

v_angle_y is the player's yaw angle, in degrees, relative to some fixed direction.
v_forward / v_right are the actual direction you're currently facing, as determined from makevectors when given the player's v_angle field.

in QC, normalize(direction1) * normalize(direction2) == cos(theta), where theta is the angle (in radians) between the two direction vectors, in this case v_right and the v_forward from the previous frame, both of which are already normalized..
this means the result is 1 when the directions are the same, -1 when they're facing away, and 0 when they're purpendicular (read: a right angle)).
while you could subtract the delta of the player's yaw, rescale to radians and use sin to get a similar result, this would not work in weird cases like where the player is facing upside down (hey, it happens sometimes!)

angle deltas are awkward due to their cyclic nature. if you just want to determine the difference of an angle from one frame to the next, do something like:
diff = anglemod(new - old);
if (diff > 180)
diff -= 360;
if (diff < -180)
diff += 360;
and you'll end up with a +/- 180 range, which can be useful for interpolating in a non-linear-eular way.

directly using angles in physics code is generally a bad idea.

[Cobalt]

[Spike]

v_angle is the raw angle from the client (well, float-ified).
angles is a product of player movement code. its pitch angle is adjusted to be 1/3rd (so a player looking up is not on his back) and the pitch is inverted to try to hide a bug from the vanilla days (vectoangles+alias models pitch the wrong way).

[ceriux]

im pretty sure "v_forward" means the player is stepping forward. not the view. like velocity forward.

self.vangles i think is the right thing.

actually in defs iv only found these :

vector(vector v) vectoangles = #51;

vector angles;

found this in client.qc :

other.angles = other.v_angle = pos.mangle;
other.fixangle = TRUE; // turn this way immediately

self.origin = spot.origin + '0 0 1';
self.angles = spot.angles;
self.fixangle = TRUE;

if (deathmatch || coop)
{
makevectors(self.angles);
spawn_tfog (self.origin + v_forward*20);
}



the different colors are all taken from different spots (just search "angle")

i dont know if any of that is useful.

however looking at some things there if you're trying to get the player to look a specific way (or camera) self.fixangle might be required.

[Cobalt]

[Spike]

'0 0 0' isn't a direction, its a location.
by fixed location, I mean x=1

v_angle is unused on non-player fields. its the angle received from the client, like .movement is the forward/right/up speeds the player wishes to move at.

v_forward, v_right, v_up are 3 vectors, combining to form a 3*3 orientation matrix which you can use to rotate stuff by the angles of the player.
here's some fun maths
makevectors(self.v_angle);
relative = other.origin - self.origin;
dirs_x = v_forward*relative;
dirs_y = v_right*relative;
dirs_z = v_up*relative;
'dirs' is now the 'relative' vector but rotated into a frame of reference relative to the player's angles. all distance stuff will have been preserved. It says how far forward, how far right, and how far up the target is according to the orientation given.
and then we can mess around with the player a bit
self.v_angle_y += 180;
makevectors(self.v_angle);
targ = v_forward * dirs_x + v_right * dirs_y + v_up * dirs_z;
and 'targ' is now pointing out and away from the player, but rotated by 180 degrees around the z axis (yay yaw). if dirs_z was 0, then its exactly opposite the original 'relative' direction (the matrix was rotated, not inverted, hence why only if z=0).

so, ceriux, when you seem to dismiss v_forward as being merely 'like velocity forward', you are oh so wrong. it is much more useful than merely that.