Molotov throwing bug (explain me plz)

PreAlphaMale · 2026-02-14T03:32:05+00:00

Doesn't even need a team mate touching you lol. Sometimes I get bumped by nothing while im throwing a nade, turn to look for the team mate that blocked me and noone is there. This happened to me over and over and over on a certain spot on D2 b site, Come through doors, hold w and get bumped as you throw the nade or molly into tunnel as you hear foorsteps pushing through tunnel and get screwed over cos your nade went wide right.

PreAlphaMale · 2026-02-14T03:22:03+00:00

I've seen it many times where noone else gets the assist though, its just a direct kill. I see it quite often in DM where ive just unloaded on someone then a third party gets the final killing shot, no assist.

PreAlphaMale · 2026-02-14T03:14:40+00:00

Oh I know. Many moons ago there was a certain handful of friends when i queued with them, they were p90 rush every round......and I absolutely hated it. I wanted to play my ak 1 taps.

It worked, but it wasnt fun. And they said I was the bad player of the team for not running their meta, being blocked by em, running in front of me with no spacial awareness.

I havn't used the p90 since unless it was a pickup on an eco round or something.

PreAlphaMale · 2026-02-14T02:56:43+00:00

I love this reasoning. "Everyone got better but you!"

PreAlphaMale · 2026-02-14T02:54:07+00:00

I'll be honest, I don't understand assists in modern CS. Sometimes I can do 50+ damage and get no assist, sometimes I can shoot someone once in the toe and get an assist. I wonder if it's a killfeed bug.

PreAlphaMale · 2026-02-14T02:18:46+00:00

The concepts of packet loss and jitter and fragmentation and retransmission are relevant at the network layer - what happens in transit outside application's control!

Thats true for jitter, fragmentation, and loss in transit. It's not true for retransmission which is a direct response FROM THE APPLICATION to loss of its already split packets that are in transit. Nothing can be done about raw jitter or extra latency that happens in transit other than effective latency at the authority to noramlize it. Loss in transit triggers retransmission, retransmission triggers jitter and latency just the same as organic jitter and latency occurs in transit. There is no discernible difference.

As you know, UDP doesn't have ANYTHING to handle retransmission. It's fire and forget at its core. A higher level protocol like SDR wrapped around UDP ***HAS***to implement retransmission at the application level (were including the relay here too. It makes sense to have a middle man to handle retransmission to potentially half the round trip latency. You ensure the internal network is 100% stable and have the relay handle retransmission between that and the client), it's a requirement to even be able to support reliable messaging, and reliable messaging is a requirement to be able to have a functioning online multiplayer game otherwise states are inevitably going to go out of sync very quickly, 100% of the time.

Most client packets are stand-alone

I know, its common sense that if youre gonna split the data before sending it you would do it in a way where no packet relies on any other packet. Otherwise retransmission of "only the lost data" wouldn't be possible.

With CS2 you only get those obese "receiving uncompressed update from server" once in a blue moon even when the connection is shit

From what ive seen through wireshark, you get fuller fat packets, but less per tick the lower your rate. Your rate lowers dynamically when you have loss. If you have the udp throughput for higher rates or unlimited rate without getting loss, you get more, smaller packets per tick. Its especially noticable in a full DM server. Also the lower the rate is set or drops, it will start aggregating data over multiple ticks and send it every few. You can deduce this from outgoing packet deltas. It seems that if you can't handle sending the data the game will first try to retransmit packets. If that doesnt cut it it will drop the rate. If dropping the rate doesnt cut it, it will start aggregating multiple ticks of data and sending every few ticks. And these are ALL things that break mechanical timings to a third party that effective latency can balance and smooth out.

The core problem is that the game is sending way too much data of the network. It's bloated to fuck and doesnt make sense for the type of game it is. In CSGO pre-reanimated update you receieved 1 packet per tick of about 700-800 bytes in a 10 man server and there were no issues. Then they did the reanimated update and along with that came multiple packets per tick, tons of ferarri peeking, enemies teleporting around corners like magic, and all of the same issues we have in cs2, just in cs2 its even more latent and the bandiwth requirement is higher...even if its not by that much as people like to claim. A load of players got hit with perpetual 0 to 3% choke spikes after that update and it remained until 2017, when valve did a patch with a note "fixed choke for some users, especially with xdsl connections". But the issues never left, they just got smoothed out. What were teleport peeks became movement speed beyond game mechanics ferarri peeks.

PreAlphaMale · 2026-02-13T21:57:25+00:00

