CLOK BBS

This is something that's bothered me for a long time. It appears that cooldowns and roundtime use different timekeeping mechanisms which leads to them never actually lining up correctly and makes it seem like cooldowns are one second longer than they claim.

The simplest example of this is with a rotation of a 15s cooldown, 5s RT skill followed by two 5s RT attacks. Naively, when the third 5s of RT is finished, it's been 5s+5s+5s=15s since the skill with a 15s cooldown was used, so it should be ready to go again, right? Nope! This is never actually the case. You'll always get a "You must wait 1 second" message. Why tho?

It's been pointed out that the game runs on a 1s update loop. You can observe this experimentally for the RT countdown: Record the timestamp with subsecond precision that the "Roundtime: N seconds." message arrives, and again when the "Roundtime finished" message arrives. The difference is always less than the stated roundtime - I've seen it as low as a millisecond between the start and end of a 1s roundtime. What's probably happening is we're getting a counter created which is decremented every tick, and when it hits 0, RT is finished.

But cooldowns don't seem to obey this system. If they did, I would expect the above example to succeed, potential ordering bugs in the execution of one-queued-command aside. But I'm not actually using that to trigger my next attack, so it can be ruled out. How I suspect it works is that the cooldown timer is based on Real Time, not the 1s update timer. Something like:

• On use, get current time
• If current time - last use > cooldown, success, store last use
• else, error, cooldown not yet done

And since the real time elapsed in RT is always less than real time, you don't actually get to use your cooldowns immediately when coming out of RT and instead have to wait up to a second longer. Seems like the simplest solution would be to drop the real cooldown by a second, e.g. 15s cooldowns are actually up at 14s, so that they're available when RT is finished. A more correct solution is probably to rope them into the 1s update loop so that if it's running faster or slower than real time for whatever reason, things don't skew weirdly, but I imagine that's a bit more of an invasive change.