As said in the video, I wanted to make a video about why there probably isn't any fix to the firing animation delay. But @MrMaxim already made a great video explaining the exact thing, so there is no reason for me to make the same video. MrMaxim's video: kzfaq.info/get/bejne/iNWRlZmSv7bQeHU.htmlsi=Zq4c7IGTXZ8_j7Ex

I respect anyone who is willing to falsify their own theory in public. You have earned this sub.

Because you have open mind and are capable to admit to your mistakes you get my sub and like. We need more creators like you.

takes a lot to say you were wrong but these videos are very high quality ! +sub

We all become Scientists when it comes to the Counter Strike Tickrate, but when we are in school we don't care about math, physics and the rest.Thank you for putting so much effort in this "Experiment"!

I didn't see your original video, and I could only watch this one up until 0:26 (I'm a software engineer and the "processing inputs relative to dpi" comment has me too close to a brain aneurism, so I will stop there for my own safety). However, I wanted to say that I absolutely admire and appreciate this video for being an effort to sincerely correct yourself and learn. Getting things wrong and then being open to confront and recognize it is not only how we learn, it is how humanity achieves greatness. But it is difficult and scary to do, especially in public forums (like youtube). Good work. Also, if you're not an engineer already, then you absolutely should be one. Knowing the specifics about some piece of hardware, and how its input might get processed, isn't what's important. What's important is being able to think. And it only took 26 seconds to demonstrate that you know how to think. Please continue doing so.

The way you edit these is so good and profesional, also you explain and go deep into details about stuff you say. I felt like i was watching a profesional youtuber video or smth. Keep up with the uploads man.

Here's my take on this: Valve explained during cs2 launch how the subtick system works. The servers still run at 64/128 ticks, your game still polls it at that rate, and both the client and server send updates at 64/128 ticks. Every single update still operates at the same tickrate. However now, alongside the actions triggered by the user during that tick, they now send an offset time pinpointing the exact moment each event occurred. This means if you and your enemy shoot at the same tick, the update with the smaller offset wins the duel, as per Valve's explanation. Given that understanding of the subtick system, here's what I think is happening: In CS:GO, with just one tick without offset, you could only "+shoot" or "+moveleft" once per tick. I think they replicated this by allowing only one kind of action to be registered per tick. But the mouse position is a different story. As mentioned in your previous video, modern mice update their position 1000 times a second. So, sending only the beginning or end mouse position for each tick would be insufficient. Instead, they probably send the path the mouse took during that tick. This means the server receives information on all your actions, when you did them during the tick, and the path your mouse traveled during the tick. This way, they can determine the bullet's direction. Now, the possible bug explanation: Perhaps the "+shoot" animation happens at the tick's end when the event is registered on the server, but the bullet still goes to its intended position based on the registered path and tick offset. Maybe "-right" is sent either at the start of the next tick or at the end of the current one. It's also possible that not all actions have a subtick offset in the update, leading to these inconsistencies. There might be misalignment between the offsets for mouse events and "+shoot" events. Or maybe, they need to determine the bullet's position when the "+shoot" event occurred at an offset position between two mouse subtick updates. This could also account for the inconsistencies observed in larger test data. Depending on how deep into the tick the action is triggered, the resulting distance varies. Also with the old system, you unconsciously click to shoot when your crosshair is almost hitting the enemy, but not doing it already, because you have unconsciously adapted to this game behavior and subconsciously know the bullet will go to the position your mouse will be when the tick ends. So to people with thousands of hours to csgo, this feel awkward and out of place, because this is not the behavior they have been subconsciously adapted to.

please keep us updated on this after every patch

I watched the previous video and was like, cool stuff, but after that, I subscribed because testing and proving oneself wrong is really high quality. Looking forward to your future tests

For me, subtick feels pretty good most of the time, my major problem is spraying. I really think they need to focus on making tracers align with where the bullets are actually going, or disable them entirely; I know the spray patterns, but when I'm stressing in an intense gunfight, and I see my tracers missing left, I instantly pull right; But I'm not actually missing left, that's just what the tracers show. I unironically started using follow recoil because I may miss 2-3 kills per game due to my crosshair jumping on pistol round or something similar, but I'll lose 5-10 gunfights due to bad spraying because of the inaccurate tracers.