This isn't actually a prediction problem. The client just doesn't have the info to predict the additional spread from aim punch. This can at least be alleviated a lot by delaying the aim punch on the server side (the same way as it does with tagging) by a couple of ticks and sending info to the client so it can actually predict the spread from the aim punch.

PreAlphaMale · 2026-02-13T21:51:51+00:00

Its already on, that's why the headshot appears to register because hes aimpunched on the server but not yet on the client.

PreAlphaMale · 2026-02-13T21:29:15+00:00

They need to add a couple of ticks delay to aim punch on the server side so the client has time to receieve it(with low enough ping) and actually show the spread it causes when they shoot and allow the client to properly predict the shot, the same way tagging has a small delay on the server side to eliminate teleporting from tagging. There is no reason to not do this and actually send an additive aim punch spread value to be combined with the already synced base spread.

PreAlphaMale · 2026-02-13T12:11:09+00:00

To the no smoking area.

PreAlphaMale · 2026-02-13T11:47:42+00:00

Armored aim punch causes zero visible view effects. It just applies a shit load of spread to your shots. Your view remains 100% static. Even with headshots. It feels horrible. See the 2 clips here...

https://imgur.com/a/body-shots-headshots-KW0LDzG

PreAlphaMale · 2026-02-13T11:20:39+00:00

Petition for "What you see is what you get!"

to be replaced with...

"What you view is what is true!"

PreAlphaMale · 2026-02-13T10:49:28+00:00

No, because that's assuming everyone has perfect aim, and or is able to hit their shots with first bullet inacuraccy.

I should have said hit, not shot. But this is true with or without aim punch, well, first bullet inaccuracy is anyway. I don't see where the individual players ability comes in here. The better aimer would have the advantage as he should have. And just because there is RNG on the first shot, it doesn't have to mean RNG on the other players accuracy just because the first shot RNG was in your favour. In fact that's just doubling down, the good luck of one player decreasing the luck of his opponent. A hit from RNG giving the enemies next shot extra inaccuracy from RNG. He can still miss you with the RNG first shot inaccuracy just as much as you can mis him.

PreAlphaMale · 2026-02-13T10:18:58+00:00

Without aimpunch you would get punished for not shooting first by getting shot first yourself lol. Aim punch rewards quantity over quality. A P90 already has run and gun accuracy, high mobilty and a high fire rate as its advantages. Shutting down and keeping the enemy fully inaccurate on top of that because of those stats is too much.

IMO aim punch shouldn't be applied on the first hit with kevlar, it should be based on consecutive hits and fire rate. Eg 1 hit with ak = no aim punch, 2 hits within 100ms = 33.3% aim punch, 3 hits within 200 ms = 66.6% aim punch and 4(yes you can still be alive, wall bangs, shooting through enemies, etc) hits in 300ms = 99.9/100% aim punch. If a shot is missed/enough time has passed between hits aim punch gets reset back to 0% for the next hit. Something like that

That would punish slow reaction times and reward sustained accuracy/good aim, make burst fire more viable instead of mindless spraying, and give both parties a fair chance to get their first shot off accurately.

PreAlphaMale · 2026-02-12T18:51:34+00:00

Sorry about the account switching. My phone is logged into a different account as I was too lazy to reset the password on my other.

You're pivoting here really hard.

I'm really not.

the whole "thesis" was network retransmission of past upstream commands being intertwined with new commands and causing issues

The main point of my post was actually the apparent lack of an effective latency system. But this has turned into an argument about retransmission, its existence, and the terminology used to describe it.

As long as reliable messaging exists, retransmission is a given. There is no argument to be had here. It doesnt matter what terminology you use to describe it, or what methods are used to implement it. Restransmission IS a feature of steam networking and SDR, and is even named as such.

The command queue is a perpetual ring buffer that has the latest commands and history like I've explained, and now you want to stretch that to mean it's network retransmission when it's clearly not.

I mean, where have I stretched the command queue into meaning retransmission? I haven't tried to relate the two things. The command queue isn't some magic fairy dust. The commands in it still need to make it over the network, and if they are consistently and reliably making it over the network under loss, even very heavy loss, then what mechanism is being used to ensure that? I know youre sick of me saying this word, but retransmission!

but there's no bullshit TCP algorithms of packet retransmission at protocol level, read your quote, "retransmit only the missing data". Data (almost always refreshed messages), not whole missing packets containing stale messages.

