Trying my luck here again to clear a few things up. Usually, I'm not including this in my replies, but as you've attacked me before, I'm going to say this upfront: I have hands-on experience with the Source engine as I've programmed plugins and server management tools for CS:GO before. In terms of Source engine, I do know exactly what I'm talking about as I've directly interacted with the engine before. So, what I'm about to type is true for the source engine (CS:GO, CS:S etc). Other games I didn't program for, but I still know a whole bunch of stuff about netcode in different games. Alright, let's see now.
rusihhh wrote: ↑08 Jul 2025, 10:45
- The game sent you *everything too late* in one packet.
This cannot happen without the game noticing that something is wrong. First off, the game won't just "send you everything too late in one packet". If that would be the case, it would be a "bug" or at least a known problem with a game's engine and how it handles its networking. If this were the case, every player would have the problem and not only some select players.
There are 2 main ways that your hypothetical scenario could manifest itself:
1. Packets have been delivered "out of order".
2. Packets have been delivere in order but are delayed.
Let's see if we can spot this.
Scenario 1. What's happening here is a little bit complicated. As I've said before, the game server sends your client a constant data stream, 64 packets per second. Each packet represents a "frame" of game state. The network protocol used for virtually any real-time online game is UDP, which "doesn't care" about delivery success of packets (oversimplified). UDP, as used in gaming scenarios, donesn't have mechanisms to check for missing packets, and it doesn't need to, because by the time a missing packet would be detected and re-transmitted, the information contained in that packet is already out of date. UDP works like a "fire and forget" cannon. The server fires data at your client and instantly upon firing out the data forgets about it. It has no means of telling that data has arrived.
Let's say you're receiving a constant stream of packets from the server. In an ideal world, it looks like this:
1-2-3-4-5-6-7-8-9-10
Each number represents a packet.Your client would display this as perfect, stutter-free, normal gameplay.
If there's a hiccup along the path, data packets can be delayed a little bit. In this theoretical scenario, it would look maybe like this:
1-2-3-6-5-7-4-8-9-10
As you can see, everything still looks like normal up to the 4th packet. Packet #4 has been delayed along the path somewhere, so it doesn't arrive in it's intended "location" inside of the data stream. Your client will now display a "jump": After packet #3, it sees #6, so it displays the game state as seen in packet #6. From now on, it waits on subsequent packets that are further forwards in time. After packet #6, packet #5 arrives at the client. However, packet #5 contains a game state that's older than what the client is already displaying at the current moment in time. The client has no idea what to do with this packet, as it contains outdated information - it is discarded. Now, here's the important part: As packets #4 and #5 are discarded, they'd show up as packet loss - in my example with 10 packets, 2 are discarded, meaning a loss of 20%.
The simple conclusion is that yes, out of order packets might cause this effect visually, but it would be diagnosable as packet loss. Game overlays would indicate that packets have been lost if out of order packets were to blame.
Scenario 2: This is infinitely more simple to understand. If there's some delayed data, it is the literal definition of increased latency, or ping. If this happens, it will show up in a game's diagnostic overlay as either high ping or excessive jitter.
rusihhh wrote: ↑08 Jul 2025, 10:45
- Or the internal game logic **batched actions together**.
As hinted at before, this could be possible and some games have done this in the past, namely Battlefield 3 and Battlefield 4. The reason these game have done that however are of a different nature. These games run on low tickrates, like 10Hz. Some actions you can perform within the game can "fit" multiple actions into one frame. For example, there are fully automatic machine guns and assault rifles that have a higher rate of fire than what would fit into one frame of game state. If you shoot your fully automatic MG3 at someone and you're hitting him 2 times, both of these hits occured within one frame of game state, meaning that both hits are transmitted to the opponent within one data packet. This simply would deal 2x damage than what would usually be possible within one gamestate frame.
However, this doesn't apply to modern games like CS, Siege and so on, and also doesn't fit the usual problems described on this forum, because of 2 main reasons: Number one, the reason this was done in BF was because of a technical necessity. The game's netcode was too slow to handle the situation otherwise. Modern games, especially the competitive ones, have such fast tickrates that this isn't a concern at all, so this isn't done. The only exception would be if the server would be stalling for some time and it would need to "catch up". However, most modern games also have diagnostic overlay symbols for slow server performance, so this should be visible. Secondly, this is hard-coded into the game, so everyone playing the game would experience this. The problems in this forum are niche however, there are people who can play CS, Rainbow or any other game without any problem. If such behaviour was hardcoded into the game, every player ever would experience it. We don't see this, so this can be ruled out.
rusihhh wrote: ↑08 Jul 2025, 10:45
- Or it skipped sending intermediate states.
Again, this can happen, but the only real reason for this happening would be the server stalling and "catching up" with the current game state. This would trigger a "slow server" warning in a game's diagnostic overlay.
rusihhh wrote: ↑08 Jul 2025, 10:45
It could be a design issue.
Again, if it were, everyone would have it. And we don't see that.
rusihhh wrote: ↑08 Jul 2025, 10:45
- Someone might receive this in one tick: `['enemy movement', 'shots fired']`
- Another might get:
Tick N: `['chicken movement']`
Tick N+1: `['enemy movement', 'shots fired']`
→ He dies without ever seeing the enemy.
This is impossible. This would mean that the server changes its tickrate and sendrate for one client, while being on another tick/sendrate for another client. It can't do that. Even if a game changes tickrate dynamically, at any moment in time, it's always the same for everyone.
Let's say tick N is a valid game state and depicts enemy movement. This gamestate exists on the server and is sent to the clients. If one player sees tick N as "enemy movement", every player sees tick N as "enemy movement". Clients can only see the game state the same way the server saw it. The same is true for tick N+1. It is a valid game state on the server and it's pushed to clients as such. If one player sees tick N+1 as "enemy movement, shots fired", every other player also sees this exact game state.
The only reason why one player might not have seen the game state from tick N is because it either arrived out-of-order or it was lost entirely. Both scenarios would show up on a game's diagnostic display.
rusihhh wrote: ↑08 Jul 2025, 10:45
then **instant deaths** may be caused by the **order, grouping, or missing content in the packets**,
Again, this can't happen, because if a packet is missing content, the client can't interpret it as such and it's simply discarded, again showing up on a game's diagonstic display.
So yeah, hope this helps a little. Out of order packets are a thing and it can cause problems, but these are simple to diagnose and track down. The premise of this post was that this could happen without showing up on a connection monitor, as with anything you've proposed so far, that's not possible. Any of your suggested "problems" would show up on a diagnostic display somewhere.
