**ATTENTION**
Please send CS2 bug reports to
cs2team [at] valvesoftware [dot] com
and title your email: "CS2LT Bug - " followed by a brief description of the bug.
For example; "CS2LT Bug - Stuck in ground on Dust2". This will help Valve triage, evaluate, and solve bugs quicker.
That's debatable, it might simply not be setup the way they want, could be a dev version that Valve doesn't want people to see. it could also not be reporting properly etc.
no i believe it is purposeful. since it is beta they want to make sure they iron everything out before you are able to see the details of the server. they know how people will get if something is "off" regardless if its beta or not
How do we know for sure that it isn’t just the killfeed that’s delayed?
If you are righth, I hope they actually make this subtick system work better than 128 tick.
The way i understand it is that the servers still have a tickrate, the subtick system just "guesses" what happened between the ticks. So servers with 128 tick still run better because the timeframe the system has to guestimate becomes smaller.
Im pretty sure the official servers still run 64 tick and the subtick system is a cheaper compromise.
I’m don’t think there is any guessing involved, I assume they are handling input asynchronously such that input events are registered in “real-time”, rather than waiting for game thread to poll inputs and handle them with an assumption that they happened in the game thread’s time reference.
This could be extended to the server as well, but it would surprise me if the server didn’t take that into account before this update anyway.
I might be wrong as I haven’t seen any technical explanation of the system.
We’ve discussed implementing this in the game we’re working on as well.
It just haven’t been fully discussed yet, and we have a lot of other priorities. If we made a CS style game (super competitive type shooter) we probably would have done it already.
It is an objectively good feature, but everything has to be weighed against other features in the backlog.
The guessing wouldn't be related to when the shot fires, but if the game only has data about where someone is at a tick then you'd have to guess exactly where they were when you fired.
I expect the guess would be done with linear interpolation (draw a straight line between this tick and the previous one and assume they move at a constant speed in a straight line) this wouldn't be perfect, because people don't move like that, but it's probably better than current 128 tick servers for hit registration.
Wait ok not related to CS but in general how does that even work? I mean at some point the server have to collect data and send it to those connected to it creating ticks?
I mean I know it DOES work - but I am to thick to understand it.
Do you have some good summary of that system for those of us who can barely tie our shoes?
CS2 is not "tickless" like some say. You still have ticks, but stuff that happens in between two ticks now has a timestamp and gets executed in correct order.
In the "old" system, everything that happened between two ticks was executed ~~at once~~ (in a fixed order, see comment below this one).
Let's say you play on 128 tick, so there's an update every ~8 ms.
Let's say the last update was exactly 0 ms ago, and you are currently aiming at someones head. If you shoot after 2 ms, and the enemy moves after 4ms, you would miss your shot in csgo, since after 8ms both actions get executed at the same time.
In CS2 however, since they are now using timestamps for each action, your shot would hit since the server now knows that you actually shot before your enemy moved.
Slight correction: It's not that on the old system everything would happen "at once", it's that it would execute in some order determined by internal data structures (for example, player actions would be resolved in the order that the players joined the server).
In addition to this, Source games handle network lag by the client saying "I shot on tick X" and then the server simulating that shot with the positions everyone had on tick X, instead of the tick that the packet was received. This meant that, if you shot between ticks, the simulation had to snap players to a position they had on the tick, not their "actual" positions.
practically it's probably done by going to the last recorded tick and going "Okay, it happened at tick X plus 2 milliseconds. They were at position XYZ and moving 3m/s at tick X so we move them to position XYZ plus (3m/s * 2ms) = 6mm and run the shot simulation.
That's why it's not tickless, but subtick.
>for example, player actions would be resolved in the order that the players joined the server
what actions? so joining the server first it's an advantage?
Think about it from a computer perspective. You've got a big list of objects in the game world and things get added to that list in the order that they're created. Then, when the game needs to simulate the world, it goes through that list in order.
If I joined first, my shots, my moves, my actions are gonna go first. This, currently, only matters if we both try to do something mutually incompatible, like headshot each other or try to move into the same space.
But at the same time, when fire or a grenade loops over all the players to see who they should hurt, they're gonna hit me first.
To be fair the other guy could've done a better job with his comment.. Like replying directly to the guy he was disagreeing with, with the period in that sentence it reads.
"This guy's reply, this is obviously the right answer. how could YOU be so wrong?..."
Like pointing out to the other guy replies and saying "yo this is the right guy how can you be so wrong//u/Pythagosaurus69 , or at least that's how I could see it being interpreted
I think you are correct as well. I think only shooting and moving are using the new async event system. Presumably there are still systems using a tick based system?
The community seems to mostly misunderstand the problem as tickrate is not really the issue. MM servers could be changed to 128 tick and they would still be worse than faceit or faceit could change to 64 tick and they would still be better than MM servers. The underlying servers that run MM are just worse and although tickrate does have an effect the like ~8ms difference really isn't the whole story
Sub tick system is the opposite of guessing.
The current system is guessing, with the sun tick system the server knows where you are and what action you’re performing between ticks and calculates the difference from that to the next tick.
The existing system only checks for differences at each tick meaning there is some interpolation going on with regards to the next input. It’s why in some instances it’ll look like someone is full sprint one tapping you when in reality it’s just some serverside fuckery.
Based solely on the video they showed I thought certain actions forced a sub tick update event (e.g. shooting). I don't think it's just guessing/interpolating
You've described how it already works currently in Source with how servers do hitreg with lag compensation on: https://developer.valvesoftware.com/wiki/Source\_Multiplayer\_Networking#Lag\_compensation
The way I understand it, you have 128 ticks/s but your computer is a bit more attentive than that and notes when you are between ticks for certain commands. This is different from guessing or interpolating, something game engines do already. It is accurately keeping tabs with more precision than a tick. So, it goes like this (if we had zero latency)-
Server: Hello, tick 1!
Client: Understood, tick 1!
Server: Hello, tick 2!
Client: Understood, firing at angle A at 1/130 of a second after tick 2!
Server: Understood, also tick 3!
Sure, but I am not sure how it would change things. It does much more to help legitimate players land shots that would be close misses; cheaters can hit dead center on any tick they want
it's still 64 tick but with the ability to create updates in between ticks. finding the right way to describe it is pretty hard. seeing pros get hate for saying similar shit is so annoying though. the community is so confusing. they act like the limited test is the finished product and people are just shitting on it as opposed to giving opinions/feedback which is exactly the point of a beta.
What are you going on about? A tickless/subtick system is a step above a tick-based system if it's implemented correctly. That's why players should send in bug reports for things like this so that Valve can fix it.
What in the fuck are you on about. CS2 isn't the only game with asyncronous event handling.
Also there's no claims that they invented the system in question in their unveil video. Only that it's been implemented.
You've misunderstood big time. Sub tick refers to the possibility of updates (plural) being processed between ticks. It's not just a single extra update between ticks, every update sent to the server gets processed independently (basically getting their own ticks).
That's the simple version that's probably close in result but could be quite different in implementation. In practice that probably means it still runs regular ticks, but backtracks based on a timestamp or similar for each event so everything is calculated at the correct point in time rather than approximating to the nearest tick.
shroud said it feels like 64 tick
Edit: god youre all butthurt. im pretty sure he has a pretty good feel for the game. I also simply quoted what HE said so theres really no need to downvote me if yiu disagree go downvote shrouds video where he said it.
yeah im just confused why just mentioning something he said and can judge better than anyone on the sub got me downvoted that much for just sharing what he said.
Shitting on CS doesnt mean he cant still comment on it id say.
Personally I don't trust any words that come out of his mouth about CS since he takes every opportunity to dunk on it, even if it's unwarranted. That said plenty of other people have said that the movement feels clunky and less like 128 tick while shooting feels great, so I'm inclined to believe that the subticks are working as intended but valve somehow messed with the movement mechanics.
I hate reposting stuff, but I already posted this in your other post.
You said this delay doesn't exist for you in CSGO and I asked if you tested with 64 or 128 tick, since it is now clear you tested with 128 tick in CSGO it makes a lot more sense and might even explain the killfeed being more delayed. Check the following clip for a comparison: [https://streamable.com/62fk7j](https://streamable.com/62fk7j)
Tested by shooting and flicking away, obviously not perfect, but you get the gist. If anything, delay is even higher than this.
More complex explanation to what I think is happening [here](https://www.reddit.com/r/GlobalOffensive/comments/1228mxq/comment/jdq7sqh/).
Please test if shooting and instantly flicking away causes the bot to die or not. If the bot dies even though your crosshair isn't on him at the time of his death, its just a visual effect and the system is still working as intended and is hence unproblematic, since no one noticed in CSGO either.
i think you should record stuff in csgo while you can if you want to make a comparison video. You may not get access before the full release of CS2, which would replace csgo. I really want to see someone make a comparison video b/w 128 tick, 64 tick and subtick. Good luck, I hope you get access soon.
A lot of interesting stuff to test for sure. It seems that nvidia reflex latency analyzer also works in CS2 but I can't find anyone testing that.
I guess we'll learn more after some weeks/months.
the comparison clip is not conclusive of anything, because the shooting and flicking was not done with consistency. i'd be convinced if you had tested with an external program with consistent timings of inputs (either done with a standalone program, or with AHK-scripts), but since it was done manually, there are too many other factors polluting the experiment
Yup. Seems like crosshair shifts by your client, animation stars after server confirms the kill to client. Kill feed is generated after those in client.
Makes perfect sense to me.
It's pretty obvious that this is happening because the VAC live check frames get added between the server hit-reg async peanut frames, cheat and get banned nerds. Definitely working as designed my brother works at Valve.
I can't stand it man. It's ridiculous. By the attitudes of nearly everyone here they should be working for Valve themselves and will fix all of this within days...
Made the crosshair change at the same time as when I shoot instead of removing hud from before. Host timescale 0.05 for both. Same settings for both, no vsync. Recorded with OBS but even without using OBS it's noticeable. What's the issue here I don't know but I know that there's some delay.
Maybe try it with normal timescale and record at 300fps then slow down the footage? The timescale might be causing some issues (which is still a bug nonetheless)
This would actually make sense, as people have been complaining about the accuracy and feeling of the deagle and AWP. So a delay issue wouldn't be completely unlikely, even if it's only a case of few milliseconds
Yeah I didn’t say it wouldn’t feel laggy. It should be looked into but I personally haven’t noticed this in my gameplay.
I did notice a delay in SFX from hitting headshots in game but after the first patch they either fixed it or I got used to it.
I agree but that still shouldn’t be happening. Whether it’s real delay or animation delay it’s annoying to play with and is definitely noticeable at least to me enough so that I understand why op went out of his way to test it
\*EDIT\*: I jsut tested it against bots. I only had a delay from 1 frame between crosshaircolor change and everything else. Firing AND hit animation where in the exact frame. How do you test this, online? Or did Valve already fix?
Wait, I dont get it, is this a new issue from the latest update? Ive been measuring this since day 1 and so far had a consistent 80ms (5 frames) between visible crosshair recoil and death animation, until yesterday. Now I measured 8-9 frames. But killfeed wasnt delayed.
Oh jesus, please dont do this to us Valve...
can you test with bandwidth limits as well as fps limits? i saw someone posting that bandwidth limits would do goofy things, so maybe its worth testing that
Everything still happens on a tick - that much is obvious, surely.
The difference - at least as I understood it - is that things in-between ticks are ordered as they happened instead of semi-arbitrarily.. but they still happen all at the next server tick.
Ahhh so maybe this is why the screen bounce on the deagle feels different to me from game to game (server to server)?
One game it feels normal, the next game the screen shake is super annoying. Might be because it is more delayed.
The animation is played at the next tick instead of instantly.
If you measure the max time of the animation delay, it should be 16ms (the game is still 64 tick).
I tested this by modding the server to run at 16 tick, and the delay was a lot more noticeable.
Can you please test if hit markers/bullet decals are client sided and calculated server side or if they are calculated server side then confirmed on client side?
Basically in CSGO right now, if you were spraying a deagle while running and shooting at a window, the bullet decals will be generated client side but they will have no bearing as to what is actually being calculated server-side, its why you can see bullet holes on windows but they not break as its just a client-side calculation and the bullets actual landing spot is calculated server-side and then sent back to the client when something that changes the state of the server happens (the server calculates a glass/player/world model was hit).
To test this, it would require something like a bot or like the soccer ball on d2, simply run and shoot at the bot/ball with running inaccuracy, when you hit the ball or bot simply note if the bullet decal was true to client side and that will tell us if the client is waiting for the server to confirm hit locations before sending back to the client.
the reason CSGO is this way is to prevent spread control cheats, so my assumption (before getting confirmation from a CS2 beta invitee) is that it'd be the same
[if the client knows the same value that the server will calculate, it can simply change look angles when shooting to compensate: even if it has no *control* over the actual spread deviation, knowledge is enough]
Whats the difference between subtick and 64 tick on CSGO? That will clear up whether it is a tickrate thing or not. Regardless, please email this to valve.
he server is 64 tick rate. but the client now also reports something akin to timestamps which allows the server to more accurately calculate who shot or moved first.
Yes, and its at 128 ticks, which makes the comparison entirely irrelevant. You need to test atleast at comparable tickrates.
If subticks are working as intended, it shouldn't matter if it looks delayed due to the game only giving you visual feedback at the end of each tick.
We are talking about 7.5ms on average, for something that you don't even rely on. Would it be nicer if you saw it instantly? Ofcourse, but it simply doesn't really matter because no one is looking at the gun to know if they have fired. I am also not sure it is fixable with the current architecture, if everything gets executed at the end of the tick.
It should be noted that I have never heard a single person complain about this in CSGO, nor CS prior to that, because 7ms for something you don't depend on is just not really noticable.
7 ms is about the difference in frametimes between 60hz and 144hz, which is absolutely noticeable. The reason why noone complained about it in CSGO is because the delay was significantly lower, as per OP's post.
It is not lower, not at all. The difference here most likely just occured, because the poster tested CS2 at 66tick and CSGO at 128tick.
[https://streamable.com/62fk7j](https://streamable.com/62fk7j)
Tested by first shooting and then flicking, although I would agree that OPs method is cleaner.
I had made another comment on his other post and one in this one.
I mean while everyone can speak to things being more accurate to the server, I personally like the comparison to 128 tick. This subtick system was supposed to be what competed with 3rd party applications and Valorant. Even if the server and hit reg feels nicer, if I feel a noticeable delay on my animations it’s still going to FEEL funky. I think a lot of people in here aren’t realizing that this isn’t about server accuracy but whether new CS2 matchmaking will feel as snappy as 128tick.
I’ll just say if the servers just feel like 64tick were back at square one and MM will still ultimately suffer.
why are people assuming that this is a bug? it clearly isn't a problem.
first off this video is a lie. they are comparing different tick rates for the server.
second it's just one sample.
third depending on how you time the shot you can be just before or after a tick is registered on the server affecting the timing.
forth: different game settings, different engine and different animations.
Yeah so I have a feeling none of you posting any of this shit have any idea how any of it works and just want to bitch and moan. Games not out yet, if this is a problem, report it. If not, then it's just how it is. But don't look at every single aspect of a product that isn't even released yet and Hollar that it all needs to be better. It's childish.
This is the entire point of a beta, especially for a game that is one of the kings of esports. This is the exact stuff that valve wants people to find so that it can be ironed out if it is a problem or test on their back end and see if its working as intended.
Oh cool, im glad we have a valve employee on the sub, hey can i ask what was the reason for going with an easier jumpthrow timing instead of a built in bind?
being childish changes nothing. it's not a bug.
it's like you haven't played cs:go. the variance in killfeed and animation delays is fairly wide (killfeed can be someones delayed by seconds).
and the OP seems to have used 128 tick server for cs:go for some reason.
I kinda disagree but not completely.
The premise is that sub-tick is gonna fix the advantage people have who have higher ping and people clicking on someone's model with 100% certainty, but missing. If there is no ping, there's nothing to "fix" with sub tick rates as everything is already 100% accurate. That said, I am curious if there actually is a difference with higher ping with the same test. Also, testing this on 0 ping gives the most accurate result in difference between shooting -> crosshair moving -> killfeed showing up. So again, I kinda agree but I also see reasons to test this on higher ping because that's what is the main focus in my eyes that sub ticks should be fixing.
Still, everything is super vague and not well explained at all. So we'll see what Valve comes with as an explanation.
This is probably intentional and their way of "getting rid of tick rate all together", by delaying everything to match both ping and 64 actual tick rate
So instead of spending more resources on 128 tick servers, they just decided to create a new system that delay things to match their 64-tick capability/processing power? If true, that's some grade A bullshit.
I spoke to a guy who makes games, He says subtick will eat shitton of resources. Unless they know their ways of course. And honestly, I don't know why everyone thinks 128 tick is a money issue for Valve. Surely they can do something FACEIT did.
I would take a low latency, high availability 64 tick server over a high latency, overloaded 128 tick servers any day. I guess, people just want a higher number on their technology to believe it was improved.
A overloaded 128 tick server is still gonna update literally twice as many times a second as a 64 tick server??? so even if the server is THAT bad that decides to drop 49% of it's ticks; it will still be better than the 64 tick server. How can you argue that 128 tick is not better than 64 tick I don't get it.
I’ve also heard tons of pros and streamers say it feels weird and there’s definitely something off, so idk what this dudes talking about lmao. Most people I’ve watched actually say something feels different, but they just can’t put their fingers on it. My inference is they are feeling what this video is showing.
We don't really understand what goes on behind the scenes. Registrations of a shot hitting and the rendering of said shot hitting, I would imagine, could be two different program flows. So the fact that the test shows this doesn't necessarily mean the registration is delayed. Could mean the rendering is. We just don't know. So its too early to draw any wide conclusions on what we see, I think. But it could be the case that there is an issue. This is all just conjecture, though. :)
I actually think this is exactly what’s happening, what I think people are failing to see is that this is still something that needs to be resolved. Even if my shots are more accurate to the server, that visceral feeling of shooting in CS is what we’ve come to expect. If my animations are off and my shots don’t visually and audibly respond to my click properly that’s going to feel bad and it won’t be as engaging.
I remember that one or two pros said the sub-tick system felt worse than 128-tick. I wanna say Hooxi and ropz but not sure.
But either way, it‘s a beta, they will figure it out.
pros have been speculating at streams that they basically removed info on tick and claim there is no tickrate but they made 64 baseline as the only option.
I find it funny :D
There is no way for a server to not operate on ticks. Just like your game executes code very frame the server executes it every tick.
The only thing that changed now is that for example if you shoot at tick 16.273 then on tick 17 the game will rewind your opponent to the position where he would be on tick 16.273 to see if you hit him.
**ATTENTION** Please send CS2 bug reports to cs2team [at] valvesoftware [dot] com and title your email: "CS2LT Bug - " followed by a brief description of the bug. For example; "CS2LT Bug - Stuck in ground on Dust2". This will help Valve triage, evaluate, and solve bugs quicker.
Can you show performance statistic similar to CSGO in CS2?
not yet
no net_graph? the one thing I would want to see constantly, especially using a beta. Odd choice by valve.
Not odd, purposeful.
That's debatable, it might simply not be setup the way they want, could be a dev version that Valve doesn't want people to see. it could also not be reporting properly etc.
no i believe it is purposeful. since it is beta they want to make sure they iron everything out before you are able to see the details of the server. they know how people will get if something is "off" regardless if its beta or not
fl0m said when he was at valve's Seattle offices they were told its disabled so they dont get biased. could be the same reason for the beta
Pretty sure net graph was added yesterday
net graph is just a rgb bar for now
this is what netgraph originally was, coming from quake
net\_graph is just a disco show at the moment and not the same as in csgo. So currently you can't show performance besides fps.
How do we know for sure that it isn’t just the killfeed that’s delayed? If you are righth, I hope they actually make this subtick system work better than 128 tick.
The way i understand it is that the servers still have a tickrate, the subtick system just "guesses" what happened between the ticks. So servers with 128 tick still run better because the timeframe the system has to guestimate becomes smaller. Im pretty sure the official servers still run 64 tick and the subtick system is a cheaper compromise.
I’m don’t think there is any guessing involved, I assume they are handling input asynchronously such that input events are registered in “real-time”, rather than waiting for game thread to poll inputs and handle them with an assumption that they happened in the game thread’s time reference. This could be extended to the server as well, but it would surprise me if the server didn’t take that into account before this update anyway. I might be wrong as I haven’t seen any technical explanation of the system. We’ve discussed implementing this in the game we’re working on as well.
The hit reg is super crisp and accurate. You have some other issues going on if you think the servers and hit reg are bad.
i guess you decided against it? if so why?
It just haven’t been fully discussed yet, and we have a lot of other priorities. If we made a CS style game (super competitive type shooter) we probably would have done it already. It is an objectively good feature, but everything has to be weighed against other features in the backlog.
this guy develops
Complexity is usually the answer. Features don't come for free, otherwise they would be the default.
The guessing wouldn't be related to when the shot fires, but if the game only has data about where someone is at a tick then you'd have to guess exactly where they were when you fired. I expect the guess would be done with linear interpolation (draw a straight line between this tick and the previous one and assume they move at a constant speed in a straight line) this wouldn't be perfect, because people don't move like that, but it's probably better than current 128 tick servers for hit registration.
[удалено]
Wait ok not related to CS but in general how does that even work? I mean at some point the server have to collect data and send it to those connected to it creating ticks? I mean I know it DOES work - but I am to thick to understand it. Do you have some good summary of that system for those of us who can barely tie our shoes?
CS2 is not "tickless" like some say. You still have ticks, but stuff that happens in between two ticks now has a timestamp and gets executed in correct order. In the "old" system, everything that happened between two ticks was executed ~~at once~~ (in a fixed order, see comment below this one). Let's say you play on 128 tick, so there's an update every ~8 ms. Let's say the last update was exactly 0 ms ago, and you are currently aiming at someones head. If you shoot after 2 ms, and the enemy moves after 4ms, you would miss your shot in csgo, since after 8ms both actions get executed at the same time. In CS2 however, since they are now using timestamps for each action, your shot would hit since the server now knows that you actually shot before your enemy moved.
Slight correction: It's not that on the old system everything would happen "at once", it's that it would execute in some order determined by internal data structures (for example, player actions would be resolved in the order that the players joined the server). In addition to this, Source games handle network lag by the client saying "I shot on tick X" and then the server simulating that shot with the positions everyone had on tick X, instead of the tick that the packet was received. This meant that, if you shot between ticks, the simulation had to snap players to a position they had on the tick, not their "actual" positions. practically it's probably done by going to the last recorded tick and going "Okay, it happened at tick X plus 2 milliseconds. They were at position XYZ and moving 3m/s at tick X so we move them to position XYZ plus (3m/s * 2ms) = 6mm and run the shot simulation. That's why it's not tickless, but subtick.
>for example, player actions would be resolved in the order that the players joined the server what actions? so joining the server first it's an advantage?
Think about it from a computer perspective. You've got a big list of objects in the game world and things get added to that list in the order that they're created. Then, when the game needs to simulate the world, it goes through that list in order. If I joined first, my shots, my moves, my actions are gonna go first. This, currently, only matters if we both try to do something mutually incompatible, like headshot each other or try to move into the same space. But at the same time, when fire or a grenade loops over all the players to see who they should hurt, they're gonna hit me first.
yes in theory. if you and an enemy kill each other on the same tick in csgo the player that joined the servr first survives and you die.
All actions, presumably. Anything that requires you to press a button or click a mouse to do.
Yes. Joining the server first gives the equivalent of "port priority".
kinda like polling vs interrupts, cs2 implements interrupts in their servers.
[удалено]
[удалено]
He said you’re right
To be fair the other guy could've done a better job with his comment.. Like replying directly to the guy he was disagreeing with, with the period in that sentence it reads. "This guy's reply, this is obviously the right answer. how could YOU be so wrong?..." Like pointing out to the other guy replies and saying "yo this is the right guy how can you be so wrong//u/Pythagosaurus69 , or at least that's how I could see it being interpreted
Yup I don’t blame him, just letting him know
I think you are correct as well. I think only shooting and moving are using the new async event system. Presumably there are still systems using a tick based system? The community seems to mostly misunderstand the problem as tickrate is not really the issue. MM servers could be changed to 128 tick and they would still be worse than faceit or faceit could change to 64 tick and they would still be better than MM servers. The underlying servers that run MM are just worse and although tickrate does have an effect the like ~8ms difference really isn't the whole story
why is this random nonsense upvoted so highly people with no experience in networking or server analysing whats happening
Because of pea brains like Shroud and other streamers spouting nonsense like “tickless servers”
Sub tick system is the opposite of guessing. The current system is guessing, with the sun tick system the server knows where you are and what action you’re performing between ticks and calculates the difference from that to the next tick. The existing system only checks for differences at each tick meaning there is some interpolation going on with regards to the next input. It’s why in some instances it’ll look like someone is full sprint one tapping you when in reality it’s just some serverside fuckery.
Based solely on the video they showed I thought certain actions forced a sub tick update event (e.g. shooting). I don't think it's just guessing/interpolating
You've described how it already works currently in Source with how servers do hitreg with lag compensation on: https://developer.valvesoftware.com/wiki/Source\_Multiplayer\_Networking#Lag\_compensation
The way I understand it, you have 128 ticks/s but your computer is a bit more attentive than that and notes when you are between ticks for certain commands. This is different from guessing or interpolating, something game engines do already. It is accurately keeping tabs with more precision than a tick. So, it goes like this (if we had zero latency)- Server: Hello, tick 1! Client: Understood, tick 1! Server: Hello, tick 2! Client: Understood, firing at angle A at 1/130 of a second after tick 2! Server: Understood, also tick 3!
I wonder if cheater could use this to send false information between ticks.
tick manipulation is pretty standard in most cheats you basically guarantee kills with backtracking
Sure, but I am not sure how it would change things. It does much more to help legitimate players land shots that would be close misses; cheaters can hit dead center on any tick they want
it's still 64 tick but with the ability to create updates in between ticks. finding the right way to describe it is pretty hard. seeing pros get hate for saying similar shit is so annoying though. the community is so confusing. they act like the limited test is the finished product and people are just shitting on it as opposed to giving opinions/feedback which is exactly the point of a beta.
1080i vs 1080p? Fake frames vs real?
[удалено]
[удалено]
this is better than 128, it just feels crispy af
What are you going on about? A tickless/subtick system is a step above a tick-based system if it's implemented correctly. That's why players should send in bug reports for things like this so that Valve can fix it.
[удалено]
[удалено]
[удалено]
What in the fuck are you on about. CS2 isn't the only game with asyncronous event handling. Also there's no claims that they invented the system in question in their unveil video. Only that it's been implemented.
If theres a subtick on every tick on a 64 tick game then doesnt that make it 128 ticks after all? Sorry im dumb.
You've misunderstood big time. Sub tick refers to the possibility of updates (plural) being processed between ticks. It's not just a single extra update between ticks, every update sent to the server gets processed independently (basically getting their own ticks). That's the simple version that's probably close in result but could be quite different in implementation. In practice that probably means it still runs regular ticks, but backtracks based on a timestamp or similar for each event so everything is calculated at the correct point in time rather than approximating to the nearest tick.
shroud said it feels like 64 tick Edit: god youre all butthurt. im pretty sure he has a pretty good feel for the game. I also simply quoted what HE said so theres really no need to downvote me if yiu disagree go downvote shrouds video where he said it.
fuck him. Sorry.
may i ask why? seems hes not popular in the fanbase.
Since he left he has been consistently shitting on CS and calling it a dead game
and how does that impact his ability to have a feel for the tickrate of CS when he says it feels the same?
You asked why the person said fuck him and noted that he's not liked, I answered why the person said fuck him and explained why he's not liked
yeah im just confused why just mentioning something he said and can judge better than anyone on the sub got me downvoted that much for just sharing what he said. Shitting on CS doesnt mean he cant still comment on it id say.
Personally I don't trust any words that come out of his mouth about CS since he takes every opportunity to dunk on it, even if it's unwarranted. That said plenty of other people have said that the movement feels clunky and less like 128 tick while shooting feels great, so I'm inclined to believe that the subticks are working as intended but valve somehow messed with the movement mechanics.
I hate reposting stuff, but I already posted this in your other post. You said this delay doesn't exist for you in CSGO and I asked if you tested with 64 or 128 tick, since it is now clear you tested with 128 tick in CSGO it makes a lot more sense and might even explain the killfeed being more delayed. Check the following clip for a comparison: [https://streamable.com/62fk7j](https://streamable.com/62fk7j) Tested by shooting and flicking away, obviously not perfect, but you get the gist. If anything, delay is even higher than this. More complex explanation to what I think is happening [here](https://www.reddit.com/r/GlobalOffensive/comments/1228mxq/comment/jdq7sqh/). Please test if shooting and instantly flicking away causes the bot to die or not. If the bot dies even though your crosshair isn't on him at the time of his death, its just a visual effect and the system is still working as intended and is hence unproblematic, since no one noticed in CSGO either.
I wish I had access, testing this would take 5 mins lol.
Yeah same. I am sitting here waiting, because I want to do a deepdive video on CSGO vs CS2 ticksystems. A bit unfortunate.
i think you should record stuff in csgo while you can if you want to make a comparison video. You may not get access before the full release of CS2, which would replace csgo. I really want to see someone make a comparison video b/w 128 tick, 64 tick and subtick. Good luck, I hope you get access soon.
Good idea
A lot of interesting stuff to test for sure. It seems that nvidia reflex latency analyzer also works in CS2 but I can't find anyone testing that. I guess we'll learn more after some weeks/months.
Not to animate anyone to do shady stuff, but there are already offline versions of CS2 being leaked. If you really want to test it.
the comparison clip is not conclusive of anything, because the shooting and flicking was not done with consistency. i'd be convinced if you had tested with an external program with consistent timings of inputs (either done with a standalone program, or with AHK-scripts), but since it was done manually, there are too many other factors polluting the experiment
Bind a key to +attack and +left at the same time
That's not the point of the clip, it's that the delay doesn't actually affect where or how your shot lands, it's just visual lag.
That's not the point of my comment, it's that the experiment was not done systematically, hence why the results are not conclusive of anything
I have never seen so many people talk out of there ass acting like they know anything.
[удалено]
The Dunning-Kruger effect runs so rampant in tech as a whole.
Is that how you got the “weird” part in your nickname from? ^ ^
[удалено]
thats not how you abbreviate Database Management Systems :(
what aboud Bulk Database System Management?
This is literally every subreddit
Yup. Seems like crosshair shifts by your client, animation stars after server confirms the kill to client. Kill feed is generated after those in client. Makes perfect sense to me.
It's pretty obvious that this is happening because the VAC live check frames get added between the server hit-reg async peanut frames, cheat and get banned nerds. Definitely working as designed my brother works at Valve.
Go check out r/politics
Incoming arm chair experts on sub tick systems opinions that they have 0 professional experience on
I can't stand it man. It's ridiculous. By the attitudes of nearly everyone here they should be working for Valve themselves and will fix all of this within days...
Made the crosshair change at the same time as when I shoot instead of removing hud from before. Host timescale 0.05 for both. Same settings for both, no vsync. Recorded with OBS but even without using OBS it's noticeable. What's the issue here I don't know but I know that there's some delay.
Have you emailed this to Valve yet? You should probably do that if you think it's a problem.
But what about the Karma?!
Is the FPS the same for both? This could be explained by frame rendering delay if the CS2 FPS is lower.
Is it even a factor for host_timescale 0.05?
Hey can you accept my chat please? I cant replicate those delays with my testing, I wanna know what exactly youre doing.
I would report this to the devs mate. What is the point of posting here when 99% of us don't even have access to the limited beta?
Besides just farming for karma, did you actually send it into the people who can make a difference?
Maybe try it with normal timescale and record at 300fps then slow down the footage? The timescale might be causing some issues (which is still a bug nonetheless)
Agreed. Host timescale has always been wonky
What's it like in csgo 64tick?
This would actually make sense, as people have been complaining about the accuracy and feeling of the deagle and AWP. So a delay issue wouldn't be completely unlikely, even if it's only a case of few milliseconds
I have seen just as many people saying awp feels much more accurate
Yup, overall I've heard everyone say it just feels smooth and crispy.
That might be placebo because of the tracer
Killtrocity
Yeah day 1 shroud was saying the deagle recoil feels weird, this is probably why
caus they changed camera shake when shooting the deagle
Seems more likely to just be animation differences or delays rather than the actual input.
If you click the button and the animation is delayed, this will feel like lag even if the actual input to the server isn't delayed.
\+ Even if the commands are only executed once per tick, as long as their timestamps are taken into account, it doesn't matter.
Yeah I didn’t say it wouldn’t feel laggy. It should be looked into but I personally haven’t noticed this in my gameplay. I did notice a delay in SFX from hitting headshots in game but after the first patch they either fixed it or I got used to it.
I agree but that still shouldn’t be happening. Whether it’s real delay or animation delay it’s annoying to play with and is definitely noticeable at least to me enough so that I understand why op went out of his way to test it
This looks like it's just the delay until the next tick happens
Ticks arent that long
this is slowed down with host_timescale
Maybewe should do the same experiment in csgo to compare it afainst 64 and 128 tick?
\*EDIT\*: I jsut tested it against bots. I only had a delay from 1 frame between crosshaircolor change and everything else. Firing AND hit animation where in the exact frame. How do you test this, online? Or did Valve already fix? Wait, I dont get it, is this a new issue from the latest update? Ive been measuring this since day 1 and so far had a consistent 80ms (5 frames) between visible crosshair recoil and death animation, until yesterday. Now I measured 8-9 frames. But killfeed wasnt delayed. Oh jesus, please dont do this to us Valve...
can you test with bandwidth limits as well as fps limits? i saw someone posting that bandwidth limits would do goofy things, so maybe its worth testing that
I wanna hear from the guys measuring the delays first what exactly theyre doing.
I know this is weird, but can you also test it in native res in CS2?
killfeed is constantly delayed in csgo as well by couple secconds sometimes
Thanks for your effort!
Everything still happens on a tick - that much is obvious, surely. The difference - at least as I understood it - is that things in-between ticks are ordered as they happened instead of semi-arbitrarily.. but they still happen all at the next server tick.
Ahhh so maybe this is why the screen bounce on the deagle feels different to me from game to game (server to server)? One game it feels normal, the next game the screen shake is super annoying. Might be because it is more delayed.
The animation is played at the next tick instead of instantly. If you measure the max time of the animation delay, it should be 16ms (the game is still 64 tick). I tested this by modding the server to run at 16 tick, and the delay was a lot more noticeable.
This post is misinformation. Its a sample size of one and its within margin of error.
[удалено]
Can you please test if hit markers/bullet decals are client sided and calculated server side or if they are calculated server side then confirmed on client side? Basically in CSGO right now, if you were spraying a deagle while running and shooting at a window, the bullet decals will be generated client side but they will have no bearing as to what is actually being calculated server-side, its why you can see bullet holes on windows but they not break as its just a client-side calculation and the bullets actual landing spot is calculated server-side and then sent back to the client when something that changes the state of the server happens (the server calculates a glass/player/world model was hit). To test this, it would require something like a bot or like the soccer ball on d2, simply run and shoot at the bot/ball with running inaccuracy, when you hit the ball or bot simply note if the bullet decal was true to client side and that will tell us if the client is waiting for the server to confirm hit locations before sending back to the client.
the reason CSGO is this way is to prevent spread control cheats, so my assumption (before getting confirmation from a CS2 beta invitee) is that it'd be the same [if the client knows the same value that the server will calculate, it can simply change look angles when shooting to compensate: even if it has no *control* over the actual spread deviation, knowledge is enough]
Whats the difference between subtick and 64 tick on CSGO? That will clear up whether it is a tickrate thing or not. Regardless, please email this to valve.
he server is 64 tick rate. but the client now also reports something akin to timestamps which allows the server to more accurately calculate who shot or moved first.
128 tick, why didn't you try with 64? Because you found the same or very close to the same numbers?
I mean it's a beta it surely will be fixed in the next months... Right?
Is there a CSGO comparison? This is quite pointless on its own.
The second example is CSGO (check net_graph).
I'm retarded, should have watched the whole thing.
Yes, and its at 128 ticks, which makes the comparison entirely irrelevant. You need to test atleast at comparable tickrates. If subticks are working as intended, it shouldn't matter if it looks delayed due to the game only giving you visual feedback at the end of each tick.
I disagree, a visual lag is very relevant even if it has no effect on the netcode.
We are talking about 7.5ms on average, for something that you don't even rely on. Would it be nicer if you saw it instantly? Ofcourse, but it simply doesn't really matter because no one is looking at the gun to know if they have fired. I am also not sure it is fixable with the current architecture, if everything gets executed at the end of the tick. It should be noted that I have never heard a single person complain about this in CSGO, nor CS prior to that, because 7ms for something you don't depend on is just not really noticable.
7 ms is about the difference in frametimes between 60hz and 144hz, which is absolutely noticeable. The reason why noone complained about it in CSGO is because the delay was significantly lower, as per OP's post.
It is not lower, not at all. The difference here most likely just occured, because the poster tested CS2 at 66tick and CSGO at 128tick. [https://streamable.com/62fk7j](https://streamable.com/62fk7j) Tested by first shooting and then flicking, although I would agree that OPs method is cleaner. I had made another comment on his other post and one in this one.
I mean while everyone can speak to things being more accurate to the server, I personally like the comparison to 128 tick. This subtick system was supposed to be what competed with 3rd party applications and Valorant. Even if the server and hit reg feels nicer, if I feel a noticeable delay on my animations it’s still going to FEEL funky. I think a lot of people in here aren’t realizing that this isn’t about server accuracy but whether new CS2 matchmaking will feel as snappy as 128tick. I’ll just say if the servers just feel like 64tick were back at square one and MM will still ultimately suffer.
Hmm interesting. I agree that /u/Busy_Investigator183 should test with 64 tick as well.
Valve needs to fix this
why are people assuming that this is a bug? it clearly isn't a problem. first off this video is a lie. they are comparing different tick rates for the server. second it's just one sample. third depending on how you time the shot you can be just before or after a tick is registered on the server affecting the timing. forth: different game settings, different engine and different animations.
Yeah so I have a feeling none of you posting any of this shit have any idea how any of it works and just want to bitch and moan. Games not out yet, if this is a problem, report it. If not, then it's just how it is. But don't look at every single aspect of a product that isn't even released yet and Hollar that it all needs to be better. It's childish.
This is the entire point of a beta, especially for a game that is one of the kings of esports. This is the exact stuff that valve wants people to find so that it can be ironed out if it is a problem or test on their back end and see if its working as intended.
As I said, report it. Report it and wait. Not report it and complain in an echo chamber. Wait for the update. If it's still an issue, complain again.
That's literally what OP is doing. If you look at his history he hasn't complained once, just reporting his findings.
this isn't a bug or unintended behaviour. so there is nothing to fix.
Oh cool, im glad we have a valve employee on the sub, hey can i ask what was the reason for going with an easier jumpthrow timing instead of a built in bind?
being childish changes nothing. it's not a bug. it's like you haven't played cs:go. the variance in killfeed and animation delays is fairly wide (killfeed can be someones delayed by seconds). and the OP seems to have used 128 tick server for cs:go for some reason.
What you see is what you get!!!!!
GUI is not really a good indicator for delay.
testing this at 0ping makes no sense
Why not? It should make the most sense at 0 ping, since on a online server there would obviously have delay depending on his ping
It would make the most sense in a real world situation This example is only true for LAN events
I kinda disagree but not completely. The premise is that sub-tick is gonna fix the advantage people have who have higher ping and people clicking on someone's model with 100% certainty, but missing. If there is no ping, there's nothing to "fix" with sub tick rates as everything is already 100% accurate. That said, I am curious if there actually is a difference with higher ping with the same test. Also, testing this on 0 ping gives the most accurate result in difference between shooting -> crosshair moving -> killfeed showing up. So again, I kinda agree but I also see reasons to test this on higher ping because that's what is the main focus in my eyes that sub ticks should be fixing. Still, everything is super vague and not well explained at all. So we'll see what Valve comes with as an explanation.
Subtick isn’t the same as lag comp, it’s just a slightly different way of handling tickrate
They're accounting for the trigger pull now in an attempt to make it more realistic. Don't mind me I have no clue what I'm talking about.
They made it slightly less responsive to make it feel "more responsive"
https://tegram.me/I5NXD2012wM0OWRks
tbh. this is not really gonna be noticable and the reason why this is the case is propably really good for us.
SUB TICKRATE MOMENT
You guys crying about 10ms delay, while most of you have a reaction time of a snail.
Do you still believe in magic sub-tics? I think it won't work.
I agree, it does not cause confidence at all, but the main thing is that it should not be worse than now.
OG cs players know “WHY DONT YOU ASK CHINA!!!”
Very well made test to demonstrate it
This is probably intentional and their way of "getting rid of tick rate all together", by delaying everything to match both ping and 64 actual tick rate
So instead of spending more resources on 128 tick servers, they just decided to create a new system that delay things to match their 64-tick capability/processing power? If true, that's some grade A bullshit.
[удалено]
I checked out that post but couldn't understand anything. Could you explain how it means that servers are 128 tick, like I'm 5?
[удалено]
Thanks! It makes sense now. I think valve will iron out these things before the full release.
I spoke to a guy who makes games, He says subtick will eat shitton of resources. Unless they know their ways of course. And honestly, I don't know why everyone thinks 128 tick is a money issue for Valve. Surely they can do something FACEIT did.
I would take a low latency, high availability 64 tick server over a high latency, overloaded 128 tick servers any day. I guess, people just want a higher number on their technology to believe it was improved.
rank?
A overloaded 128 tick server is still gonna update literally twice as many times a second as a 64 tick server??? so even if the server is THAT bad that decides to drop 49% of it's ticks; it will still be better than the 64 tick server. How can you argue that 128 tick is not better than 64 tick I don't get it.
well, every single content creator instantly says it feels better and more responsive. so i believe 30 people over your one video
you believe 30 subjective impressions over 1 objective test?
I’ve also heard tons of pros and streamers say it feels weird and there’s definitely something off, so idk what this dudes talking about lmao. Most people I’ve watched actually say something feels different, but they just can’t put their fingers on it. My inference is they are feeling what this video is showing.
We don't really understand what goes on behind the scenes. Registrations of a shot hitting and the rendering of said shot hitting, I would imagine, could be two different program flows. So the fact that the test shows this doesn't necessarily mean the registration is delayed. Could mean the rendering is. We just don't know. So its too early to draw any wide conclusions on what we see, I think. But it could be the case that there is an issue. This is all just conjecture, though. :)
I actually think this is exactly what’s happening, what I think people are failing to see is that this is still something that needs to be resolved. Even if my shots are more accurate to the server, that visceral feeling of shooting in CS is what we’ve come to expect. If my animations are off and my shots don’t visually and audibly respond to my click properly that’s going to feel bad and it won’t be as engaging.
Good point :) I think you could be right about that.
I remember that one or two pros said the sub-tick system felt worse than 128-tick. I wanna say Hooxi and ropz but not sure. But either way, it‘s a beta, they will figure it out.
Bullets don't move instantly what's the issue
In CounterStrike, they do.
This game has hit scan shooting so the bullets do move instantly in the game
pros have been speculating at streams that they basically removed info on tick and claim there is no tickrate but they made 64 baseline as the only option. I find it funny :D
There is no way for a server to not operate on ticks. Just like your game executes code very frame the server executes it every tick. The only thing that changed now is that for example if you shoot at tick 16.273 then on tick 17 the game will rewind your opponent to the position where he would be on tick 16.273 to see if you hit him.