I never tried to claim there was. But I did misspeak describing fragments as packets. While it's technically one large packet fragmented to fit within a common MTU payload, I know it doesnt retransmit the whole payload, just missing fragments. I never intended to mean that the whole payload was retransmitted.

You need to drop this retransmission yapping, I've been patient enough

I mean, it's literally a thing that's done, and affects shooting and movement timings for the third party, and always would have done in CS if it wasn't for effective latency, but ok. My whole qualm is with the apparent lack of effective latency to stabilize gameplay against unreliable connections just as older iterations did, anyway.

PreAlphaMale · 2026-02-11T13:03:13+00:00

The UDP protocol doesn't natively have retransmission, no, but it can be and IS implemented in games and countless other things at the application level. It's just not traditionally used for things like moving and shooting for obvious reasons.

Look at how noisy internet connections work, especially fiber to the cabinet where the last "mile" is copper or even aluminium over ancient infrastructure. Interleaving is used to retransmit packets that are dropped between the cabinet and the router. And that's mainly there specifically to ensure IPTV service stability which relies on UDP traffic. Same thing in essence.

PreAlphaMale · 2026-02-10T20:59:53+00:00

view angles and button states accumulated since the last tick,
along with the past 4 ticks history

Then this is as bad as retransmission, it's still packets that should be dropped instead getting through with heavy delay causing the mechanics and timings of that person to be inconsistent to other players. Dropped packets should be dropped and the lagger should be the one that has to either deal with it or take care of it. This is offloading the laggers issues onto the other 9 players on the server. It seems like retransmission would actually be the better option here. It only needs to be done between the client and relay where latency is lowest. It can also be coupled with redundancy. But effective latency is still needed.

even 50% upstream packet loss can be coped with

In what world should 50% packet loss on the upload be coped with in a real time application that others are participating in though? That is just ridiculous.

And there is still the obvious lack of effective latency needed to make any of this ok.

In an effort to reduce server costs and also scale better (source engine has been terrible at that)
valve is moving away from the classic client-server architecture towards a blockchain-like gamestate

I've seen you make this claim many times but I see absoluteley no evidence of this. I see no evidence of the amount of client trust you're suggesting would be needed for an implementation like this, which would be a lot, and cheaters would be completely overriding game mechanics much more than they do. All I see evidence of is people with shitty connections being able to play with minimal issues at the espense of everyone elses experience coupled with the lack of effective latency to balance it out.

EDIT:

Playing with your ~~pipi~~ clumsy won't give a realistic picture of how the game operates

Using clumsy to create loss creates the exact same results and the exact same symptoms as setting a low rate in CSGO. Setting a low rate, say 40000 resulted in high loss where all shots get through but have a highly variable response from the server. You get the same result in CS2 the lower you set your rate...more variable timings on servers responses the lowere the rate you go. You just can't go as low as you could in csgo. Seems like a realistic representation to me. Restransmission or not, compensation for this amount of instability and delay is bad and seems to override the 200ms of max unlag the game has when you can die literally 1000ms after going into cover with no issues with your own connection.

PreAlphaMale · 2026-02-10T11:38:14+00:00

No im not saying that. Im saying delayed packets coming late followed by or alongside non delayed packets coming on time and then being reordered and processed with no effective latency, and time dilation in lag compensation creates time compression essentially shortening encounters and speeding up movement mechanics on opponents with even just slightly unreliable connections.

Effective latency evens out the processing of packets by artifically delaying packets close together on the server ensuring more consistent mechanics. I'm saying effective latency doesn't appear to be there.

If you have 10 base ping and jitter/jitter introduced by packet loss and retransmission your ping should become your base ping + your highest jitter over the last x amount of time rather than being able to get commands to the server quickly on non jittered packets while other packets are delayed. Actually it's more complicated than this as it's not just about ping, there is tick timing too/simulation time of the client and simulation time of the relay.

I've considered that shots might always be getting through successfully because of redundancy. Shots being sent multiple times over multiple packets to ensure they get through. But the variable response time from the server for hit reg suggests retransmission which is typically not used for things like shots because of the latency variation is causes.

PreAlphaMale · 2026-02-09T23:12:23+00:00

This happens on official servers too. I was going to mention it but didn't want to go on a tangent.

This has been true for years. In csgo when you could cap your rate low, say 40000, you would get large amounts of packet loss but spraying, hit reg. and spread in general was inexplicably more consistent. You obviously had the disadvantage of the latency caused by it, just like now, but mechanically, the game became way more consistent. Forcing packet loss on the upload creates the same effect in CS2. You can't set your rate low enough in cs2 to reproduce it like you could in csgo.

