Sprinting

[ScatterBox]

[Spike]

better to use .maxspeed instead of hacking client speeds.
bind a "+moveleft;cl_sidespeed 5000"
superfast!
the maxspeed field blocks it serverside.
wait, or was that qw only? thought it got added in 1.09? am I misremembering? too lazy to look it up. bah

[gnounc]

[gnounc]

[ScatterBox]

[Cobalt]

Maybe you need to strzone the string.

[Spike]

when printing, add \n afterwards (second print?), or just use centerprint instead.
failure to do so will just weirdly bug out the prints.

secondly, your sprint_time value is presumably a global. this is stupid. if its a local then its even more broken.
this variable should be a field instead. self.sprint_time. this allows coop to work.
although, yes, if your game is strictly singleplayer then a global is fine - is your mod strictly single player? :s
either way, make sure its NOT a local! that might help explain how its always 0.

thirdly, counting frames is flawed. think functions are generally scheduled 10 times a second. that means your limit of 4 gives 0.4 (or so, it can actually vary a little) seconds of sprinting... which isn't much at all.
if instead your concept of frames is that of playerprethink/playerpostthink, then you're getting noticably more frames than that (72 or so, but can vary)! counting frames is just unreliable however you look at it.
the solution is to add/subtract frametime and work purely in actual time, rather than in frames.
yes, this means that you can somewhat easily over-spend. just make sure the player still has to pay (in downtime) and your half-frame overspend is unlikely to be a problem.

[Cobalt]

[ScatterBox]

[Cobalt]

Well on the first check, it would be = 1, so then it will see it = 1, and take one, so you get 0

[ScatterBox]

[r00k]

[Cobalt]

[r00k]

im not 100% sure but i think it is 1 at the end of a frame
otherwise 0 so its not updating too often
this is how the player is slowed down in the watermove code
so i just modified it for this use.

[Spike]

looks like it'll spasm if you drop below 10fps.