Startzones, "Lags", and Moving Forward

[Beetle179]

Lately there's been a lot of talk about "lagged" wrcp/wrb startzones. I'd like to provide some information about identifying these records and incite some discussion about how KSF should handle/treat these cases.

To start with some basics:
-The KSF servers run at 66 tickrate.
-This means the server processes information about each player (notably position and velocity) 66 times a second.
-This corresponds to an update 66 times a second, or once every ~0.015 seconds.
-This means there is a discrete, integer number of ticks to everything the server reports -- PRs, WRs, and times could all be expressed as a non-decimal number of ticks, meaning perfect ties are possible (two records could both be exactly 352 ticks long, for example). (random note: 352 ticks would be about 5.33 seconds.)

Sidenote about server resolution and interpolation:
-Ideally, all reported times would exactly fall in line with the tickrate and be spaced apart by exactly 1/66 (0.01515…) or some multiple thereof.
-However, based on some coding backend we aren’t familiar with (believed to be the server clock), the server “fakes” a resolution more accurate than 1/66 tick. We know that any time which does not fall in line with the scale of the tickrate is effectively completely random, pure guesswork by the server.
-The implications of this are that times reported as +0.00 over each other, or reported as, say, 3.711 seconds vs 3.712 seconds, are actually perfect ties as far as number of ticks goes -- the maximum accuracy the server can report -- but randomly ended up not being the same due to some flaws in the timer.
-The Momentum mod handles this very well and has proper interpolation for startzones and endzones. See their Tumblr post here for an explanation -- note that the KSF timer does not do this, but it would be an excellent addition (although a lot to ask for at this point)

Now, startzones. Startzones are literally just big triggers that you stand within, and when your player hull (thanks jux) completely exits the startzone, your timer begins -- the server recognizes the transition of your player status from “in startzone” to “in zone”, and updates your timer to start running on the same tick this happens. (possibly the next tick? Not important for our purposes anyway). Sometimes, for unknown reasons, the timer does not actually update your player status when it should -- it gets delayed by one tick (or more, but that’s rare). Meaning, the server believes you’re in the startzone for one tick longer than you actually were, and your timer gets started one tick later than it should have been. This is what we call “startzone lag”, or what I’ll be calling a “false start” from now on -- since we really don’t know if lag/latency has anything to do with it.

The issue then is detecting what is and isn’t a false start. I go over this in-depth in my video on startzones, which I’ll post here as soon as it’s released. But the gist of it is, we know the maximum speeds possible for one to obtain as they leave most startzones (more on that in a minute), and if their speed exceeds this maximum speed, then we can deduce that they experienced a false start -- the excess speed comes from speed gained from airstrafing and gravity (mostly gravity -- 12 units per second per tick) on the tick that the timer erroneously dropped.

A “standard startzone” looks like this: (linked because massive pictures)

Without showtriggers_toggle:
http://i.imgur.com/Prnw0Qo.jpg

With showtriggers_toggle:
http://i.imgur.com/zXC0h98.jpg

The yellow trigger shows the startzone. Notice how the startzone lines up perfectly with the ground -- this is very important!

Now we need to talk about the command !togglevel. What this does is tells you your speed every time you interact with a trigger -- including when you exit a startzone, which is what we’re interested. More than that, it will tell you your speed as it is broken up into its horizontal (xy plane) and vertical (z axis) components. From lots of testing, we’ve found that the maximum possible speed the timer will allow you to get in the xy direction is 350 units/second -- anything greater and it seems to somehow reduce your speed back to this threshold. Additionally, on a standard startzone, the maximum possible speed one can obtain in the z direction is 316 units/second downwards (or 322 with a crouchjump). This is the maximum speed you can legitimately reach given that you must pass over the ground without bumping it, and assuming that you hold crouch as you exit the zone (to cut the ground tighter).

One last thing to keep in mind is that although !togglevel shows only the xy and z components of your speed, the timer HUD already reports your overall (xyz, or combined xy and z speeds) speed each time you exit a startzone.

So we know the maximum velocities you can reach out of a standard startzone are 350 in the xy plane and -316/-322 (no-cj/cj) along the z axis (negative because you’re traveling downwards). Because the xy plane and the z axis are perpendicular, we can use the Pythagorean theorem to calculate the xyz/overall maximum speed one can obtain out of a startzone using these values.

sqrt[ (350)^2 + (-322)^2 ] ~= 475.588 units/s with a crouchjump, or
sqrt[ (350)^2 + (-316)^2 ] ~= 471.546 units/s without a crouchjump.

From some testing with !makezone, !togglevel, !speed, and cl_showpos 1, we can prove that the timer reports a speed which is rounded down. This makes the maximum possible startzone speeds 475 u/s and 471 u/s for crouchjumping and no-crouchjumping, respectively. Thus, any records which exceed these values on a standard startzone, we can be sure are false starts and their reported times are at least one tick faster than what they should have been.

The question then is, why does any of this matter? It’s just one tick, it’s just a few extra units out of the startzone, it’s not a big deal, right?