My best idea for the range of difference in the new test you did would be that shooting from that long of a range assumes that the guns have perfect first shot accuracy. Even when standing still, your shots never actually go perfectly straight, even with the AK which has really good first shot accuracy, across such a long distance a shot even 1° off center will add up to a large margin.

If you watch the videos about the delay of shooting in cs2, it oscillates between 7-9ms and 20-23ms, which would explain this perfectly. This is probably due to the "distance" between the shot registered and distance to the next tick, however, Im not quite sure why is it usually one of these two values. It should actually variate between 7-23ms with enough samples. But as the animation comes after the shot being registered and the input lag is 7-9ms and 20-23ms, this would also explain the randomness that the crosshair travels after the shot.

Small thing i noticed. When calculating the distance between the shot and the cursor you should be using a cylindrical map with the centre being the head of the player as this is where the camera is placed as well as where the rays for the shots r calculated in cs. This probably doesnt change ur results much but will be more accurate as when shooting the flat wall at pit the further from the area on the wall where u are aligned, the more the distance will be exaggerated. This should help you determine y the distance between the shot and the cursor appears random which is likely to do with how long before a tick the firing input was made. If you tried to calculate this without doing it on a cylindrical map u may get a value that is more than a tick which would likely incorrectly sway ur results.

Great videos man! keep up the quality i can see you gaining alot of followers :)

Can you investigate how people can peek and immediately kill you, The games feels like they peek and shoot, before you can even see them, Its so hard to hold angles now.

In the subtick system, it turns out that pressing the shot button is recorded immediately, but the animation of the shot and the shot itself waits until the server tick is triggered, the server simply receives information about your sight at the moment you press the button, and when the tick is triggered, the bullet flies out exactly where it was at that time. the moment the sight was aimed when you pressed the shot button, and it turns out that if the moment of the shot and the server tick do not match, the shot animation is triggered at the moment of the server tick, and the bullet flies to the place where your sight was aimed at the moment of click mouse.

cs:go and closed beta cs2 felt really similar to me, but the second they fully released cs2 it became unplayably bad and I still can't find why. Nothing feels responsive and the game makes me more upset to play than it excites me.

I appreciate yours approach with taking responsibility for yours work. As the other said it takes courage to say I was wrong. Keep up good job.

*There are still some misunderstandings...* - The polling rate only means how often the host must ask the device at least for new data, this don't necessarily mean that the device actually (can) provide new data. The host is even free to poll the device more frequently than the polling rate which the device announce to the system. So if the scan rate of the device can't keep up with the polling rate that is basically useless. _Like a very high polling rate for a keyboard which use traditional contact based switches which have a debounce time of around 5 milliseconds is basically marketing snake oil._ - As far as I know mouses typically don't provide data each poll even if the sensor can do it. It can be that a poll or more is skipped on purpose. The relative movement data is send in whole numbers, if there aren't enough dots registered the error compared to the real movement would be high. Likely due to this you need to use a high DPI setting to utilize a high polling rate of a modern mouse. - The differences on the distances between the two videos may can be explained due to the changed binding. It can be that due to the sub-tick handling the two actions (stop & shooting) aren't handled simultaneously and so that the order matters a lot or more. So that the weapon spreading of the gun is greater when fired while still moving which isn't the case anymore in this video. - It's not just the tick rate of the server but also your FPS. The game engine will handle inputs and the current map state from the server between frames. Because these are not synchronized higher FPS should help to make it more consistent. - I don't know how the sub-tick thing actually works. From the Valve introduction video it appears that the inputs / actions aren't handled in discrete time slots anymore which is bond to the update rate of the map state but instead computed in a continuous manner depending on the exact time they happened. But I doubt that. I assume the computation still happens in fixed time slots but multiple updates are sent together and older ones are computed like they occurred some slots earlier. Like the client still works in discrete ways due to the input handling between FPS. So I assume to save computation the engine will currently still handle updates in discrete ticks which are just higher than the actual update rate of the server. - To me the data of the pixel distances shows discrete blocks. I assume there is a deviation due to simulated spreading of the gun while the distance should shift within discrete distances according to the discrete tick rate. So I would conclude from the data that if the shot happened within the same tick the values are 2 - 5, but if it happened one tick later the values are 20 - 24 and so 19 pixels apart. There are only a few outliers and which can be maybe explained due to rare extreme of the spreading. *So I recommend to do cross checks.* - Check if the order of the bindings matter and so changes the data. - Test with different capped FPS values, like half, the same, doubled FPS of the tick rate and with unlocked FPS. - Add a delay between stopping the turning and shooting to see how the spreading behaves depending on the delay. - Test when connected to an external server and when the game client itself is the server. _Possible that if the game client itself is the server, that the tick rate can be synchronized to the FPS if these are capped even if that is handled in a separate thread._

