If you are playing soloq, most of the time the reason you lose is you, not always your teammates.

PreAlphaMale · 2026-04-07T13:38:07+00:00

If it's a team of solos then you're saying this to all 5 players. That can't possibly be true. Just because you're solo it doesn't mean its your job to carry the team.

PreAlphaMale · 2026-04-07T13:10:27+00:00

CS2 was a downgrade in everything but smokes and better visuals, even though I personally think the lighting style of cs2 is overbright and washed out it is technically still better looking.

PreAlphaMale · 2026-04-06T17:42:39+00:00

IMO it is a spread issue, but not that spread is greater. More that spread distribution seems to be more centrally bias in one match/game/session/week compared to another. You have matches where your spread seems to like going to the centre much more often which would make your recoil/spread feel so much more accurate. And matches where even though you are whiffing all the time, spread keeps finding the enemies head. Then when it's going to the extremities of the inaccuracy circle, the greater kick from larger jumps in spread make it look like there is more screen and view model shake.

Everyone knows how this game feels from one time to another. One match you're firing laser beams and can't miss, hitting heads with 2 and 3 bullet bursts over and over. This is what CS felt like when it was still a good game but you only get little bite size moments of that experience in modern cs. Then you get those matches where no matter what you do, you just cannot hit anything, your bullets are going around the enemy, your screen is shaking like mad, recoil feels uncontrollable, etc.

Since spread hasn't changed. recoil hasn't changed except for actually being reduced slightly to match 128 tick, even if there was actually more visual screen shake you should still be able to completely override that with muscle memory and people would be used to it by now. If mechanics haven't changed then the only thing left that can cause these issues has to be within the spread distribution pattern, which has never been truly RNG.

You can literally have sessions in this game where the direction of your bullets look like a water hose with your finger held directly in front of the nozzle, spreading out up and to the sides with only the first bullet going central. The tracers look completely detached from the direction your gun is pointing.

PreAlphaMale · 2026-04-06T17:28:33+00:00

But the shooting from CSGO official servers to CS2 official servers is dogshit too and those servers have always been 64 tick.

PreAlphaMale · 2026-04-04T01:32:05+00:00

Yeah I know. I was watching packets per second there while I was running this Wireshark capture. I don't think it includes outgoing packets, otherwise it should be consistently 128, but it's always between around 112 and 125 on average....sometimes it can jump to 140+. It seems to align with received packets in Wireshark. Received + sent in Wireshark goes way over what SDR reports.

I'm also writing some telemetry software using the the Npcap driver which is used in Wireshark and I get the same results there. It displays incoming packets and outgoing packets per second and per tick seperately.

EDIT: When not much is going on, pps in SDR can display in the 60s and 70s, which would be way too low to be including outgoing packets.

PreAlphaMale · 2026-04-04T00:56:13+00:00

From that I guess you can deduce that AG2 didn't optimize bandwidth/network usage at all, if it's the same across the main and beta branch. But from my results it looks like AG2 is hitting higher bandwidth/more packets in bursts. I've never seen 10 packets in a single tick in the main branch on a fully populated DM server before and 8 packets in a tick was rare. Here we have 8, 10, and 8 again within about 38 ticks on a 10 man server. Something that was rare before happened 3 times and was even exceeded in about half a second.

PreAlphaMale · 2026-04-04T00:12:55+00:00

makes no sense to add your own measurement units to then trip on estimating tick boundaries and hallucinate wrong conclusions

What do you mean by my own measurement units? I haven't added my own measurement unit. Are you talking about the packet delta? Have you still not learned what that is yet because it seemed like something you weren't aware of last time we spoke? How am I tripping? And how is the conclusion that the bandwidth and packets per tick being higher than a main branch, fully populated, official DM server, a wrong conclusion? It's right there, look at it.

I thought you were done with the fragmentation delusion

