3 ms·

> Does it cause pop-in when peeking? The goal is early reveal, not exact last-millisecond reveal. CS2FOW predicts using movement and ping, reveals enemi

by xeonmc 3mo ago

> Does it cause pop-in when peeking? The goal is early reveal, not exact last-millisecond reveal. CS2FOW predicts using movement and ping, reveals enemies slightly before exact visibility, and keeps revealed enemies visible briefly. This intentionally leaks a small near-corner window to avoid late pop-in. This fails to address the main point of the "pop-in" issue relevant to fog of war systems, which is that it is the victim of the peek that gets the worst pop-in effect, the peeker much less so. The aggressive peeker gets the benefit of the early-prediction from the server since they're the initiator of the movement, whereas the victim only begins to receive the information after the peeker has already gotten two network roundtrips worth of early prediction.

webstrand 3mo ago
Interesting, could it be mitigated by the server doing its own prediction and defogging the peeker early? Or is lag prediction in CS2 not entirely client-sided.
- xeonmc 3mo ago
  It's more that momentum-based defogging means that the peeker has control over how to manipulate the server's prediction, whereas the victim who is already disadvantaged by network latency now gets an additional penalty of the movement initiation being not telegraphed. To solve this, the fog of war would need to use purely positional near-edge tolerances, which defeats the entire purpose of fog of war to begin with, which is the pre-aiming reaction time advantage of tracking the peeker through walls in addition to having a farther lever point from the cover than the peeker.