Wow these are some AMAZING videos. Thank you!

Top work buddy, keep on it. Even if it cant be "fixed" if we know how and why we can play around it.

I feel that to further reduce the randomness of the results with your tests, things like fps, ping, and input latency need to be controlled. since you’ve addressed the input latency from the macros should not matter if it’s consistent between all your tests. it only gets messy when comparing your results to others. fps and ping also would affect latency, making results more incomparable to others. overall it’s a difficult one to test

seems like a feature they added for inertia with the weapon sway being the opposite of where you're swinging your weapon just without a visual effect for your gun to measure the resistance.

You can actually see the "subtick" accuracy in action in Paint as a basic example of why flicking feels weird now. Open up Paint, perform a fake "flick shot" and look at the outcome. You won't see a dot... you'll see a line. The start of the line is close to what subtick will recognise, with the end of the line being where your crosshair ended up. CSGO was the opposite. It would effectively register the end of the line do to the event being tied to the next tick.

Netcode is always going to come with compromises, the question is what kind of weirdness do players prefer, something that _feels_ responsive but can look a little weird, or something that looks and feels weird but is technically more accurate. The subtick system is hard to argue with since the pixels you hit are correct every time, but... it doesn't feel good, and i guess we'll see if that's something players can get used to or if it gets more annoying over time, or of course if Valve can improve it.

You have earned a sub due to your honesty and integrity.

that was a top gear ending i liked that

Man, I don't know if you are a academic researcher IRL, but this video would be a great example of what an academic researcher should act and be like. Good video and you got a new sub :)

It seems like the position the bullet goes is less based on the time of the click, but rather the position during the previous frame. So the bullet timing is kinda capped by whatever your framerate is, but subtick just kakes it so that the timing is always based on the frame rendered during the click rather than ehat tick you are on. Other than that, the better the framerate the more responsive your shot will be.

You could use the cl_showfps 3 command , it might help determine if the tickrate matches up with the pixel travel theory

It is pretty simple - your input gets processed at the next available tick, intervals between which are constant (16.6ms or 1000ms/60). Depending on when you shoot in relation to that tick, it will get synced with the server sooner or later, so for example if you shoot 0.1 ms after the last tick, your crosshair will travel further away, while if you shoot 16ms after the last tick, the distance will be much shorter

the video by qkNorris called "deep-diving CS2 mouse input problems" mentions that the position of the crosshair is calculated from the previous frame in CS2 and from the next frame in CS2 this is why you see the difference of where the crosshair stopped vs where the bullet landed

Big probs for doin all this Work!!

I saw someone investigate this a bit further and it seems that not only is the game taking your input from the last tick, but it's also taking it from the previous frame on that tick. So for example, let's say your getting 64 frames per second. (makes the explination easy) And then let's say you shoot on frame 3,which is also tick 3. It take your mouse position data from frame 2 instead. Making it all kinds of weird.

+sub bro ! Really appreciate your work and shared too ! Nice !

The only way to fix this, is to make the animation client side, but this comes with a side effect, your gun in your view, will always fire before the enemy does, so it will feel like you shot, but you did not, atleast not for the server, there will always be this de-sync, it's either this or the old tick system