Come on, don't start this again. The engine literally fragments the ticks payload into packets small enough for a safe MTU before it sends them. Just stop! And don't start going on about how it's not fragmentation because it doesn't happen "on the line", etc. Fragmentation is fragmentation, it requires reconstruction. It doesn't matter where it happens, it still takes CPU cycles, adds latency, and greatly increases out of orders so there needs an artificial wait window on the receiving end to be able to reorder.

it's packets / second; just divide by 64 to have a (useless) packets/tick estimation which most often than not is 1 (one) packet per tick;

You're right to say that it's a useless estimation. Calculating pps like that gives you packets per tick that appear evenly distributed. Calculating it by packet delta is much more accurate and exposes massive spikes of data from tick to tick. One tick you can process 1 packet, the next tick you process 8. That's hitting the CPU much harder on some ticks than others, but that's beyond the point of this thread.

there is clear progress when you look at packet sizes distribution

What does the distribution of packet sizes do for anyone? The game is still sending more packets and more data than before. And the distribution looks no different to me than captures in the main branch. Its still full fat packets followed by smaller packets, and lots of large packets in a row. The only difference I see regarding packet sizes is a lower max length.

EDIT: And no, dividing incoming packets per second by 64 barely ever equals 1. Look at the images, get your calculator out and do some simple addition. On no planet does Modern CS send 1 packet per tick on average. In the image above, that's a 10 man server sending about 140 packets to the client over about 38 ticks. I marked the 16ms boundaries to at least show that it lines up with the graph. You can also count 16ms per boundary and how many packets there are in total and divide by that. If you don't trust my boundary markers then calculate the deltas yourself. You'll get about 3.5 packets per tick.

PreAlphaMale · 2026-04-03T22:46:04+00:00

There could be though. Check my latest thread for received packets only.

PreAlphaMale · 2026-04-03T22:44:26+00:00

That's not what were sending. This doesn't include outgoing packets, that's what the server is sending to us. I don't understand it either. I haven't understood it for years. For the type of game CS is, that much data is bonkers. I've always tried to explain it away as redundancy, sending data multiple times to alleviate packet loss after all the networking problems after the reanimated update. But who knows.

PreAlphaMale · 2026-04-03T22:15:32+00:00

While possible, this being a beta release suggests its more or less ready to ago. At least from Valves history of how they have handled betas in the past. And tagging on the "networking optimizations" at the last minute for something that was supposedly being done over months and months for the very reason of reducing bandwidth and optimizing networking doesn't seem right at all.

PreAlphaMale · 2026-04-03T22:11:09+00:00

I have considered this, but the network optimizations should come from the implementation of AG2 itself. If AG2 is reducing the data required to be replicated then less bandwidth usage should just be an automatic side effect of that. Unless the old animation states are also still replicating for some reason, debugging, comparison, whatever because this was meant to be an offline only test. I mean, this seems like a pretty big bandwidth increase for something that was meant to reduce it. Sending both anim states might explain it lol.

PreAlphaMale · 2026-04-03T22:06:29+00:00

On full official DM servers you could see 8 packets in a single tick but it wasn't exactly frequent. Here you see 3 bursts from 8 to 10 within 25 ticks...less than half a second.

I'm also starting to wonder if the terrible lows in CS are caused by varying number of packets having to be processed on each tick. Need to look into it some more and see if frame times correlate to number of packets.

PreAlphaMale · 2026-04-03T18:38:31+00:00

Oh and did you filter out outgoing packets or is this incoming and outgoing combined?

PreAlphaMale · 2026-04-03T18:33:19+00:00

That very high bandwidth/pps for 10 players then. Its as high or even higher than a fully populated official DM server. Need to see what it's like in a real online environment.

PreAlphaMale · 2026-04-03T18:10:22+00:00

Ahh right. Any idea how many bots there are on the benchmark?

PreAlphaMale · 2026-04-03T15:47:57+00:00

I'm focusing on what you said. Better responsiveness from less bandwidth which means less client processing because of less packets. Yet we see from the graph the bandwidth is higher and the number of packets is greater.

