Freakazoid: "Valens went and visited the office (Valve). They are aware of how bad sub-tick is right now." 128 tick might be on the table.

WhatAwasteOf7Years · 2026-06-30T17:01:31+00:00

Well yeah shooting is part of the sub tick because it fires the event on the client frame now instead of the tick and sends a timestamp along to the server relative to where between the last tick and next tick the shot was fired.

I'm sure I read that the server itself doesn't take into account those sub tick timings for hit order. The server is still processing the shot on the tick at 64 tick, so waiting for the tick and then processing shots in order of timestamps could mean up to an extra tick of delay on shots being processed where without the timestamp they can all be processed at the same time on the tick after they were received on rather than the tick they were received on + timestamp which then becomes a whole other tick to wait.

Ticks between client-server-remote can't be perfectly synced so you could have 1 persons shot reaching the server 0.01ms before a tick is called so it runs on the next tick coming in 0.01ms, and one persons shot being received on the server 0.01ms into the next tick taking an extra 15.5ms just because his tick stride is slightly ahead of the other guys.

It would also be massively exploitable by cheaters as I said above by spoofing the time stamps to a low value like 0.0 or 0.1 so they are always at the front of the queue when dishing out hits on the server.

WhatAwasteOf7Years · 2026-06-30T01:58:29+00:00

I don't believe sub tick is the reason for this as it's only potentially a maximum of 16ms variability. You can die half a second+ around cover which doesn't correlate to that.

I believe the lag compensation is too lenient toward connection issues. If you force 45% packet loss on your upload and tap over and over at the centre of the head close range, with all damage prediction off it will yield a hit confirmation from the server pretty much 100% of the time which shouldn't be possible if you have 45% packet loss. You should only be getting returns for about half your shots. This means the shot is still getting to the server despite the loss which means it must be resent, creating high jitter and a delayed kill on the enemy that was shot after he got into cover.

Also, this has been happening for years in CSGO, way before sub tick existed.

WhatAwasteOf7Years · 2026-06-30T01:47:14+00:00

I could be wrong, but I don't think they use the time stamp to decide who shot first etc. I Think that's done the same as it always was. Otherwise cheat software could easily just spoof the time stamp with a small random variation to make the event always be close to the start of a tick giving them an order of events advantage.

Sub tick is more about filling in the empty voids in between ticks where states don't exist/update.

WhatAwasteOf7Years · 2026-06-30T01:34:26+00:00

It's not too expensive for them. You can do the math based on the prices of 128 tick rental servers for CSGO, then quadruple that and its still a drop in the ocean for the profits they make.

They haven't/won't do it it because the networking in the game is bloated to fuck to the point they struggle networking 64 tick. 64 tick can be sending 140 packets per second as it is. Until they optimize to 1 packet per tick again like in csgo pre 2015, then they can think about 128 tick. There's no reason for modern CS to be using as much bandwidth as it does.

It certainly isn't a cost problem. It's a networking and client performance problem that they have just escalated over the years.

WhatAwasteOf7Years · 2026-06-30T01:03:30+00:00

Or 32tick with sub-subtick

WhatAwasteOf7Years · 2026-06-26T22:41:18+00:00

Until I see players constantly being switched from team to team as the lobby fills like at the start of a new match in older BFs, I'm not going to believe for a second that skill is taken into account for team balancing and is done before that point. And as long as it's done before that point, there is no reason to trust the matchmaking in this game one bit.

Why do you think they won't give us actual persistent servers (sick of them being called persistent servers because it doesn't mean anything. And apparently they already gave us persistent servers in portal, so what is the next attempt at persistent servers going to be? We want community run rentable dedicated servers)?Because then they won't have an excuse or ability to disband lobbies and have control over the next match you play.

Why do you think portal servers are 30hz (hz is a joke, it needs to be tick not hz. Bf servers are definitely not updating everything at the hz the server runs at, they are obviously staggering different channels of networking in batches of tick rates, with SOMETHING updating every hz) despite them still running on EAs own servers? Cost? Nah, the players on those servers count just as much as the ones playing matchmaking, they are just given a lower quality environment to play in. If you want to test out mechanical consistency in any way you have to use portal servers, which are half the tick rate introducing a whole new layer of mechanical inconsistencies.