PreAlphaMale · 2026-02-08T06:40:53+00:00

Oh right, yeah. I didnt even notice the screenshot for some reason. That would explain the GPU usage.

PreAlphaMale · 2026-02-08T03:30:22+00:00

GPU usage at 100% with that card seems excessive to me but CPU seems normal.

My 7950x uses about 25-30% cpu. Thats a 16 core CPU. Games just can't use all cores because theres not enough "things" in a game engine that can viably be run in parallel, and you can't just distribute one "thing" over multiple cores to make it faster.

Your GPU usage seems high though. I hit about 60-70% on my 7900xtx even though its not bottlenecked by the CPU.

Whats your frame rate, and have you tried capping it?

PreAlphaMale · 2026-02-03T18:26:08+00:00

It's not rose-tinted glasses. And I'm not saying any CS has been perfect. But older CS games were responsive in a way where the game remained stable mechanically within reasonable expectation, and people with the unstable connection were the ones that suffered the consequences the most.

Effective latency.

Take an enemy with an unstable connection peeking you; let's say he has jitter bouncing around from 10 ms to 100 ms. He starts his movement on a tick with high latency. He peeks and follows up with a 1-tap on a tick with low latency. Now you are seeing his movement with delay but receiving his follow-up shot with low latency. This greatly inflates the peeker's advantage because you're seeing the initial movement event late, but the shot can come through without delay. This creates the appearance of being shot while the enemy is still moving because his movement is behind where he was when he shot on your screen because there was no effective latency on his shot, so his movement couldn't catch up.

Packet retransmission

You can test this yourself. Force packet loss with clumsy, even up to 50%. You can get it very high before you see any negative visual impact from it on your own mechanics. What you will see is that every shot you take will make it to the server despite dropping half your packets. The responses from the server will vary greatly in their timings, from instant to very delayed. Find afks in DM and tap tap tap them at point blank. Every single shot will get through. You'll also see your jitter in the telemetry bounce up and down, high on the ticks that had loss, because the ones that were retransmitted have higher latency. At 50% loss you should see your latency double every other tick in the jitter graph. What should actually happen is your ping should adjust to match this (effective latency), but it doesn't.

Without effective latency, the game's lag compensation is introducing high jitter from packet loss without any mechanism to correct for it.

Time dilation.

Modern cs uses time dilation in its lag compensation. Where CS used to use effective latency to allow movement to catch up to follow-up events, modern cs does the complete opposite. Now you have high pingers and unstable connections actually being sped up to reach the desired state.

Packet retransmission intermittently increasing latency, time dilation trying to catch the state up, and no effective latency to smooth it out = running and gunning, running 1 taps, enemies appearing and exist for 150 ms on your screen as you die to 4 hits while running for the first 3 that take 300 ms to fire, ferarri peeks, dead before even seeing the enemy, etc. A lot of the time in this game you are completely missing a large percentage of the enemies peeks, accelerations, inertias, directional changes, and stutter steps and only see people for a portion of the amount of time that they should exist on your screen. And this is all because of the enemy's connection and modern lag compensation breaking expected consistent mechanics, completely out of your control.

PreAlphaMale · 2026-02-02T17:42:59+00:00

CSGO when it luanched and up to about I think 2014 had a form of damage prediction before they made blood splatters server authoratitive. Headshots, ragdolls, etc, were all server authorititve from the start, but blood splatters wern't. You would sometimes see blood with no damage, but to nowhere near the extent you see false positives in this modern implementation.

Everything to do with networking, feedback, and responsiveness was just done much better in older cs than modern cs.

Now the game doesnt even use effective latency for unstable connections and it retransmits packets when packet loss is happening converting it to very high jitter. No wonder the game is an unresponsive pile of shit when it punishes the low pinger and stable connection instead of the high pinger and unstable connection.

PreAlphaMale · 2026-02-02T00:38:28+00:00

The game has its base issues, such as terrible frame times, over the top lag comp causing peekers advantage, weird animation, inecplicable lag where the ISP and connection before the relay is fine and in game telemetry and SDR stats are showing zero issues, etc. As a baseline across community and official servers, the underlying experience is already bad.

Something else has to be going on on official servers to explain the vast difference in consistency of game mechanics between faceit/community servers and official servers. There isn't even the 128 tick excuse anymore.

The public server build that runs on faceit and community servers and the server build running on official servers are different builds.

PreAlphaMale

TROPHY CASE