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:
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).
Spike wrote: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.
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 .... ?
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.
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 ?
Spike wrote:v_angle_y is the player's yaw angle, in degrees, relative to some fixed direction.
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).
'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.