detecting/calculating mouse yaw movement?

[pitchatan]

Currently trying to find a way to properly calculate mouse yaw.
What i need is a function to see if the mouse is moving left or right and produce a -1 or 1 respons.

Tried using self.angles_y & self.v_angle_y but that didnt really work that well as it keeps looping from -180 - 180 ( i could be wrong about this >_< )

The aim is to replace the current wishvel in sv_user.qc:

Code: Select all

wishvel = v_forward * self.movement_x + v_right * self.movement_y;

To something where v_right gets multiplied by my yaw (example: -1 or 1) and a server cvar.

Anyone have any suggestions?

[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]

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).

Im guessing i should define oldv_forward as a vector, still can't get it to compile.
fteqc spits out oldv_forward is not a field no matter what i try.

Or perhaps it's something from fteqw defs?

[frag.machine]

just add this at the end of defs.qc:

Code: Select all

.vector oldv_forward;

[pitchatan]

just add this at the end of defs.qc:

Code: Select all

.vector oldv_forward;

Thanks, silly me.. compiler said everything that needed to be said. >_<

Now, i have tried and tinkered with

Code: Select all

dir = v_right*self.oldv_forward;
self.oldv_forward = v_forward;

But seemingly only returns -2 i am currently using it in the airborn part of sv_user.qc
any suggestions?

[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]

I seem to remember commented code somewhere to use the ents .v_angle for makevectors, not its .angles. I am guessing v_angle is a "view angle " ? Only relevent really to player entities? Or is that completely wrong?

If I compare the players .angles to .v_angles, the Y and Z component are the same, but the X component on the .angles seems to cut off at 30/-30 where the same X component on the v_angle seems to accurately range from 90 / -90. I guess because the player entities wont ever have a range past 90 either way, but onother entities, its possible ?

v_angle_y is the player's yaw angle, in degrees, relative to some fixed direction.

[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]

Is it safe to say that the "fixed" (static) direction in reference would be world.origin, or '0 0 0' ?

v_angle_y is the player's yaw angle, in degrees, relative to some fixed direction.

So if you take a v_angle on a non-client ent, it will be same as .angles? Or just a dead field?

v_angle is the raw angle from the client (well, float-ified).

[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.