4 ms·

"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 Counte

by Thaxll 4y ago

"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.

entropicdrifter 4y ago
It means they're increasing the granularity of the timeline of events in order to improve accuracy and fairness.
- JusticeJuice 4y ago
  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.
  - _cenw 4y ago
    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.
  - Sniffnoy 4y ago
    Is there a reason you would expect them to use floats here instead of fixed-point? I would naively guess the latter.
    - gravitronic 4y ago
      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.
wnevets 4y ago
does that make aimbots more effective?
- kuroguro 4y ago
  Aimbots are already too effective, I doubt this changes much.
- JusticeJuice 4y ago
  Shouldn't really make any difference, because they're already super effective with ticks. Having more fine timing accuracy doesn't drastically improve them.
bob1029 4y ago
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.
_cenw 4y ago
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.
- ultrahax 4y ago
  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.
  - _cenw 4y ago
    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.

by Thaxll 4y ago

entropicdrifter 4y ago

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

JusticeJuice 4y ago
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.
- _cenw 4y ago
  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.
- Sniffnoy 4y ago
  Is there a reason you would expect them to use floats here instead of fixed-point? I would naively guess the latter.
  - gravitronic 4y ago
    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.

wnevets 4y ago

does that make aimbots more effective?

kuroguro 4y ago
Aimbots are already too effective, I doubt this changes much.
JusticeJuice 4y ago
Shouldn't really make any difference, because they're already super effective with ticks. Having more fine timing accuracy doesn't drastically improve them.

bob1029 4y ago

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.

_cenw 4y ago

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.

ultrahax 4y ago
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.
- _cenw 4y ago
  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.