Re: [Quake-C] sv_maxspeed

[<qu...@ca...>]

I remember making the haste rune due a player speed increase being a 
headache.
The old rune code only sped up weapon fire and speed.

I have this in player_run

// haste run faster - moved up here for morphs
	local float f, ms, v, k;
	k = 0;

	if (self.rune_flag & RUNE_FLG_HS) k = 1;
	if (self.rune_flag & TECH_TEIM) k = k + 1;

	if (k)
	{
		if (k > 1) k = 1.2;
		ms = cvar("sv_maxspeed");
		f =  ms * 1.6 * k; // at 320 max, this is 576, for both runes 691
		if (self.movetype == MOVETYPE_FLY) f = ms * 1.4;
		v = vlen(self.velocity);
		if (!self.movement_x && !self.movement_y)
		{
			if (v > ms)
				self.velocity = self.velocity * 0.95;// (ms / v); // cap it
		}
		else
		if (v < f)
		{
			if (self.movement_x > 20)
				self.velocity = self.velocity * (f / v);
			else
			{
				f = ms * 1.25 * k;
				if (self.movetype == MOVETYPE_FLY) f = ms * 0.9; // flight speed 
side & back normally .8 * ms
				if ( (fabs(self.movement_y) > 20) ||  (self.movement_x < 20) )
					self.velocity = self.velocity * (f / v);
			}
		}
	}

This code uses sv_maxspeed as a base.  I'm pretty sure it ignores 
cl_forwardspeed.
It creates the cap and then makes some tweaks.
Similar to yours, but with more math.

I dont remember all the details, but the tweaks are important.
This runs every 1/10 a sec in player frames.

It seems really cool.  But controling movement is hard.  Especially with 
both haste runes!
If there is any challenge in nav, with haste it sucks.

In singleplayer you could use slowmo and velocity mod to do Flash (dc 
comics char.) type stuff.
Or a matrix type bullet time.  That would be wicked.
Wont work in DM or coop though.


On 2016-04-01 13:44, Cobalt wrote:
> Trying to fix a bug in the old Runequake QC involving an athletic rune 
> which
> makes the player have a slightly faster velocity.
> 
> Apparently if you set your clients cl_forwardspeed way high you get 
> crazy
> speed with it. It uses this code:


It shouldnt.  At least it wont go past sv_maxspeed.
And if you bump that up, then any player could exceed the usual limit.
I'm not sure if dp fixes it or how, but in the old engines diagonal 
moves, wall hugging and bunny hopping
all violated sv_maxspeed by some amount.


> 
> if ((self.cl[CL_CMD_FORWARD] || self.cl[CL_CMD_SIDE]) && self.flags &
> FL_ONGROUND)
>   self.velocity = self.velocity + self.velocity * 0.10;
> 
>       As an fix, we took the code and  changed it to:
> 
>        if ((self.cl[CL_CMD_FORWARD] || self.cl[CL_CMD_SIDE]) && 
> self.flags &
> FL_ONGROUND)
>        if (vlen(self.velocity) < 440) // Cobalt fix attempt for bug
>       self.velocity = self.velocity + self.velocity * 0.10;
> 
> 
> Apparently its an improvement as your speed does not perpetually 
> accelerate,
> however theres a side effect where you can have some
> increased movement sideways and not always recover quickly when moving 
> in a
> straight line.
> 
> This case the engine is a port of the old Proquake engine, and its able 
> to
> hack into the client with thos cl_ commands I guess.


That does sound pretty hacky.  I had no idea proquake did such things.
Ideally, the server should always maintain ents, with client side stuff 
for HUD, fancy gfx, etc.


> sv_maxspeed is usually 320 by default, however Runequake has it set to 
> 350.
> We originally thought it was 400, so thats why we set the fix to be
> < 440, so I guess we can try < 385 to see if that helps, but was more
> curious if there was a better option than the velocity, other than 
> porting
> to Darkplaces and using
> sv_playerphysics...which is what we may wind up doing anyhow one day.
> 

Yep, these days using an old engine is tricky.