Great video fun to see people taking a experimental perspective! In the video you say that since the average is 11.41 and we expect 21.56 your theory is proven wrong. In statistics usually one would calculate a confidence interval for the mean 11.41 to reach such a conclusion. This is done by first calculating the sample standard deviation (sigma) which is given by: sigma = sqrt( (1/N) * sum_{i=1}^N (X_i - 11.41)^2 ) Here N is the number points in you data and X_i is the pixel distance for measurement number i. Now you can calculate a confidence interval, lets use a 95% confidence interval: a = 11.41 - 1.96 * sigma/sqrt(N) b = 11.41 + 1.96 * sigma/sqrt(N) The value 1.96 comes from the fact that we are using a 95% confidence interval. The confidence interval interval is now given by (a,b), if 21.56 lies inside this interval we can not say for sure that you theory is wrong, if 21.56 is outside this interval we would say that you theory is less likely to be true. A 95% confidence interval means that if the experiment was repeated 100 times, we will expect that in 5 out of these 100 experiments the value 21.56 lies outside the confidence interval even though your theory is true. This is why statisticians do not say "you theory is proven wrong" but instead says "you theory is less likely to be true".

ngl i dont think you were wrong, there is something weir with the awp/scout

amazing video. Keep going. +1 sub

After actually trying cs2 out shooting feels SO MUCH better

Scientific Thinking, Being willing to accept you were wrong and a top gear reference tto end it. You earned my Sub

My theory is Valve made the sub tickrate system by coping the scene from the movie The Waterboy. "The tickrate delay is a fake. It fakes to the right. No. It fakes to the left. No. It doesn't fake. It thinks about faking. It pretends to fake... I don't know where I am. I can't breathe. The room is getting smaller I have to sit down."

"Kalkulačka🇨🇿" Btw, dobré video, už vím trochu jak valve hry fungujou :)

But why does the shooting animation be server sided can't they just let shooting/ weapon -animation be on the client. We send the Shot with Subtick to the Server so client and the server registerd the shot almost at the same time. Can't we just get the shooting -animation on client side exactly at the same time we shot and the server registered so it wont feel delayed and weird ? Or am i missing somehting here... Is this even possibel if someone gets what i mean what do you think ?

My only guess is that perspective matters. The longer the line between you and the wall you shoot, the more deviation there will be. You have to shoot at the exact pixel to get actual data.

The question is, why cant shooting animations be client side? This would allow for the animations to better match the subtick systems accuracy would it not? Because your gun would shoot the moment you clicked, and at the moment of the next tick your bullet would hit where you click and where the animation fired.

just to add one more point, now for awp flickshots to work, awpers will need to shoot after the enemybox has either passed or atleast 80-90% passed from your crosshair, instead of flicking your wrist and shooting first, also flick shots accuracy will depend on your internet connection also.

When u use both commands same time at same bind it would not be subticked, just based on 64 tick. Does it work same for loading config like you do?

Its possible it felt bad before official release, but I have to say playing it after release its been mostly excellent. I notice way more consistency when shooting moving enemies, headshot sound/kill feed is instant where in CSGO it was delayed, and just overall it feels great for the most part. I will say though you do get those moments where you die behind cover sometimes, and peekers advantage is crazy good. If Valve did 128 tick + the new sub tick system I think we might have a perfect online experience that might feel very very close to a LAN game, but they seem set on this which still is better than most multiplayer games.

Ayo bro you never claimed to be 100% right so chill. I understood the problem thanks to you and two more such videos on youtube, the problem is very simple, animation vs tick, its a backend vs frontend issue, all the sub issues emerging from it, should be left as they are because focusing on the is a moot point and a waste of time.

I know this was long ago but taking in that mistakes was made and correcting it deserves a sub from me. (I also thought i was watching a 10k+ sub youtuber xD)

I see here a man of science, game science

I think the issue is probably plain old lag... You turn, then fire while you're turning, but the fire instruction does not arrive at the same time as the turning instructions, so it fires at an earlier position. This was an issue in csgo but was much harder to do since you would have to send your turning and fire inputs at the same time yet have them recorded on two different ticks, and the difference would be so tiny it would be barely noticeable

What if its because of how CS2/CSGO processes the binds? Can you compare CS2 and CSGO using the macro? I could definitely see CS2 processing binds more like a stack/one at a time if they're using subticks and CSGO literally bulk processing binds and marking them all with the same timestamp.

If I understand correctly, the distance aren't random, but depend on how far away the next tick is after firing. If you check the longest distances, maybe you'll see the 64tick delay in it?

