Blur Busters Forums

rusihhh wrote: If you have something to contribute — like real Wireshark captures or engine insight — that would be valuable.

Otherwise, please refrain from derailing the thread further.

No. I will write whatever I want.

28 Jun 2025, 23:06

rusihhh wrote: ↑

28 Jun 2025, 23:06

1. Download and install Wireshark.
2. Start capturing packets at the beginning of a game session.
3. Apply a filter to isolate UDP traffic (usually ports 30xx, 50xx — depends on the game).
4. Let it run during the entire match.
5. Do the same for another match — or ask a friend (ideally on another ISP or different ping) to capture their session.

11 hours earlier.

28 Jun 2025, 13:16

rusihhh wrote: ↑

28 Jun 2025, 13:16

Colleague, Wireshark is a great tool — but not fully decisive in this scenario.
Each game world and client session is highly dynamic: packet content depends on line of sight,
player position, nearby activity, and even tick timing. So results are inherently non-deterministic.

You are proposing a methodology that you yourself have previously rejected. And this data does not support your theory in any way.

1000WATT wrote: ↑

02 Jul 2025, 13:24

...

I genuinely don’t understand your goal here.
You’re not trying to disprove the theory, not offering technical insight — you’re just picking at words and tone, while ignoring the actual question.

My original point was simple:
That **some engines may adjust packet size/frequency based on perceived connection quality** — a concept seen in networking layers of modern game engines.

As GPT put it:

GPT wrote: There are indeed similar mechanisms in some modern engines — including Unreal Engine 5 (UE5).

For example, UE5’s Netcode includes features like:

• Adaptive Update Rate — reduces how often data is sent to certain clients, depending on distance, relevance, or connection quality.
• Network Relevancy — not all actors replicate to all clients at the same rate or with the same detail.
• Packet Aggregation — combines multiple frames into one packet if possible — or splits them when needed.
• Prioritized Replication — actors and actions deemed more “important” are sent first; others may be delayed or dropped under load.

Yes, I said Wireshark has *limitations* — because it doesn’t show the full content of game logic. But it’s still useful when comparing multiple sessions, different servers, or clients with varying conditions.
That’s why I encouraged people to gather more data — not to rely on one isolated capture.

Your sarcasm about hormones, and now nitpicking time stamps, doesn’t help anyone understand the mechanics.

The real question remains:
Why are some players receiving fuller updates while others seem to get trimmed packets — even without visible problems like loss or jitter?

I’m asking for deeper insight:
— engine-level behavior
— per-client shaping logic
— heuristics or thresholds
— tick sync or relevancy metrics

If you know something about how CS2, Source 2, or similar engines handle this — please share it.

Otherwise, please stop derailing with non-technical mockery.
Let’s keep this space useful for those trying to understand why their game feels broken despite clean metrics.

Sorry , I’ll repeat the theory again — and explain why I came to this conclusion:

I observed this behavior in both CS2 and Rainbow Six Siege after analyzing several Wireshark pcap files from different matches.
the average size of inbound UDP packets differed significantly between players.

Important to understand:
UDP packets do not change in transit — they are generated by the game (application layer) and arrive exactly as sent.
This is not TCP — there’s no fragmentation, reassembly, or retransmission.
So if one player receives 60 packets/sec at ~200 bytes each, and another receives 60/sec at ~100 bytes,
then the game itself is deciding to send them less data — based on some internal logic.

What this means in practice:
At tick T1, an enemy performs: peek → shoot → crouch.
The player getting “full” packets receives all of that in one update and can react appropriately.
The one getting “thin” packets might only get the peek — and receive the rest later.
By the time they visually see the enemy, it’s already T2 or T3 — and they’re dead.

In simpler terms:
You were supposed to react at T1 —
but your client didn’t get the necessary info.
You only see the enemy after your death has already been registered.
That’s why you get “Ferrari peek” situations — where someone instantly appears and kills you with no chance to respond.

As ChatGPT explained:
Similar mechanisms do exist in modern game engines:

• UE5: Adaptive Update Rate, Network Relevancy, Prioritized Replication
• Unity: Adaptive Sync, QoS-based Replication
• Source 2: no public documentation, but the effects are consistent with similar behavior