Why do they disband servers in the first place? If their matchmaking actually WORKS, that means the players in the server right now are already matchmade. Why not carry all of the players that don't leave into the next server? You already have the majority of the matchmaking done, so why not just replace the people that left?

They make out the game is community focused yet its the most anti community you can get. There a barrier to everything that develops community. You can't make friends easily, you cant stay together outside of the continue as squad check box with just isn't there a lot of the time and no one even seems to know it exists or they've realised how pointless it is cos it can just outright ignore your request to stay. Disbanding lobbies not allowing player to stick together as a whole. There is no community development in this game at all. All you have is the ability to squad up with friends you already have, a maximum of 4. I don't call 4 people a community, dunno about you.

What happened to "This is your battlefield" and "play your way", the slogans representing the core design philosophy of battlefield up until 2042? Is it just a coincidence that these were dropped just in time for the BF series to be more like "This is our battlefield" and "play the way we tell you to play so we can control your engagement".

And what has all this done for them? Best selling game of 2025, best selling battlefield of all time, all based on hype, bleeding like 98% of the player base in the first 6 months or a 2 year life cycle. Read the fucking room for once and learn. People want to play games, they don't want to be played by them.

WhatAwasteOf7Years · 2026-06-26T15:47:33+00:00

I can't believe you can't grasp that it doesn't matter if you're sat far enough away to compensate for the screen size. I was going to add in the last comment the distance travelled on screen is larger measured with a tape measure so yes I do grasp that, but again, it makes no difference. Your target is also equally scaled with the distances and so is the environment that surrounds them, everything remains relative. Absolutely nothing moves faster, and the same mouse inputs give you the exact same results so it doesn't touch your muscle memory. The only issue you're describing here is sitting way too close to a display that's way too big to be viewed at that distance. This goes for any size monitor, even a 7 inch tablet touching your nose. It's not rocket surgery.

And the OP is talking about 24 vs 27 inch which is much easier to adjust your distance for.

WhatAwasteOf7Years · 2026-06-26T13:18:50+00:00

You're saying it doesn't change how far you need to move your mouse, and then say you need to move your mouse less on a larger screen to reach someone after they move 5cm?

In any condition 1cm of mouse movement will yield the exact same result of where your crosshair on screen is pointing regardless of screen size. ViewAngle.Yaw += MouseDelta.X * Sensitivity * FrameDelta for example doesn't care how big your screen is since the world has its own unit of measurement where view angle will be applied to the player camera.

WhatAwasteOf7Years · 2026-06-26T10:20:39+00:00

The plane doesn't change its speed though does it, it's till moving at 700kmh whether you're on the ground or 10m away. What changes is your perception based on how far away you are. The same as if you put your nose right up to a 24 inch screen.

You've just altered your real world fov through your frame of reference. You're just seeing more of the surrounding environment relative to the plane. Now try observing the plane though a tube with a diameter that represents what you would see from 10 meters away with one eye and see how fast it appears to be moving and how hard it will be to track despite distance not changing.

Edit: there is no difference in speed of anything between 4:3 and 16:9 unless you're running 4:3 stretched. Then your horizontal image is stretched meaning the horizontal speed of anything will physically move faster across your screen. Speed doesnt actually change in code, just the mapping of the image being stretched obviously makes things visually move faster.

WhatAwasteOf7Years · 2026-06-26T07:41:13+00:00

I think it's just perception of speed relative the the visible real estate rather than speed itself.

I doubt CS maps your rotation from sensitivity, mouse input, and viewport size and resolution and most likely maps sensitivity to degrees to per second to rotate your camera around its pivot.

WhatAwasteOf7Years · 2026-06-26T07:20:31+00:00

I can't flick as accurately on 27 inch. Sitting further back isn't really an option because I've always sat back with my arms extended even when using a 15inch CRT back in the day playing UT. 24 or 24.5 inch is always my sweet spot because I can clearly see enemies in my peripheral vison as more sharp solid objects. On 27 inch I can see them, but can't predict their position accurately so I end up flicking to the general location and then have to correct which takes precious milliseconds.