how does the shoot where you click work for cs2 with revolvers?

There is a big inconsistency in the video, from experience I saw that sometimes it is possible to kill the enemy before you come out of the corner, that is, if I know the location of the enemy behind the wall, I strafe to the side and shoot at the enemy without leaving the wall yet and without seeing the enemy, I kill him and the kill is counted without shooting through the wall, although in fact I was shooting at the wall and there was a wall on my sight at the time of the shot

Do we even have information if this is a potential sync problem instead of intentional change by Valve? I mean, it wouldn't be that far fetched to assume that Valve would intentionally apply jitter to your shots for a short time after movement, similar to how your crosshair gets less accurate while you're running. Because you cannot accurately rapidly move your gun and shoot with pinpoint accuracy, it would make sense to emulate this in software, too.

its happening because while subtick registers your mouse click at the exact moment you clicked and sends it to the server, it has to wait until the next tick arrives (yeah servers still run at 64 tick) and server confirms that the shot was made. because the other person you shot may have shot you before you click. if this confirmation was removed, you would see that the animation happens and player gets killed then the next tick arrives and server denies your click request because other player clicked before you did and all of a sudden you die even when it looks like the other person should

nice vid man respect

Nice and clean

Delayed animation can be fixed by not waiting for server to tell client to show animation. Just show animation when player shoots. Yes sometimes animation is shown but player was already dead. That is way better option than showing delayed animations which mess up players aim.

I have learned to put my aimer just left of the opponents and my shots finally are hitting like they did in csgo

As I stated again and again, if they would change the fire automation to be client sided there would be 0 issues. The bullet is synced to the closest tick (that's why there is a difference in the distance)

Good video.. The problem is not anything with CS 2. The problem has been there since source release. The problem is that not everyone have this problem or dont see it. You get the problem within time. No one has found a fix to this despite many have tryed so hard and alomost everything. Its also making keyboard a mouse going wierd and I did hope that they would fix it in CS 2 but I tryed it yesterday and it wasnt. I alteady stopped playing it until they fix it. GL

The difference in distance should be a function of the time until the next tick. So if your macro fires 8ms before the next tick it will be half the difference of when it fires 16ms beforehand (just after previous tick). If you could get this to run predictably at multiples of 16ms the distance might actually start to look consistent, reproving your theory.

shot is processed by server before animation. they separated these actions it seems.

One important part you missed is the game client update rate (FPS). If your game client is running at e.g. 150 FPS, this means your game will update 150 times per second. For each game tick, the game will poll inputs from the operating system and this is what usually decides how often your inputs will register, not the DPI or refresh rate. With an FPS of 150, the game will register your mouse movements 150 times per second. It's only in the case you have a FPS higher than your mouse refresh rate that the refresh rate will be the limit. E.g if your FPS were 1000 and your refresh rate 500, the game would read the exact same mouse positions 2 frames in a row. Each tick on the game client is also when the game runs all the logic and updates calculations, and is when the game can decide to send a subtick update (by requesting the OS to send out packets to the network).

I think this has something to do with floating point accuracy. Basically it should be caused by rounding error for the time stamps of the inputs, because other wise the lines of code should be executed at the speed your game is running, which is quite consistent, so the distance travelled will be varied by a small margin(the fluctuation of fps depends on the specs of the device ofc.) Rounding error also explains the 'grouped' behaviour of your data. And to my knowledge, unless packet loss is detected the recording of your inputs and animations wont cease, meaning that the animations wont wait for the server to respond, it is purely client sided unless you have really bad internet.

So I used to that this was the cause of all the shots that we'd see hit that would be off characters and shots miss that are on characters. Now I'm starting to just believe the subtick adds just enough data to process that counters trike is now receiving Escape from Tarkov levels of desync.

they are not random, it just depends if the moment you click is close or far away to the next tick. if you shoot right after the previous tick, the game will wait a long time until the next tick to display the shooting animation, and you get a larger distance/time. if you shoot directly before the tick, the game doesn't have to wait very long until display the animation, and you get a short distance/time. it just matters when you happen to be firing and if it lines up with the tickrate or not.

I personally think it has something to do with moving. With this experiment you are standing still. I feel like it’s a gamble so I just go smg so I can prioritize my movement and spread while moving. I think sub machine guns are meta. I run it with a deagle for long headshots.

Insta subbed. trust you bro ❤

Dobra praca!

There has been a discovery tripp made a video on how making an alias for moving and shooting fixes the problems we have with them right now a tweet by poggu explains that alias locks moving and shooting to the tickrate breaking the timestamp code for subtick. There have also been a lot of ppl complaining about stutters and big fps drops, if the fps somehow affects the way timestamps for the subtick stystem works it could explain why your test are inconsistent and also why right now everything feels so shit and random. We could test this in a number of ways but ill let you decide the method. ps. Dont forget to email valve if you find anything

Hello, game dev here. Just to make sure it gets mentioned: Everything gets sent on ticks, but with the sub-tick system it stores the timestamp, position, etc so that it can be sent on the next tick. With CS:GO it just registers that you shot and then sends the current position, that you shot, etc on the next tick, so what is on your crosshair and what the game sends to the server on the next tick may not match. Also, fun fact, when you see other players smoothly move it isn't their actual exact location, the game is just interpolating between the last and current tick. So in my opinion, people who are complaining about aiming in CS2 have just gotten used to the slight delay which is no longer there.

2 problems i see here 1) did you remove the weapon inaccuracy? 2) do you know that bullet holes decals are different between client side and server side so what you see is not what actually happens?