bakies 3mo ago
Why wouldn't you just send the positions to both clients in the same tick? Seems trivial to solve.
- dvt 3mo ago
  "Same tick" is a misnomer for a few reasons. First of all, games use UDP, which is basically a "fire and forget" protocol (which means packets get dropped routinely). Second of all, realtime games use some interpolation/prediction to make up for latency (and aforementioned dropped packets). So it's sort of a "relativistic" temporal system, not a linear "oh now you're at t=1, now you're at t=2" kind of timeline. And there's all kinds of complicated ways you create concensus between multiple clients, between server and clients, etc. (A lot of this remains an active research area.)
  - bakies 3mo ago
    Counter strike in fact uses ticks
    - dvt 3mo ago
      A tick is the smallest amount of time the server does its "work" in. It does not mean, as the person I'm replying to was implying, that clients are 100% always lined up, because a game is played (locally) at much higher update rates. So a server, of course, does send updates (player position, etc.) every "tick," but that doesn't matter. Even assuming zero dropped packets (suppose we're playing over TCP), it would feel like shit (stuttering, rubber-banding, pop-in, jittery physics, etc.) to play a game over a ~60ms latency that updates ~60 times a second vs other people that also are ~60ms from the server, so game engines do a lot of interpolation and servers are in charge of concensus. Hence, it's a bit of a misdirection to say: "can't you just send everyone the right player data every server update?" because servers obviously already do that (and that's not really the hard part, anyway). Local interpolation and remote concensus is the hard part, and games handle this differently. In CS, for example, two players cannot kill each other (with guns) simultaneously. Valve's engine requires that someone always wins a gunfight (which sometimes can feel random). However, I would argue that feels way better than, e.g. in Halo, where you can headshot each other (and both players die), which feels dumb and frustrating. So when building these servers, there are lot of tradeoffs to consider (a lot of which might change the feel of the game).
      - bakies 3mo ago
- Sayrus 3mo ago
  Peeker's advantage is not directly related to fog of war. The peeker is moving so before the movement is even sent to the server, the client's camera began moving. As such, the peeker will have at least a tick, usually more before that new position is available to the opponent. "Fixing" this would make movement sluggish: any movement would need to be validated by the server. Meaning delay between pressing keys and actual movement.
  - 20k 3mo ago
    But the pop in system doesn't relate to this at all. Peekers advantage still exists with this system on or off in exactly the same way, and both players will see exactly what they would have seen previously without the culling system
- ThatPlayer 3mo ago
  That would have to include your own position on your own client. Adding a delay of the RTT of the worst latency in the server to your inputs Some games still do this. RTS games notably, but hide it with mouse and sound effects. If anyone remembers the Starcraft 1 option of "extra high latency", it would work by increasing the delay.
deleted 3mo ago
[deleted]
the_gipsy 3mo ago
What is the reason for thinking "early, not milliseconds" would not mean "early enough for the peeked/victim too? Ultimately the server must decide when to "pop" players, regardless of client interpolation which can only happen after the pop. So why would the server delay the pop for one player?

by xeonmc 3mo ago

webstrand 3mo ago

Interesting, could it be mitigated by the server doing its own prediction and defogging the peeker early? Or is lag prediction in CS2 not entirely client-sided.

xeonmc 3mo ago
It's more that momentum-based defogging means that the peeker has control over how to manipulate the server's prediction, whereas the victim who is already disadvantaged by network latency now gets an additional penalty of the movement initiation being not telegraphed. To solve this, the fog of war would need to use purely positional near-edge tolerances, which defeats the entire purpose of fog of war to begin with, which is the pre-aiming reaction time advantage of tracking the peeker through walls in addition to having a farther lever point from the cover than the peeker.

bakies 3mo ago

Why wouldn't you just send the positions to both clients in the same tick? Seems trivial to solve.

dvt 3mo ago
"Same tick" is a misnomer for a few reasons. First of all, games use UDP, which is basically a "fire and forget" protocol (which means packets get dropped routinely). Second of all, realtime games use some interpolation/prediction to make up for latency (and aforementioned dropped packets). So it's sort of a "relativistic" temporal system, not a linear "oh now you're at t=1, now you're at t=2" kind of timeline. And there's all kinds of complicated ways you create concensus between multiple clients, between server and clients, etc. (A lot of this remains an active research area.)
- bakies 3mo ago
  Counter strike in fact uses ticks
  - dvt 3mo ago
    A tick is the smallest amount of time the server does its "work" in. It does not mean, as the person I'm replying to was implying, that clients are 100% always lined up, because a game is played (locally) at much higher update rates. So a server, of course, does send updates (player position, etc.) every "tick," but that doesn't matter. Even assuming zero dropped packets (suppose we're playing over TCP), it would feel like shit (stuttering, rubber-banding, pop-in, jittery physics, etc.) to play a game over a ~60ms latency that updates ~60 times a second vs other people that also are ~60ms from the server, so game engines do a lot of interpolation and servers are in charge of concensus. Hence, it's a bit of a misdirection to say: "can't you just send everyone the right player data every server update?" because servers obviously already do that (and that's not really the hard part, anyway). Local interpolation and remote concensus is the hard part, and games handle this differently. In CS, for example, two players cannot kill each other (with guns) simultaneously. Valve's engine requires that someone always wins a gunfight (which sometimes can feel random). However, I would argue that feels way better than, e.g. in Halo, where you can headshot each other (and both players die), which feels dumb and frustrating. So when building these servers, there are lot of tradeoffs to consider (a lot of which might change the feel of the game).
    - bakies 3mo ago
Sayrus 3mo ago
Peeker's advantage is not directly related to fog of war. The peeker is moving so before the movement is even sent to the server, the client's camera began moving. As such, the peeker will have at least a tick, usually more before that new position is available to the opponent. "Fixing" this would make movement sluggish: any movement would need to be validated by the server. Meaning delay between pressing keys and actual movement.
- 20k 3mo ago
  But the pop in system doesn't relate to this at all. Peekers advantage still exists with this system on or off in exactly the same way, and both players will see exactly what they would have seen previously without the culling system
ThatPlayer 3mo ago
That would have to include your own position on your own client. Adding a delay of the RTT of the worst latency in the server to your inputs Some games still do this. RTS games notably, but hide it with mouse and sound effects. If anyone remembers the Starcraft 1 option of "extra high latency", it would work by increasing the delay.

deleted 3mo ago

[deleted]

the_gipsy 3mo ago

What is the reason for thinking "early, not milliseconds" would not mean "early enough for the peeked/victim too? Ultimately the server must decide when to "pop" players, regardless of client interpolation which can only happen after the pop. So why would the server delay the pop for one player?