5 ms·

We are talking a couple of hundred kB here. They store more in analytics.

oliwarner 7y ago
For CSGO it's about 80MB/hour at 32Hz (apparently the current OW rate). Many servers run at 128Hz. Logging a rolling week's activity at that higher rate requires 53GB but you could dramatically reduce the burden by only keeping things with in-game reports and then deleting recordings after the last issue was dealt with. My point is it's not nothing, but it's nothing by modern standards if you've got more than two brain cells to rub together.
- hutzlibu 7y ago
  Then something is wrong with the logging. If you only record player input: mouse movement, clicks and keystrokes, it should be much lower.
  - oneplane 7y ago
    Except that the data logged isn't just "mouse moved x,y to x,y" but more like 'hid frame was X'. And empty hid frames are still hid frames.
  - untoreh 7y ago
    you can inspect it yourself, I assume the format is the demo record which has been available in source games since decades
  - oliwarner 7y ago
    Should it? What sort of density do you expect? 32 ticks a second, say 16 players. At least 512 state/event points to log per second, plus running game state/events. As I said, it's not nothing, but it's not bad.
  - clarry 7y ago
    It's probably recording what amounts to a demo record, which basically contains everything you would need to reconstruct the player's point of view as if you were spectating them. This means the record must contain everything the server sends to that player (other players' locations, sounds, map state changes, chat, etc.). Technically you could record only the players' inputs but to play back such a recording, you would then have to deterministically reconstruct the entire match from all players' inputs. That's a bit more complicated than just replaying the local part of the simulation that your client already does with what data the server sends to players during normal course of gameplay. oliwarner's numbers amount to about 45 bytes per frame per player, which is not unreasonable.
- clarry 7y ago
  At that rate there's also going to be plenty of redundant information, so I think this data would compress quite well.

For CSGO it's about 80MB/hour at 32Hz (apparently the current OW rate). Many servers run at 128Hz. Logging a rolling week's activity at that higher rate requires 53GB but you could dramatically reduce the burden by only keeping things with in-game reports and then deleting recordings after the last issue was dealt with. My point is it's not nothing, but it's nothing by modern standards if you've got more than two brain cells to rub together.

hutzlibu 7y ago
Then something is wrong with the logging. If you only record player input: mouse movement, clicks and keystrokes, it should be much lower.
- oneplane 7y ago
  Except that the data logged isn't just "mouse moved x,y to x,y" but more like 'hid frame was X'. And empty hid frames are still hid frames.
- untoreh 7y ago
  you can inspect it yourself, I assume the format is the demo record which has been available in source games since decades
- oliwarner 7y ago
  Should it? What sort of density do you expect? 32 ticks a second, say 16 players. At least 512 state/event points to log per second, plus running game state/events. As I said, it's not nothing, but it's not bad.
- clarry 7y ago
  It's probably recording what amounts to a demo record, which basically contains everything you would need to reconstruct the player's point of view as if you were spectating them. This means the record must contain everything the server sends to that player (other players' locations, sounds, map state changes, chat, etc.). Technically you could record only the players' inputs but to play back such a recording, you would then have to deterministically reconstruct the entire match from all players' inputs. That's a bit more complicated than just replaying the local part of the simulation that your client already does with what data the server sends to players during normal course of gameplay. oliwarner's numbers amount to about 45 bytes per frame per player, which is not unreasonable.
clarry 7y ago
At that rate there's also going to be plenty of redundant information, so I think this data would compress quite well.