I tnink the only reason why it is what it is, is that ping of serwer and client beetwen in the same time, when did the action of clicks mouse and clicks keys in game.

Animations could be fixed if just made client-sided. You see them real time ( for your brain and for your spray sake), subticks still kills behind wall (unavoidable). Opponent sees you firing when the tick is updated.

farther shots have larger spread. Even the silenced USP is not pixel perfect to the exact center of the crosshair at long distance.

if its any consolation, your last video had me thinking: "so cs2 is actually more accurate, and the tickless server is actually doing its job.". based on what you said and i what i know already though lol

as far as i know .cfg are executed in a single frame unless "wait" is used so +attack and -moveright are done localy in the same frame.

This is likely due to your fps. Shots are registered on the previous frame in cs2. Your fps is on average say ~250fps? With 46 pixels per 1/60 seconds you have about 11 pixels per frame which matches pretty well with your data? This probably doesn't explain everything that's going on but locking your fps at 64 could produce some eye opening results.

hey whats res u playing and crosshair?

tak to bude teda lepšie :D

maybe your theory was wrong but that was a good video with good edits

Unpopular opinion: I really like this. I have played a lot of shooters in my life and the first time I tried CSGO it felt weird, none of my shots landed por some reason, that's why I chose Valorant. Then I tried CS2 and felt a lot different, finally I was hitting my shots, a whole difference. CS2 for sure is one of my preferred shooters nowadays. I know people were used to the old game, but if the game rewards reaction time and accuracy rather than were your cross-air was at the end of the tick, a lot of new players will find this game fun.

The reason your bullet to crosshair distance isn't constant is because it depends on when you shoot. The 64 tickrate means the game state is updated every 16 milliseconds so if you shoot at the exact end of the tick your shot is registered and then your gun animation would start 16 milliseconds later. But if you shoot 8 milliseconds after the last tick your shot would be registered and the gun animation would play 8 milliseconds later.

great work mam

Same thing I felt in OW2. Still feels off compared to OW. Used to play CS back in the day, and I can see why this is a bother.

how do the results vary on a 128 tick server would be very interested :P

Subbed because of mistake admission, and a lot of effort on objectivity. Rare these days.

How is the expected value of a uniform distribution the maximum value of that distribution??? if the delays range from 0-100% of the period of 1 tick, and this distribution is uniform, then the expected value should be 50%. Which means that the average distance your crosshair travels beyond the bullet should be half of the distance your crosshair should travel in 1 tick (since distance scales linearly with time). With the experimental results, I would say your theory might be correct.

A true hero , worried about the truth

Can you check how it was in CS 1.6? I think CS2 is more like 1.6 than GO.

Ale zdravíčkoo

This video is me trying to explain that’s I’m not bad, the games bad

can you give me your sens setting

Nice top gear reference!