This is why it matters. There are many stages like this where one tick can make or break a WRCP. There are many, many stages and bonuses (and even maps) where the top 2 times are separated by 1 tick, or tied. If the record is a false start, then rank 2 is being cheated out of a record that belongs to them.

“But if it’s just one tick/a tie, just rebeat it anyway” -- this is a ridiculous argument for two reasons. One, no one should have any obligation to have to grind for something they shouldn’t have lost in the first place. Two, in many cases, these false starts happen on very optimal stages -- not necessarily SHORT stages, but stages where there is very, very, very little (if ANY) time left to shave off.

“But if they beat the record by one tick, and they got a tick advantage because of a false start, then they would still have tied the record without the false start -- so why remove it?” Again, two reasons here. One, because everyone else who ties the true time has to play the KSF-timer lottery (see the sidenote earlier about server resolution), but the “lagger” skips this and just takes the record without having to worry about it. Two, any potential competitors for the record may tie the true record, but will never know if they would’ve beaten the record, because the “lagger” holds that tick buffer over everyone else.

“But they beat the record by 0.05 seconds (3-4 ticks) anyway, so even if they hadn’t gotten a false start, they’d still hold the record”. CORRECT, and this is a much more difficult matter. In my opinion, I believe these records should be kept until someone sets a rank2 time of +0.015 (+1 tick), and THEN removed -- but not until someone does set that true-time tie.

Hopefully this all makes sense, because now I’d like to talk about what to do about false starts. One solution is to simply add exactly 1 tick -- 0.015151515… seconds -- to a regular old 1-tick false start. This is good because it eliminates the advantage the “lagger” had and puts them in the lottery with anyone else who tied the true time. However, it does not solve the problem of a misleading !prinfo if that person still holds the record after the appropriate time is readded to their time. (note: if this were to happen, it’s very important that 0.0151515… be added to the player’s time, and NOT just 0.015, or else they actually get an advantage in the lottery.)

Another solution is to simply nuke the time. This is good because it removes any misleading !prinfo, and there’s no difference between rank 2 and rank 100 on a stage -- so they aren’t losing out on anything. However, the downside here is that they lose their chance to play in the lottery. This is my personal preferred solution.

The last question is who would enforce these things. Sacred is the only particularly active high-admin on KSF, with untouch and evolv largely unavailable. However, we know Sacred is a busy person himself, with mapping responsibilities and a life to attend to. The answer to this is, I don’t know. If KSF is willing to appoint another admin with the power to change times, someone who is willing to educate themselves and not approach situations with bias, I personally believe that would be the ideal route. But that’s not up to me, so I’d like to hear from some of the higher-ups. This is not an issue that should be ignored, lest the precedent be set that “cheated” times be acceptable.



I really hope this clears things up. Every claim I’ve made has been tested pretty thoroughly, but if I’ve made any mistakes, I’m more than willing to hear them -- I do ask for proof of course. There’s no tl;dr -- if you want to contribute to this conversation, I ask you to read the entire post to educate yourself. Thanks.

[Mooster Cow]

.

[FluX]

Extremely informative and helpful thread, nice work!

[Crayz]

If trigger collision events can be processed late would it make more sense to not use triggers at all, and instead iterate through all player's center origin each tick to determine what zones they are/aren't touching?

[Habitat]

teach me how to add times and ill do it

[Rickzter]

When we tested it earlier u could get more than 350 XY and a 334 edge (Z) if u did it perfect. I admit a 334 didnt happend all the time but when you got it you could feel that u did a really good prestrafe, exiting the zone in a perfect 90° angle. People saw me get it 3 times in a row some times. (think it was skandy and morning) when i really tried for the perfect prestrafe. If its assumed to be a "false start" then it just happends WAY too often. Alot of ppl who specced me during testing will confirm.
The "best" i got was 352.xx/334

[Stevo_97]

Really interesting to learn about the parts of the timer that don't usually have much light shed on them. As for who should make such changes and approach situations without bias I honestly think you, as the person who made this thread in the first place, should be the person appointed to the job. The only other person I can think of who might step up to the task is Crash Fort. Anyway, good job.

[nemix]

Brilliant post beetle

[Sacred]

See, was a good idea to post here. It's not that I don't have the time, if this would be handled via reports as usual and you just leave the according message then it wouldn't be a problem for me at all. I personally think that the "lagged" time should be added, and not entirely removed.

When we tested it earlier u could get more than 350 XY and a 334 edge (Z) if u did it perfect. I admit a 334 didnt happend all the time but when you got it you could feel that u did a really good prestrafe, exiting the zone in a perfect 90° angle. People saw me get it 3 times in a row some times. (think it was skandy and morning) when i really tried for the perfect prestrafe. If its assumed to be a "false start" then it just happends WAY too often. Alot of ppl who specced me during testing will confirm.
The "best" i got was 352.xx/334

This is really important. We need to know exactly what the numbers are, and be confident that those are correct. And as I said to you in steam, beetle, we still kind of assume that the zone is set perfectly and not 1 unit off.

[Frag1337]

Really interesting to see those values, keep up & good job