Not going to merge this yet since I haven't fully gone through it.

I'm not 100% sure if ProcessMovement will be the right way to go since it still seems vulnerable to time altering. Players with a frame rate low enough will move at the same real-time velocity as other players, but due to process movement not being called enough the actual advantage of that might not be as useful as I might think. I'm worried that if a player can willfully boost their time by reducing their frame rate that a cheater would be able to do the same without the disadvantages that would come with dropping frames.

One possible scenario where this would occur is on maps with a greater than 64/tickrate second drop allowing the player to toggle an fps bind and gain a .1 second difference in an identical route. While players are currently able to reduce times through cheats in the current system, one is abuse through means not normally accessible to the player, while the other can be changed via various methods.

Another thing is the way that time is incremented should be changed to match this system. While probably not significant, instead of incrementing the time by the time it took the server to process the last frame or the servers tick interval. It should be incremented by the players'/styles' timescale, then at the end multiplied by the tick interval of the server. This will greatly reduce the players' time from drifting too far from their actual time as their run continues. Assuming that they are running at a normal timescale.

The code below shows how bad the current system of incrementing is on the timer. variables are only incremented and assigned via Call_StartFunction to ensure that the compiler can't make any runtime optimizations for us. For a ten minute run at 100 tick the timer will add an extra .274 seconds to the players run. As a note, this is less of an issue on csgo servers that run on 2 to the power of n for the most part. It is also the most likely reason why rumour's time dropped significantly from the baseline.

public void OnPluginStart()
{
	float intervalTime = 0.0;
	float tickedTime = 0.0;
	for (int i = 0; i < 100 * 60 * 10; i++)
	{
		Call_StartFunction(INVALID_HANDLE, GetFunctionByName(GetMyHandle(), "GetTickIntervalEx"));
		float tickInterval;
		Call_Finish(tickInterval);
		Call_StartFunction(INVALID_HANDLE, GetFunctionByName(GetMyHandle(), "GetOne"));
		float one;
		Call_Finish(one)
		intervalTime += tickInterval;
		tickedTime += one;
	}
	Call_StartFunction(INVALID_HANDLE, GetFunctionByName(GetMyHandle(), "GetTickIntervalEx"));
	float tickInterval;
	Call_Finish(tickInterval);
	tickedTime *= tickInterval;

	PrintToConsoleAll("%.9f, %.9f", intervalTime, tickedTime);
}

public float GetTickIntervalEx()
{
	float interval = 1.0/100.0;
	return interval;
}

public float GetOne()
{
	float one = 1.0;
	return one;
}

600.274414062, 600.000000000
600.274414062, 600.000000000
600.274414062, 600.000000000
600.274414062, 600.000000000

After looking into the exploit more, it seems it was caused by some bad code of mine. I was unable to alter my times with the pull request by changing my framerate to the upper and lower bounds of the engine.

The timing issue on 100 tick servers will be addressed at a later date. Thanks @hermansimensen for making this pull request.