Theory:
The game may be dynamically adjusting the amount of data it sends to each client,
based on its internal evaluation of connection quality or server-side heuristics.

How does changing my resolution mid game impacts my hit registration for a short period of time. One guy told here on forum to increase screen scaling to 120 and and it did help for some time(I tried it myself in CS2), but then slowly degraded back to shitty hit reg and insane enemy peaks to which impossible to react. We are all f**ed!

I have the same issues and i found something new, might be a good indicator whether you should bother playing today or not. Please refrain from hardware/ram timings/regedit tweaks bs.

First, here are some of the examples. Its not always about the kill but the way i die in such slow paced game and the fact that my crouch key didnt register half a second after pressing it

https://youtu.be/h5YeZx7TlDg
https://www.youtube.com/watch?v=KI5RCLt ... br&index=3


Worth noting, most of these people are 1/5th of my skill rating in cs2 and i barely even touch it.

i tend to insta crouch with certain guns/in certain duels right before/when gunfight starts/mid gunfight but just as some of you, im half a second behind the server, people tell me that i didnt crouch.

Already have played on 70 ms (same isp) before but its just the same as 110, so its not a ping issue.


Now the important part - i have discovered something that some of you havent:

When my fps is uncapped (its not about the cap/uncap thing, its about getting 750+ frames, i have a 9800x3d), i simply have trouble moving around the map, i get teleported back and forth. No packet loss thing but i get that "network problem" indicator. The second way to test whether youll perform or not is asking your Neon to jump around, if its stuttery - good luck. The third one is shooting gekkos flash or kjs drone and getting noregs. And the sova reveal thing.

https://youtu.be/kJARnuj2ZOY

Now i wonder why having 1000 frames leads me to having network issues and what can we learn from it. Its not the game/engine issue in case of fps, its our ISPs fault but maybe we can figure out something useful.

What I would say is I do not think it is one particular ISP fault. Or internet issue from our side.
The same issues have occurred for me across different locations with different network/ISP and different PCs. Across different countries and continents.

rusihhh wrote: Yes, I said Wireshark has *limitations* — because it doesn’t show the full content of game logic. But it’s still useful when comparing multiple sessions, different servers, or clients with varying conditions.
That’s why I encouraged people to gather more data — not to rely on one isolated capture.

Let's say we believe everyone who provides data that he has no "visible" problems with the Internet and does not use registry settings for the network adapter.

We wait a million years, we get a billion cycles of single records.
And how is this data useful? You won't even be able to find out whether the method you described earlier is being used.

• Adaptive Update Rate — reduces how often data is sent to certain clients, depending on distance, relevance, or connection quality.
• Network Relevancy — not all actors replicate to all clients at the same rate or with the same detail.
• Packet Aggregation — combines multiple frames into one packet if possible — or splits them when needed.
• Prioritized Replication — actors and actions deemed more “important” are sent first; others may be delayed or dropped under load.

Because even if this method is not applied, the packet size will be different in different game sessions and will depend on the activity of the players.

RealNC wrote:

Who does this newly created account "rusihhh" belong to?

I can give you a hint why this happens. Network packets do not appear out of thin air, they are created by the game's network code. The game code, physics, shooting, etc., everything that exists, is created by your computer, your processor, your memory. If you feel some problems with input lag or image in games without the Internet and this lag changes randomly, everything will be a million times worse in online games. Your computer simply cannot create "correct" network packets.

TN_fun wrote: ↑

03 Jul 2025, 06:10

I can give you a hint why this happens. Network packets do not appear out of thin air, they are created by the game's network code. The game code, physics, shooting, etc., everything that exists, is created by your computer, your processor, your memory. If you feel some problems with input lag or image in games without the Internet and this lag changes randomly, everything will be a million times worse in online games. Your computer simply cannot create "correct" network packets.

hahaha...

yes randomly at one summer day somewhere in 2017 or 2019 from nothing and air...my first computer and all other computers after that i build...was not more able to simply create "correct" network packets...

irony off


funny you.

wait...i forget about consoles players which too randomly started to have same exact feelings and problems like some pc users here...must be probably hardware issue too and they stopped randomly to simply create "correct" network packets too one day...

irony off x2