Setting sv_noclipaccelerate to 1 prevents movement in noclip

[zike1017]

Describe the bug Setting the noclip acceleration speed to a value of 1 (sv_noclipaccelerate 1) prevents the player from accelerating at all while in noclip. The minimum acceleration needed to move seems to be about 1.3.

To Reproduce

1. type sv_noclipaccelerate 1 into console
2. turn on noclip
3. attempt to move and fail

Expected behavior Setting sv_noclipaccelerate to 1 should still allow the player to accelerate in noclip. The expected value for 0 acceleration would be sv_noclipaccelerate 0.

Desktop/Branch (please complete the following information):

• OS: Windows
• Branch: Steam beta chaos build

[braem]

This should occur in every source game.

It happens because there is a "bleed" amount that slows you down in noclip, so you cannot move if the bleed amount is greater than the value you've accelerated to (spd): https://github.com/momentum-mod/game/blob/ce8c9060cb68ac765009b2bf883339eb59bbbd88/mp/src/game/shared/gamemovement.cpp#L2325-L2337

The "bleed threshold" here only accounts for speed though, not acceleration.. so yeah the drop amount can be too large when it shouldnt be. Adding in acceleration and adjusting Valve's magic FOUR for default accel works, while keeping that source feel.

float flBleedThreshold = ( maxspeed / 20.f ) * maxacceleration; // maxacceleration = sv_noclipaccelerate
float control = spd < flBleedThreshold ? flBleedThreshold : spd;

Though changing accelerate will also effect deceleration in this case, ehh.

Could also just replace the jank with a sv_noclipfriction like

float drop = sv_noclipfriction.GetFloat() * gpGlobals->frametime;

What say ye?

[hexaflexahexagon]

so in laymans terms this exists in all source games already, changing would just make it different from those. the ways we could change this are:

1. messing with valve code™ so that we can have sv_noclipaccelerate use values that make sense, though the downside is this changes noclip deceleration too which might feel weird
2. add a new command sv_noclipfriction to remove janky code, avoiding the above issue and balancing sv_noclipfriction so that it uses numbers that make sense, at the downside of adding yet another command.

. . . or something like that?

[braem]

so in laymans terms this exists in all source games already, changing would just make it different from those. the ways we could change this are:

1. messing with valve code™ so that we can have `sv_noclipaccelerate` use values that make sense, though the downside is this changes noclip deceleration too which might feel weird

2. add a new command `sv_noclipfriction` to remove janky code, avoiding the above issue and balancing `sv_noclipfriction` so that it uses numbers that make sense, at the downside of adding yet another command.

. . . or something like that?

Yup. Though with 1 and default values (5 noclipaccel 5 noclipspeed) it is identical. It's just that noclipaccel would also influence the friction/bleed/decel/w.e whereas before it would only be noclipspeed.