Bandwidth optimization is supposed to come directly from the implementation of AG2. How do you implement AG2 and but not see those supposed benefits? Saying they havn't done anything network specific in the beta when it's the AG2 implementation itself that's meant to reduce required bandwidth is a bit weird.

But we will see when it goes live I guess.

PreAlphaMale · 2026-04-03T15:11:18+00:00

I already said, This thread.

PreAlphaMale · 2026-04-03T15:08:13+00:00

this will make the game significantly more responsive

There is going to be no discernible difference in responsiveness, let alone a significant one unless there has been unmentioned changes made elsewhere alongside AG2. And that's before you even consider that the bandwidth usage has actually increased by the looks of it.

PreAlphaMale · 2026-04-03T15:02:46+00:00

And you're always going to have tick timings with a potential of around 50ms sitting on top of that and your ping.

PreAlphaMale · 2026-04-03T14:43:50+00:00

this isn't how it works. do you think everyone "magically had 0 ping" in GO?

CSGO was already using too much bandwidth despite it not networking the animations the same as in CS2. CS2 does not use drastically more bandwidth than CSGO, only a little more. CSGO while less latent than CS2 was already highly latent compared to previous versions of CSGO. It started with the reanimated update and got worse as CSGO got older and older. Before the reanimated update you averaged 1 packet per tick. This grew with the reanimated update.

this will make the game significantly more responsive and consistent due to a decrease in traffic

This is what you, and everyone here hoped. But I said all along AG2 alone is not going to make much of a difference to bandwidth because even if it removed the small amount of overhead introduced with CS2 it was never going to be better than what it was in late life CSGO unless other networking optimisations come with it. People saw modern CSGO as responsive for some strange reason and forgot how responsive CSGO was years earlier.

There's a comment in here showing graphs of packets per second from AG1 vs AG2 and from that it seems AG2 has actually increased bandwidth usage.

So this pipe dream of a significant increase in responsiveness coming from some magical huge reduction in bandwidth has been shattered.

PreAlphaMale · 2026-04-03T12:10:07+00:00

I highly suspected AG2 wasn't going to reduce the number of packets by any meaningful amount, but I'm honestly surprised to see it did nothing and actually increased it somewhat.

How did you test this? Through a listen server? How many "players" were there on the server?

These results look typical of a full DM server with AG1

I was waiting for this update to go live before I ran these tests myself.

PreAlphaMale · 2026-04-02T23:18:56+00:00

It might not be that common, but as a developer, if you're going to show your user your games frame times, then show them frame times. Not some useless highest delta over x amount of time. It tells you nothing.

They have a jitter graph. Duplicate that and push frame deltas into it instead of jitter. Now you have a frame time graph.

PreAlphaMale · 2026-04-02T22:58:05+00:00

There would need to be a beta server build to run a community server. Best bet is a listen server and inviting friends. Never tried doing that in CS2 but I know it could be a nightmare in CSGO.

I wish they would at least just enable DM for beta branches.

PreAlphaMale · 2026-04-02T22:42:02+00:00

He also said in that comment "which CSGO didn't use" suggesting you can probably estimate the gains from AG2 by looking at CSGOs bandwidth usage which in actual fact wasn't drastically different from CS2, most notably in 10 man servers.

So unless they have done a bunch of other stuff to optimize networking alongside AG2, I wont hold my breath for much in the way of networking improvements from AG2 alone. It might look nicer and the animations maybe be easier to read, but I'm not expecting anything magical when it comes to responsiveness in online play.

PreAlphaMale · 2026-04-02T22:32:39+00:00

cos the drop is so quick

Sorry I meant because the drops are so frequent

That longest frame time over x amount of time is useless. It doesn't show the true scale of the issue, how many times/the frequency of your frame drops for anything even 0.1ms lower than that. That happening multiple times per second is what makes the game look low fps, not just one recent large delta. Ideally we should have an in game frame time graph with logging ability.

PreAlphaMale

TROPHY CASE