BackStabbing (Fun with Dot Product)

[Spike]

sorry, should have been vel-=foo

downwards velocity, upwards surface.

vel -= vel * (((vel * normal) * scale) * normal);
'0 0 -1' -= (('0 0 -1' * '0 0 1') * 2) * '0 0 1'
'0 0 -1' -= ((-1) * 2) * '0 0 1'
'0 0 -1' -= (-2) * '0 0 1'
'0 0 -1' -= '0 0 -2'
'0 0 1'
velocity is now going back up again.

unfixable pitch bug is unfixable because too many qc mods depends upon the buggy behaviour, namely that makevectors(self.v_angle); MUST work as it does, and that tmp = vectoangles(v_forward); self.angles_x *= -1; makevectors(self.angles); must also work. or so. too many existing mods would break if that negation was no longer needed.

.gravitydir contains some normalized vector in a per-ent field. I took a liberty and had changeyaw update pitch+roll automatically as apropriate.

[Cobalt]

THEIF PL! WE HATES IT FOREVEREEERRRRRR

https://www.youtube.com/watch?v=Xj8r5ojAh9k

This sounds familiar somehow.. Hmmm. Part of your collaboration with Cobalt? I know he has added this to TBC as well.

[Hypersonic]

When you state
vel -= vel * (((vel * normal) * scale) * normal);
Do you actually mean
vel -= (((vel * normal) * scale) * normal);
According to your example solution that appears to be the case

Which built-in functions are buggy, just makevectors? Is vectoangles buggy as well?

[Spike]

technically vectoangles is the buggy one. but it'll do what you want anyway so why care.
Its only when you do advanced stuff that you really notice the bug, and most things can simply be negated, which is why id didn't spot it, and why its so easy to depend upon the bug, thus why it cannot be fixed reliably - because fixing it will actually break things.
its fixed in q2 if that helps.

[Hypersonic]

For both Quake 1&2: angle[0] is pitch, angle[1] is yaw, angle[2] is roll

//quake1
void PF_vectoangles (void)
{
	float	*value1;
	float	forward;
	float	yaw, pitch;

	value1 = G_VECTOR(OFS_PARM0);

	if (value1[1] == 0 && value1[0] == 0)
	{
		yaw = 0;
		if (value1[2] > 0)
			pitch = 90;
		else
			pitch = 270;
	}
	else
	{
		yaw = (int) (atan2(value1[1], value1[0]) * 180 / M_PI);
		if (yaw < 0)
			yaw += 360;

		forward = sqrt (value1[0]*value1[0] + value1[1]*value1[1]);
		pitch = (int) (atan2(value1[2], forward) * 180 / M_PI);
		if (pitch < 0)
			pitch += 360;
	}

	G_FLOAT(OFS_RETURN+0) = pitch;
	G_FLOAT(OFS_RETURN+1) = yaw;
	G_FLOAT(OFS_RETURN+2) = 0;
}

//quake2
void vectoangles (vec3_t value1, vec3_t angles)
{
	float	forward;
	float	yaw, pitch;
	
	if (value1[1] == 0 && value1[0] == 0)
	{
		yaw = 0;
		if (value1[2] > 0)
			pitch = 90;
		else
			pitch = 270;
	}
	else
	{
		yaw = (int) (atan2(value1[1], value1[0]) * 180 / M_PI);
		if (yaw < 0)
			yaw += 360;

		forward = sqrt (value1[0]*value1[0] + value1[1]*value1[1]);
		pitch = (int) (atan2(value1[2], forward) * 180 / M_PI);
		if (pitch < 0)
			pitch += 360;
	}

	angles[PITCH] = -pitch;
	angles[YAW] = yaw;
	angles[ROLL] = 0;
}

The core of the problem is that whoever wrote this function thought that pitch-up was positive, when in fact pitch-down is positive. Quake2 compensates with a negative sign at the end, Quake1 does not. Useless function for 6dof, roll output is always 0 no matter the input.

I already examined makevectors and it seems to be usable for 6dof with no errors.

[Spike]

the problem is that q1's vectoangles is _correct_. give it a vector and it'll give an angle to orient an mdl entity along that vector. which is precisely the problem. the angles it gives has a negated pitch relative to the makevectors builtin - because mdl entities pitch the wrong way. THAT is the bug. It is quite obscure, but too many things depend upon it, hence how its unfixable.

[Hypersonic]

Ya mods rely on how it works now, so don't change it of course. In Quake1 just multiply the resulting pitch by -1 (angle_x = angle_x*-1) or (angle[0] = angle[0]*-1)

A vectoangles for 6dof would need 2 vector parameters to calculate roll, roll doesn't make any sense with just one vector. Perhaps a vectoangles6dof could be added. Can QC functions be polymorphic? If just one vector parameter is present it would do the same as vectoangles and assume it is the forward vector only, but yield a properly signed pitch. If 2 vector parameters are present it would then also yield a non-zero roll value(well, unless roll really is zero.) Perhaps have the 2nd vector be the up vector (doesn't matter if the other parameter is the up or right vector, but just one would have to be decided upon.)

[Dutch]

I noticed this bug before while trying to orient a sprite model. The pitch was always opposite.