I Was Wrong About The Subtick System - Update About The Last Video
2023 ж. 23 Қыр.
90 126 Рет қаралды
A few days ago, I uploaded a video, where I talk about an issue caused by the subtick system. There were a lot of things incorrect in that video, so I tried to make things clear in this one.
I'm not going to ask you for subscribe, because this is probably my last video, because I don't have anymore video ideas.
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: kzhead.info/sun/hdOakpqZkYKie3k/bejne.htmlsi=Zq4c7IGTXZ8_j7Ex
Fix: Nvidia Reflex - Off thank me later
subtick not even here yet. servers still 64.
@SNO0137 “true subtick” wont exist because theres no way the game will be able to run instantaneous updating and function well for everyone
@@nikivinn ye, the more latency the less noticeable is a variation xD
one thing id like to quickly point out is simply that the polling rate is never communicated with the server, and doesnt increase the load on it (to my knowledge), since all the server cares about is how much you moved since the last time you communicated with it. the polling rate and sensitivity calculations are all done clientside and is something pretty much every computer can handle well. glad you realized your theory was wrong and found a better answer (which i agree with mostly), its nice to see people learn new stuff
I respect anyone who is willing to falsify their own theory in public. You have earned this sub.
u sure that "falsify" is the correct word?
@@MiriadCalibrumAstar Yes, falsify as in The Falsification Principle by Karl Popper
@@fable959 ooooh, thats really interesting. Thx.
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.
i agree, great mindset hehe :)
takes a lot to say you were wrong but these videos are very high quality ! +sub
+1
+1
He got criticized over someone arguing the label of dpi and polling rate... It's so pathetically minute that the haters should be actually embarrassed for missing his point and attacking an irrelevant detail.
@@MsLibrary agreed these people criticizing cant even put a percentage of the effort this guys making on his vids
@@chivarawr Lol what does that have to do with anything. Does the fact he puts effort it his vids make him right or what? No.
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"!
why so toxic bro
@@Daniel-qy9lulol i didnt meant it toxic in any way? Im 100 percent serious. I love the video.
@@Daniel-qy9lu?
@@Daniel-qy9lu ???
@@Frozone4630 Why did you put it in quotations lol, it really does sound toxic
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.
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.
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
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.
A mouse uses relative values, meaning the change in movement per dots depending from the previous sent event. A game engine typically handles the inputs between frames and so it must compute all mouse events which occurred between the last frame. So the engine will just adds up all X and Y values of all the mouse events to compute the total movement since the last frame. The polling rate don't mean that the device actually is able or want to send data that often. It's just a value how often the host must at least ask the device for new data. Depending on the speed you moved the mouse that may even skips a few polls. Like on a 8 kHz mouse that will only send data each 125 ns if the mouse is moved very fast on a high DPI setting.
its not that simple, you can try doing it with offset time, but it wouldn't work because you can't trust local clocks/client computer's system clock(biggest issue with distributed time and event management systems), someone could write very naive cheat which abuses the system's time api/clock, whatever valve is using to calculate those exact timestamps of clicks is some mathematical trickery or hash code instead of an actual timestamp..
@@niks660097 counter strike isn't known for having good anti cheat measures precisely. They may be signing events, but those could be easily reversed anyways and could make the computations heavier making it for more expensive cost of operation for the same fluidity.
@@niks660097 I'm guessing that it does actually just send the timestamp. A cheat taking advantage of this could only change anything by at most a tick, and there are much more useful cheats that already exist.
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.
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.
tracers have been delayed since csgo times, which is why some people turn them off entirely
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.
Wow these are some AMAZING videos. Thank you!
Great videos man! keep up the quality i can see you gaining alot of followers :)
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.
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.
Because he used a long distance the angle in very small and so the error it introduces.
Top work buddy, keep on it. Even if it cant be "fixed" if we know how and why we can play around it.
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.
*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._
Big probs for doin all this Work!!
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.
Not sure if user load is making a terrible lag effect on the game, lots of rubberbanding on my end
I find when its working well, it feels great.. But then you get into these awkward fights where you and your opponent cant kill eachother.. And even though youre 100% sure your crosshair is on him, the bullets are htiting.. your tm is 100% sure too.. But then nothing is actually hitting him lmao.. Even if youre 2 feet away.. then it feels like crap
@@theSneaper Exactly that, dude stands in front of you , you make sure you aim and start shooting, but dude doesn't die and you get killed instead, it happens so many times it's annoying. Sometimes you even see blood come out, but nothing happens. They really need to fix this.
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.
I don't know but probably because of lag, He sees you on his screen before the server has updated his position and can shoot you immediately because of sub ticks.
@@rickinilsson9686 Ye thats what im sayin. It happens so fast you have no time to react what so ever.
A lot of people knows where people are potentially peeking. they just immediately shoot after peeking, potentially killing someone. a good example of this kind of spots are from T side, cat towards A site box where people usually peek. hope this explains it.
@@_tomochi nah cs2 peeking is different compared to csgo. Pros have talked about this
@@_tomochi i agree that good players do this but the peekers advantage in cs2 is too different from csgo for this to be the only explanation
You have earned a sub due to your honesty and integrity.
+sub bro ! Really appreciate your work and shared too ! Nice !
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.
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
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.
or maybe there is a reason they disabled multiple actions per key press???? that might cause the delay.
Well, if you've tried CS 1.6, it's hit registering is crystal clear! I wonder why they didn't just implement that to new CS games since it's obviously made during an era when internet speeds were super slow, and the fast paced game still had to work flawlessy. It's no surprise games during that time often had incredible technical feats made happen under the hood. "Progress" is not always progress. As computers and system comes faster, developers start to slack off since there's "no reason" to go through such a huge trouble implementing lightning fast code... since it doesn't need to be that fast anymore, fast hardware compensates!... I'm a C++ developer myself so I kinda know what I'm talking about. :o)
lmao@@tonikauko
I think it'll get better, even just a bit we just have to let valve take the time and figure out the deeper desync issues between players, animations and such.
I mean we have been playing the same game for over 10 years and gotten used to it obviously its gonna be different. I personally don't notice this at all and i have 2.3k hrs lol... maybe because im focusing on the fact im still bad :D
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
he's already controlled those things by using CSGO as the control, which is subject to all the same factors you've mentioned.
@masdog Is it known whether things outside of base tickrate, polling rate, and mouse latency affect registering commands?
@@byucatch22 not necessarily, cs:go and cs2 may both be different aswell as the inability to compare results from one client to another
@@magnov983 well, since the command was bound to a key, the keyboards input delays as well as network latency would change results
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 :)
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."
amazing video. Keep going. +1 sub
You could use the cl_showfps 3 command , it might help determine if the tickrate matches up with the pixel travel theory
"Kalkulačka🇨🇿" Btw, dobré video, už vím trochu jak valve hry fungujou :)
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.
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)
cheatin woould become a problem no?
The client is also tick-based
You got to remember that anything client-sided is prone to be altered by cheaters.
@@M0n4rc making animations for firing client side wouldnt allow any more for cheating than the game already does?
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.
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".
Just as a disclaimer. For your theory to still be true we have to see a sigma of at least 50, meaning there should be alot of variance in your data. I think you can calculate the standard deviation in excel using STDEVP(C4:C104).
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.
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.
It's so obvious when someone is trying to convince themself of something that isn't true in order to feel a way they want to feel. ;)
@@MsLibrary You living in some bum fuck location with shitty internet doesn't mean its the game. I'm in the US, all my friends are in the US, we all have no complaints about the netcode. You seeing edge cases on youtube doesn't mean the system is bad as a whole. Its so sad when you see someone so desperate to be negative and critical about everything all the time. SAD!
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
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.
that was a top gear ending i liked that
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.
ngl i dont think you were wrong, there is something weir with the awp/scout
FOR REAL. They are actually unplayable. Extremely noticeable in deathmatch
YES! During beta i played a few games in csgo and a few in cs2 and my awp flicks felt completely random in cs2. If in csgo i could consistently flick to the same spot, in cs2 - it felt like I could never get the right flick consistently
ong.
@@koala.justakoala4287 You could also shoot straight .
@@crouchjump5787 well it's just a workaround.
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 ?
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
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
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.
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.
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?
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
Take us back to the old tick system but give us 128tick
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.
It doesn't do that. Source 2 is tick-based both server and client side.
@@eldafint yes it is tick based but still client waits till server registers shot to show shooting animation.
@@Jonsson95 Do have an actual source on that?
@@eldafint kzhead.info/sun/lKhyeZeRe2WNrKs/bejne.htmlsi=ICbZhgMZ-P8mXAi0
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.
That’s what I meant to say in the video. I probably worded it badly.
So from a user perspective it's still random, no?
@0sac it always will be because no one has an internal “sense” of when to fire right before a tick registers
@@magnov983 Yeah i've rewatched the video and understand now, it's defo an animation issue as far as I can tell. CSGO was defo more random relating to when your shot fires, but weirdly, i'd prefer that to an animation delay
essentially, yes, but the randomness is whether or not the animation plays at the right time. In CSGO the randomness is whether or not the hit actually registers. It just moves the randomness out of the shooting equation and into the animation instead.
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
Nice and clean
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.
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?
if that is the case, wouldnt it be reasonable to assume that a shot cannot occur more than 21 and a half pixels behind the crosshair? for him to have a mix of both very far back and very close shots with the same setup, it seems like the distance to the next tick probably isnt the issue. Maybe we would see different results if there was a way to fire right when a tick starts, but with subtick, that might be impossible to replicate.
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
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
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.
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.
I see here a man of science, game science
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?
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.
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.
I know my aim isn't fantastic by any stretch of the imagination but there appears to be a serious problem with hit reg in this game. Many times sprays are landing quite clearly for zero damage, even when blood and dinks happen.
It's because the animation and actual shots aren't synced and can be up to 16 ms apart due sub-tick.
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).
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.
how does the shoot where you click work for cs2 with revolvers?
I have learned to put my aimer just left of the opponents and my shots finally are hitting like they did in csgo
hey whats res u playing and crosshair?
farther shots have larger spread. Even the silenced USP is not pixel perfect to the exact center of the crosshair at long distance.
maybe your theory was wrong but that was a good video with good edits
0:32 "if you replace DPI for polling rate, it should still make sense" That's interesting because they are entirely unrelated, and the idea they are somehow interchangeable is a red flag of bad data.
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.
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.
A true hero , worried about the truth
This video is me trying to explain that’s I’m not bad, the games bad
great work mam
Insta subbed. trust you bro ❤
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.
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.
nice vid man respect
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.
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.
Nice top gear reference!
I wanted to run the top-gear outro music in the end, but it felt way too weird
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.
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
@@dubaibank ignore the animations. i get what you mean by the feel, and have to block it out mentally lol
tak to bude teda lepšie :D
Your aim is so crisp
I think players should be able to kill each other. It's really frustrating that in csgo I popped someone in the head with a the xm only for the game not to register the hit at all. And this is still happening in cs2 as well.
Csgo felt very accurate, almost 100% of the time you could figure out why a shot missed, whether you were moving or bad spray or whatever. The desync between what you see and what the server thinks in CS2 due to subtick makes the game feel much more random than GO did. I didn't play GO when it released, but man I sure hope they figure out how to make subtick work well, because right now it feels terrible
Dobra praca!
Subbed because of mistake admission, and a lot of effort on objectivity. Rare these days.
But does cs2 still suck or is it good now?
how do the results vary on a 128 tick server would be very interested :P
64 tick is hardcoded into cs2, meaning that you cannot try any other tickrate.
in cs 2 i managed to hit a qkly from t side mid onto a guy siting in short with a jump ak shot 2 times in 1 game and it felt noice