Hacker News Reader

Comment by Thaxll | Hacker News Reader

"Sub-tick updates are the heart of Counter-Strike 2. Previously, the server only evaluated the world in discrete time intervals (called ticks). Thanks to Counter-Strike 2’s sub-tick update architecture, servers know the exact instant that motion starts, a shot is fired, or a ‘nade is thrown."

Not sure what it means but it's probably related to the rollback tech in the source 1 engine, which is pretty outdated.

View on HN

Rollback is really the best lag compensation tech we have, trusting a client to a very small degree to tell their state of the world (or rather a delta to current) is much better than most other contemporaries. Call of Duty still divides your RTT by half at the start of a match and rewinds by that much. On connections with asyncronous latency this can be extremely impactful.

I’m not sure your information wrt Call Of Duty is correct.

To my knowledge, the client timestamps their inputs and sends them to the server; the server will then rewind the state of the world to the time of the input before applying it. RTT isn’t an input. Each snapshot from the server includes the server world timestamp of that snapshot; the client will gently lerp its clock to match this per frame.

Source - I’m a COD engine developer the last ~15 years or so.

Oh, I remember you from T5 debug messages. You are most certainly more knowledgable about this topic than me.

My info might be outdated, but I've noticed that on asyncronous routes, there seems to be a large bias that's based on on assuming upstream latency == downstream latency. It might just be the clock not getting adjusted (even most NTP imlementations make this assumption), but it also has been since ~T7 that I even checked. Conditioning the network to add ~40ms to downstream latency could actually reproduce this behavior.

People don't really realize how hard of a problem sub-10ms clock sync can be on cursed networks.

It means they're increasing the granularity of the timeline of events in order to improve accuracy and fairness.

Yeah, I'm interpreting this as instead of sending an integer of the tick that something occured on, they're sending a floating number of when it happened.

I assume the float they send will have a limit in accuracy however. So really it's not like ticks are 'gone', they're just getting much much smaller.

The ticks aren't going away. They're just sending exact timestamps for movement so the server side view of a hitbox is more accurate when rewinding hixboes. The difference on 60 tick was sometimes large enough to miss headshots on faraway targets. It'd of course help if their clock sync and anti-drift measures were better now. It's NTP hard mode.

Is there a reason you would expect them to use floats here instead of fixed-point? I would naively guess the latter.

They just meant that things now happen within fractions of a time slice, instead of always landing on exactly 1/60th of a second boundaries.

I would assume it works something like this:

At the server, client input events exercise some localized net code layer on a purely ad-hoc basis (i.e. serviced in small batches the moment packets are received). Players involved in these interactions could receive immediate updates from the localized, ad-hoc simulation (i.e. "infinite" tick rate).

The global tick is responsible for synchronizing these ad-hoc buckets (i.e. the same player can't die to 2 different kill shots). Rollback would likely be required in some cases, but if the global simulation is ticking at 60hz and the likelihood of a rollback is low, I think it could feel really good.

does that make aimbots more effective?

Aimbots are already too effective, I doubt this changes much.

Shouldn't really make any difference, because they're already super effective with ticks. Having more fine timing accuracy doesn't drastically improve them.

Reply on news.ycombinator.com