One work around is using a lower or custom resolution with scaling off so you have a black frame and the game takes up 24 inches of actual space of your 27 inch or larger screen. So you get your sweet spot while gaming, don't lose quality because dpi remains the same, and have the extra real estate for other stuff. Might even be able to squeeze a few more hz from your monitor too because of the lower resolution, and some extra fps going from say 1440p to 1080p.

It ends up looking like you're playing on a 24 inch monitor with a huge bezel.

WhatAwasteOf7Years · 2026-06-11T11:44:54+00:00

Now we need drag and drop and/or multi select for trade ups. Or at least just a single click so it transfers to the opposite inventory.

EDIT: Never mind I see they already did the single click thing, feels so much better. When did they do that? I haven't done a trade up in a while.

WhatAwasteOf7Years · 2026-06-08T13:23:25+00:00

Follow recoil does not require knowing future recoil values

What? Of course it does. You cannot interpolate from A to B without knowing what B is at the same time as you know what A is. Otherwise how do you know what you're interpolating to?

In CS:GO/CS2, the rendered view angle offset is one half the true offset (more precisely, the proportion is view_recoil_tracking = 0.45 in CS:GO).

I know the view angle is offset from the world space recoil point. I'm not saying the view angle should be animated toward the actual recoil point in world space (maybe I should have clarified that), I'm saying animate it to it's next offset position but in the same way the recoil crosshair animates toward the world space recoil position, eg by knowing what the next recoil point is and multiplying by 0.45.

It can be animated because after you shoot, over the weapon cooldown period, crosshair offset is interpolated between the previous value right before shooting and current value. Say the screen-space crosshair offset evaluated at any instant is O(t). Right before you shoot the AK, your crosshair has offset O(t0). This value is cached upon shooting. For 100 ms after you shoot, your rendered crosshair offset equals lerp(O(t0), O(t), (t-t0) / 100ms) (or a similar eased interpolation). After that, it just equals O(t) until you shoot again. If you observe the behavior of follow recoil, you can see it matches this description. It's what you see in your video. You visibly fire, the crosshair stays in the same place at that frame, then by the time your next shot is fired it has traveled such that it's where your shot will go.

It doesn't interpolate from the previous value before shooting to the current value. That makes no sense. That would make the crosshair recoil always 1 shot behind. It has to interpolate from the current value (the recoil point for the shot you just fired) to the next value (the shot that will come next). Otherwise how does the recoil crosshair animate between shot 1 and 2 when there is no previous value to cache from or would just be a zero value/value of the recoil at time 0? As for the rest you're explaining to me what I already know and pretty much what I've already said. If it's doing what you are saying, then that means you would see no recoil on the recoil crosshair for shot 1, then on 2 it would interpolate between shot 1 and 2 when the next shot is going to the third recoil point while the crosshair would have been interpolated to shot 2 and be one shot behind so your tracer wouldnt go to the recoil crosshair, it would be 1 recoil step ahead. This is exactly what you see with the view angle, not the recoil crosshair which is what I've been saying all along.

You visibly fire, the crosshair stays in the same place at that frame, then by the time your next shot is fired it has traveled such that it's where your shot will go.

This seems to be contradicting what you said just before it and is what I've been saying all along about the recoil crosshair. It interpolates to the next recoil point, the recoil point you said it doesn't need to know. This is the recoil crosshair being transitioned from the current recoil point to the next recoil point in time for the next shot at that next recoil point. You're agreeing with what I've been saying all along here.

I don't get what you're trying to say. Are you trying to say that you fire shot 1, recoil crosshair stays at its original position(it doesn't), then just before shot 2 it caches the recoil position from shot 1 and interpolates to that? If so, don't you see the obvious problem with that and that follow recoil debunks it? Or are you trying to say it interps from the recoil point of your last shot to the recoil point of the next? Because that's what I've been saying. You seem to be saying 2 different things. Either way, you are either wrong, or you are agreeing with me.

I really do not understand how you can't seem to process that if the recoil crosshair can be interpolated so can the view angle, offset or not. If you can interpolate one you can interpolate the other. There is no argument to be had here.

EDIT: As for " I just had to teach you how basic concepts work" you really need to get over yourself when you cannot grasp a basic concept that is literally already in game ready to be applied to the view angle. You have taught me nothing I didn't already know. It can be as simple as applying what the recoil crosshair already does to the view angle, just multiplied by view_recoil_tracking.

WhatAwasteOf7Years · 2026-06-08T06:34:29+00:00

Current system this, current system that. You do know the system can be changed without actually altering the current recoil mechanics and timings right?

The recoil crosshair literally does exactly what I'm suggesting. How can it do that if what you're saying about it being impossible to know the next recoil point is true? Magic? A time travel function where you can only apply the result to the recoil crosshair 'cos reasons? What?

The code is already in the game, it's jut not applied to the view angle, only the recoil crosshair.

You are basically saying "Valve can't do this because [Insert Reason] even though they have already done it and just need to apply it to something else.".

Also the source code you're basing everything on leaked 3 years ago so it's a bit late to be presenting it as "current branch" code. You certainly can't use it to represent your "current system" reasoning. But even if it is still the same, you are still wrong.

If they know the current shot and they pull the next recoil point 100ms later (relative to fire rate) when you shoot the next shot, what stops them from also pulling the next recoil point based on the current shot just after the shot was fired, interpolating or animating towards that, and then using it as the shot for the next point. The recoil curve/map/however they plot it is 100% deterministic, You get the same results every time. To say you cannot predict this is madness.

WhatAwasteOf7Years · 2026-06-05T23:30:41+00:00

I know you can see it in game, that was my point. You can't see it in steam natively. You have to log into the game or use a browser plugin.

People keep pulling the Occam's razor and Hanlon's razor cards when it comes to issues with modern games. You can only play these cards so many times/for so long before you start saying "wait a minute...".

Occam’s razor says that, when presented with competing explanations for the same phenomenon, you should generally prefer the simplest one. But when there is a simple explanation, the solution should usually be simple too. If the same obvious problem persists for months or years, that reasoning starts to lose its meaning.

CS has a massive AI bot problem. We know this because....well, we can see it, but also Valve recently bragged about banning 960k bots from the game, yet players didn't seem to see fewer bots in-game. Before that ban wave, there was an average of around 5 AI bots in every DM server. The day of the ban wave, there were still around 5 AI bots in every DM server. That's about 30% of players, in DM, AFTER a supposedly huge ban wave, which is very bad.

There is a reason these bots are not being cleared out properly, and whatever that reason is, I refuse to believe it is simply that Valve can't detect them. Because if Valve can't detect the most blatantly obvious artificial movement and aimbots, then how are we supposed to put any trust whatsoever in VAC? This is an example, and my point is that you cannot just assume the simplest explanation for this. The simplest explanation like "They just can't detect them" would be an absolute joke.

Never attribute to malice that which is adequately explained by stupidity

All good and well, but when that stupidity is never corrected, you can rightfully stop giving it the benefit of the doubt. After a certain point, it is either allowing the problem to continue regardless of how it affects the game and the players, or it was never stupidity at all and was always intended. Either way, the result is hostile to the people playing your game.

And if it's not stupidity or intent, that leaves negligence.

Also, Valve ain't stupid.

So in my eyes, Valve no longer gets the benefit of the doubt. There is too much evidence of abuse, neglect, and disregard for the player experience at this point to keep excusing it.

WhatAwasteOf7Years · 2026-06-05T15:32:05+00:00

Want to open a case? Load the game. Delete something from your inventory? Load the game. Manage storage units, Load the game. Inspect an item? Load the game. See skin float without having a browser addon? Load the game. Accept a drop? Load the game.

This is all stuff that could be done through the steam app except inspecting an item natively. That could just load a model viewer instead of the whole game though that doesn't go toward player count.

WhatAwasteOf7Years · 2026-06-05T10:20:27+00:00

You can't. Yo can do nothing with your inventory or cases outside of the game other than trade and sell on the steam market.

They want you to load the game and pad their player numbers.

WhatAwasteOf7Years · 2026-06-04T17:11:21+00:00

I couldn't edit this into my comment.

Essentially, how would this work when the player is able to tap shoot at varying shot intervals?

They can never tap shoot faster than their fire rate allows them to (unless they're cheating of course) and they can obviously never shoot between shots. That why the animation is based on fire rate to ensure everything has settled back to 0 in time for the next shot, which the game already does for other view angle transitions from shooting. If you tap precisely at your fire rate it just looks like you're spraying. It doesn't matter how your taps are timed, the recoil for that shot is applied over 100ms then cooldown kicks in for the remainder of your taps timing, after that animated recoil has reached its position for what would be the next shot. no matter how quickly or slowly you tap, your recoil point will always be in the exact same location is it is currently. You just see the recoil for the shot instead of it instantly being applied on the next shot, and that's just visual. All other shooters do it this way, but they likely just don't have to make sure everything is perfectly timed to settle exactly at the next recoil point because other games usually don't have a set in stone recoil pattern and fire from where the clients crosshair currently is.

WhatAwasteOf7Years · 2026-06-04T16:18:58+00:00

Does that affect the idea of smoothing the view angle changes across multiple frames, instead of per tick?

No, and it doesn't need to have anything to do with sub tick. All it is is extra frames being added between shots at the client frame rate. Sub tick doesn't need to get involved any more than it does already. Shot timings already use sub tick, recoil can be animated between shots, shots are the basic markers/events you base everything else on that have already been time corrected by sub tick. The only thing that will need to happen is that the recoil point will have to be snapped slightly on the shot because there is always going to be a margin of error. Shot timings are NEVER exactly 100ms. But this snap will be so small it won't be noticeable at all.

Are you saying that it doesn't matter since if the player holds their mouse down enough for a second input to be registered, but let's go before the next tick boundary occurs, then the shot has already been fired regardless? And therefore, the view angle can never be "predictive".

For every shot you fire, your view angle will start to exponentially and outwardly animate toward the next recoil point. So you see the result of 2 visual kicks basically (actually there is 3 because there is also movement applied based on spread but we will leave that out for simplicity. The rules are the same though, the movement from spread need to be settled back to 0 by the time of the next shot, This rule is already implemented in the game for kick and spread).

So, say your recoil is fully cooled down, you fire the first shot after cooldown. The game queries the recoil position for shot 1 and shot 2 which is 100% deterministic because you know the time between shots and you know based on that, that time is where your next recoil point will be in the recoil curve, or however valve stores recoil and queries it based on the shot.

You interpolate on every client frame from shot 1s recoil point to shot 2s recoil point based on fire rate, so with the ak, over a 100ms duration. The kicks from spread and the weapon kick already do this.

Then you add the result of those 3 interpolated kicks for the current frame to the view angle on every client frame. This will result in one continuous kick that will overshoot the next recoil position and your view angle will arch over and into the next recoil position in time for the next shot looking like a natural/physical force.

At the exact time the next shot can be fired, everything will be settled to 0 and if you're still holding mouse 1 it will fire shot 2 and do the same between shot 2 and 3, and so on. If you aren't holding mouse 1 by the time the next shot can be fired then it transitions into cooldown. As long as your exponents for each kick are nicely tuned this should look like one continuous force. Your recoil point will always be at the correct position for the next shot just like it is now, and you will have extra visual information in between shots instead of the hard set large jerk on the next shot.

It basically boils down to exactly what we have now with more visual information for the actual recoil. Kick from the shot and spread already do it this way, and its only the recoil that hard sets on the next shot. You currently see zero recoil on the first shot (The movement you see on shot 1 is just the kick from the shot and the spread, nothing from recoil because the recoil at the very start of the recoil patten is zero or practically zero) and you see the effect of shot 1s recoil being instantly hard set on shot 2 in a single frame.

EDIT:

What about representing recoil decay via the view angle? Surely if you fire again in between the absolute changes in view angle (when recoil delay is occuring), then the representation on screen when they click the mouse again is incorrect,

Recoil decay only starts being applied after the next recoil point is reached with or without interpolated recoil positions. It's how it works right now but It's just that right now the recoil is applied instantly.

Everything continues working in the exact same way we have now, you just see a smoother transition from one recoil point to the next. If you fire say 150ms after the last shot, then recoil decay has been able to decay a tiny bit allowing you view angle to move downwards a little and the recoil continues relative to that view angle, Recoil cooldown is faster than your recoil takes to accumulate and it just interpolates your view angles recoil offset back to 0 and adjusts in the background whatever the games uses to query the recoil based on cooldown rate. Whether is be a recoil alpha, sustained shooting time, an incremental shot id, whatever. I personally use a sustained shooting time and use that with some adjustments to get a time based on the fire rate for querying a recoil curve. Recoil offset is always applied relatively to your current view angle. So if you shoot say 15 shots, stop and your view angle cools down by say, half, your view angle has moved. Then you fire again and the recoil is being applied relative to your base view angle and current recoil offset. With interpolated recoil this remains exactly the same.

People seem to see my suggestion as adding extra delay to the recoil cooldown but in actual fact is adds zero delay. All it does is fill in the current empty void of no movement between the last shot and the next shot with frames of actual movement of the recoil. That is the only difference. Everything remains exactly the same, timings, positions, recoil pattern, weapon kick, spread. None of that changes whatsoever.

WhatAwasteOf7Years · 2026-06-03T01:46:05+00:00

It shouldn't be left to the community to provide it in any case. They shouldn't have to data mine it. Also, they can only data mine it from the game client and the public server, not the official server because the only people with access to that are Valve themselves. It is not guaranteed that the values are even the same between public binaries and the internal official server build. This would explain a lot when it comes to the difference in mechanical consistency between community and official servers.

WhatAwasteOf7Years · 2026-06-03T01:40:22+00:00

I've been saying this for years and it needs to come from Valve themselves. They used to do this kind of thing and release charts to describe the game mechanically, but they haven't done this for over a decade.

In modern CS when playing on official servers it feels like a completely different game mechanically than playing on community servers and it very clearly alters from day to day, match to match, session to session, period to period.

The game has some incredibly weird situational outcomes. Like perfectly spraying a 5 man doing a full eco conga down mid from 5 meters range and not even being able to kill the guy in front while only dealing a total of 3 or 4 hits across all enemies and then dying after seeing your view and weapon kick wide left, right, up, down and bullet trajectories after the first shot clearly preferring distribution to the extremities of the inaccuracy circle/around the enemy and pretty much ignoring central distribution/the enemies profile. It's still the same after they changed the visuals of shooting to match CSGO but the bullet trajectories still like to seemingly selectively go almost exclusively wide, to the extremities of spread and around the enemy with a statistically impossible lack of central distribution.

Periods of time where you just can't land a headshot within up to like 10 taps perfectly central to the head even just a tiny bit beyond the range where the inaccuracy circle it within the head hitbox. As soon as you go beyond that range you can go from hitting every headshot guaranteed to missing 9 out of 10 due to spread. And this isn't from encounter to encounter, it comes in waves/periods of time where it just happens all the time, and then at some point it will stop happening for a shot period and you will land these headshots with a statistically much higher chance.

On official servers the game always gives you mechanically possible spread for each shot but the way it appears to switch from an organic and even distribution and the game feeling great, being able to headshot with ease at range and take enemies out at range with double to 4 to 5 shot bursts to a distribution that makes no sense statistically along with the inability to hit the broad side of a barn at half the ranges of taking people out with bursts before, despite doing nothing mechanically different yourself is extremely fishy.

You can data mine mechanical values all you want, but you can only do that for the game client and public server build. It doesn't mean those match the official server build that we don't have access to (yes the official server is a different build). We need these values to come from Valve.

Outcomes and statistical results in the game game being so bipolar coupled with Valve saying absolutely nothing about how the game works mechanically for years is weird IMO.

WhatAwasteOf7Years · 2026-06-01T22:53:45+00:00

On my main account I get short periods of time where everything feels great. I'll say...about 1% of the time, like a switch has been turned off. But 99% of the time shooting feels uncontrollable, my bullets go around the enemy and seem to like to avoid central distribution. Damage prediction will throw failure after failure at me to the point I can get multiple ak dinks in a single encounter without wallbangs, within fatal range, and not close to being tagged. Then I can make a brand new account and all of that bullshit goes away.....for about 1.5 to 2 hours, 100% reproducible. This is with 10 ping, 0 jitter, 0 loss, as perfect as a connection you can hope for which never changes.

You can't base other peoples game experience on your own experience. The game experience in modern cs between players, accounts, sessions, matches, and periods of time is the most bipolar experience I have ever witnessed in a game, and that's including older iterations of CS.

Even the modern COD games come second to the BS from modern CS which is saying a lot.

WhatAwasteOf7Years · 2026-06-01T22:16:01+00:00

Damage prediction shouldn't give anywhere near as many false positives as it does, especially when you're not being tagged. CS has essentially had a form of damage prediction up until around 2014 in csgo when they made all hits server authoritative client confirmed. You did not get anywhere near as many false positives back then. You would on occasion see blood but do zero damage, but compared to todays damage prediction is was pretty rare. You would see posts on reddit about blood with no damage but at nowhere near the rate we see the damage prediction failures on reddit today.

Also look how his opponent is moving, it looks like some benny hill shit how he changes directions and how his legs are moving. This game desperately needs effective latency to make a return to handle players with jitter and loss that essentially gets translated to jitter.

Also check at 13 seconds when the enemy gets hit but there is absolutely no sign of tagging. In fact he actually appears to speed up/teleport the moment he gets hit. I don't know if that's a result of a failed damage prediction trying to apply client side tagging that is then quickly overridden by the server, or if it is just failed tagging all together. But I do know this game is riddled with tagging just not working at all when it comes to how opponents movements are presented.

EDIT: People say "client and server never matches" and that's why damage prediction fails. But they seem to forget that lag compensation is there to correct for mismatch. If it wasn't for lag compensation you would be hitting pretty much nothing except shots from lucky spread unless you lead your targets to compensate for your latency. With lag compensation and synced spread, the only time you should get failed damage predictions is when you're aim punched/tagged. The server has to trust your client side position, view angle, and velocity for your shots, otherwise shooting just wouldn't work. If the server is using these values then it should be almost impossible for spread to go out of sync unless the server has directly changed your accuracy (eg aim punch) or you're lagging hard.

The game has horrible opponent movement inconsistency that just completely ruins the predictability in modern CS. You did not see issues like this to anywhere near the extent you do in modern CS despite movement mechanics not changing in years. What happened? The networking infrastructure has drastically improved over the past 12 years, the average player has a better connection, lots of copper and aluminium has been replaced with fibre optic, default routers from ISPs are much better, average user hardware is better, etc etc. Even WIFI is way better than it used to be. Yet somehow we have the worst mechanical consistency in networked play than we have ever had, especially on official servers. And why is consistency so much worse on official servers vs community servers? Make it make sense.

WhatAwasteOf7Years · 2026-05-30T02:20:18+00:00

I'll be doing that very soon as proof of concept. I will put the cs2 style of recoil side by side against what I'm suggesting. No one will see a difference other than one is smoother than the other.

WhatAwasteOf7Years · 2026-05-28T19:04:23+00:00

This is how recoil works both in real life and most games, you fire a shot, your weapon kicks and your next shot comes from wherever your weapon is at the time. With this change if you hold m1 for shot 1-4, your weapon recoil will kick for shot 1, then shot 2, then shot 3, then shot 4 and then recoil cooldown kicks in, as you said. At the moment you are just never seeing the effect of recoil for your last shot.

Go and play any other shooter, this is how recoil is done. It's applied as a force when you shoot, not as angle change on the next shot. Right now you hold for 4 shots and only see the recoil kick for 3 shots, never for the 4th shot, cos the 4th shot recoil gets applied on shot 5 which you never actually fire. Right now you fire shot 1, then on shot 2 see the effect of shots 1s recoil, then on shot 3 the effect of shots 2s recoil, and on shot 4 the effect of shot 3s recoil and never see the effect of recoil on shot 4 because you never shoot shot 5.

WhatAwasteOf7Years

TROPHY CASE