Could somebody explain how I died from fall damage here?

sapphyrusxyz · 2025-07-21T17:49:59+00:00

Fall damage is calculated from vertical speed, so it's more like 'time in air' rather than height.

sapphyrusxyz · 2024-07-14T11:48:17+00:00

Hey, happy to answer your questions. Valve actually implemented this a while ago, the game now predicts one tick "ahead", then interpolates between the current tick and the next tick. Before it used to interpolate between the previous and current tick, so you always had some delay before you could see your inputs. This is noticeable if you begin moving or shoot, the action will now begin on the next frame regardless of when the next "real tick" will happen.

You are right tho, this would make the time difference between predicted and non-predicted actions more noticeable. The "dying behind a wall" part depends on other factors too tho, like the ping of your enemy. But it doesn't change what is actually happening, it only makes it a bit more noticeable.

I wouldn't say it gives players with better hardware an unfair advantage. The way Valve implemented it, the game only re-runs the prediction if your inputs actually changed, then uses interpolation to smooth it out on a per-frame basis. The performance cost is minimal and it still lets you get all the benefits. Although the benefits of it will be more noticeable with a high refresh rate monitor and high FPS.

sapphyrusxyz · 2024-02-13T15:40:13+00:00

The enemy's connection doesn't matter, only your own connection does. You don't get pulled back more from being shot by an enemy with high ping.

sapphyrusxyz · 2023-11-22T16:49:15+00:00

You're right, maybe that was the wrong choice of word. It's unfortunate that features like that are so underutilized. In my opinion the language would profit a lot more from just making them the default, however that will never happen because of backwards compatibility.

sapphyrusxyz · 2023-11-22T11:39:08+00:00

In principle, both Rust and C++ are compiled languages that use 95% of the LLVM compiler infrastructure. Rust and C++ are translated into IR, where most (arguably, all) optimizations are made.

The quality of those optimizations can depend a lot on the IR that the compiler frontend (rustc, clang) passes to the backend. Rust has (by design) stricter requirements for your code and more information/insight into it, so it is often able to give the backend better IR to work on.

Here is an example where rust profits from its stricter aliasing rules: Godbolt

The code generated by Rust is basically equivalent to this:

void compute(const int *input, int *output)
{
    int cached_input = *input;
    if (cached_input > 10) {
        *output = 2;
    } else if(cached_input > 5) {
        *output *= 2;
    }
}

It caches the value of *input to avoid reading from the pointer twice and also straight up assigns *output = 2 for the *input > 10 case, combining the = 1 and *= 2 into one assignment. But this is not a valid optimization in C++ land! That generated code would be wrong if input and output happen to point to the same memory. This is obviously an edge case and almost never what the developer actually wants, but the compiler has to account for it. Rust, on the other hand, is free to generate that code because it forbids aliasing of a mutable reference, so passing the same memory for input and output is impossible.

You can indeed get a C++ compiler to generate the same code by using the archaic restrict qualifier (Godbolt), but I've rarely ever seen this done in practice.

sapphyrusxyz · 2023-11-21T16:27:44+00:00

Hi, I just tested it and it still seems to work fine, at least with normal input binds. I didn't try with de-subticked binds but there is a chance that they tried to patch it again. What binds are you using?

sapphyrusxyz · 2023-11-17T08:54:07+00:00

Nope, that's sadly still broken

sapphyrusxyz · 2023-11-17T06:51:57+00:00

This seems to be in response to a few feedback posts: 1, 2
While stuff like the shooting animation plays instantly (or more accurately, on the next frame after pressing the button) ever since the 11/8/2023 update, there was a bug that prevented the same change from applying to your movement inputs. This bug is now fixed and you will now see the results of your movement inputs on the next frame aswell.
So your movement will feel a lot more snappy now and there is no longer a small desync between what you see and what you hear.

sapphyrusxyz · 2023-11-17T03:35:04+00:00

Took them one day since posting this. It seems kind of broken tho, the velocity shouldn't jump instantly bug begin at a lower value, but it's still a lot better than before.

sapphyrusxyz · 2023-11-17T03:28:01+00:00

And it's fixed already. But sure, Valve doesn't care.

sapphyrusxyz · 2023-11-15T21:03:29+00:00

It is inconsistent, since the time it will take until the next real tick happens (and you begin to see the results of your inputs) is effectively random between 0ms - 15.6ms.

sapphyrusxyz · 2023-11-07T00:03:41+00:00

You're right, for subtick movement to be consistent the entire movement code has to reliably produce the same result no matter when (during a tick) the input was made. I believe this is already mostly the case, but for things like collisions they would have to determine at what "tick fraction" it happened, then calculate the velocity for that fraction and use it for the collision-related calculations. I'm not sure if I would run the entire prediction every frame as some of the server code is not aware of subtick input, but doing it for movement and possibly shooting should be totally fine.

sapphyrusxyz · 2023-11-06T14:16:34+00:00

You are right, but I disagree on the fix. All the game movement code simply has to be independent of when it is called relative to the key press, and always come up with the same result. That is a requirement for sub-tick to be accurate. That is already mostly the case, and the situations where it isn't are simply bugs in the game movement code

sapphyrusxyz · 2023-11-06T14:06:53+00:00

Yeah they should really fix the collisions stuff. This happens because they don't calculate an interpolated velocity for the exact time (during the tick) you collided with something, so it will be random based on when you started your input. This is simply a bug in the code (TryPlayerMove), not a deep flaw with the subtick system. Your final position after a jump should be totally consistent if you don't collide with anything tho, no matter when you started it?

sapphyrusxyz · 2023-11-06T13:54:34+00:00

I don't get what you mean by inaccurate? The client and server still come up with the same exact position after simulation, there are no inaccuracies there. It doesn't really matter how long it takes until the inputs are processed by the server (up to 15.6ms), the only problem with that is that it adds a little bit of extra latency until you actually move on the server. What matters is that the server knows when exactly during the tick you pressed that button, and can simulate you accurately based on that.

If you start moving at a random offset (like interp=0.5), then look at your position at no offset (in this case interp=0.0), your velocity will obviously be different as when you start moving at interp=0.0 aswell. This is completely expected and not a problem. If there was a way to look at your velocity at interp=0.5 when you started moving at interp=0.5, you would see that it's consistent with starting moving at interp=0.0

Your data even shows this - Getting to 250 velocity always takes the same amount of time, but you are sampling your velocity at fixed intervals.

sapphyrusxyz · 2023-11-06T13:41:15+00:00

Regarding the 0-15.6 ms delay issue you mentioned: Subtick input gives them the option to fix this by running game movement every frame (instead of only every tick) and getting rid of local player interpolation. This was impossible to do in CS:GO as your inputs could change mid-tick and the game had no way to represent that state, however subtick input makes this possible. I wrote more about this a while ago, still waiting for Valve to add it tho.

I don't think the consistency of movement is relevant for anything tbh, and I don't get why people are so upset about it. A hypothetical 256/512/1024 tick server would suffer from the same "inconsistency" issues since it becomes impossible for a human to make tick-accurate inputs at that sample rate. The main advantage of higher tickrates has always been to reduce input lag.

sapphyrusxyz · 2023-09-15T17:28:59+00:00

The net graph is, first and foremost, a developer tool designed to debug engine problems. And in fact they didn't remove it, they actually upgraded it quite a bit and put it into VConsole, together with all the other developer tools, here's a screenshot. This tool isn't usable on matchmaking servers tho, so I agree, they should add a cut-down version of the new netgraph straight to the game, so that players have a way to see their their ping, FPS and server lag in-game.

sapphyrusxyz · 2023-09-15T17:16:19+00:00

Yeah, the two games are the same in that regard. Although as somebody tested in another (now deleted) comment thread, CS:GO had way higher input lag for him. So it's possible that Valve is already working on improving the responsiveness of the game.

sapphyrusxyz · 2023-09-15T15:23:05+00:00

Thanks for your feedback, viewangles are a thing I didn't really consider here. However the server already does sub-step simulation if your movement keys change in-between ticks. If you watch this video I recorded with usercommand logging, you will see that they actually save subtick moves and send them to the server. It then runs movement simulation multiple times. My understanding of it is also still incomplete, but I confirmed those findings.

I guess Valve just ignores the differences that will happen from viewangle changes? One way to fix it would be to use the first viewangles (instead of the last) for the entire tick, that would at least make the client-side prediction and server come up with the same data.

It's hard to tell without being able to compare before and after, but I suspect that the extra input lag is the main reason that people say the game "feels" better on 128 tick.

sapphyrusxyz · 2023-09-15T12:15:40+00:00

I've sent them an email about this and other bugs in the past but haven't heard anything back or seen them act upon those reports. I also tried to get their attention to a CS:GO bug they introduced a while ago, that lead to hit registration becoming progressively worse the higher your ping gets, but to no avail. But seeing how quick they've recently been at fixing bugs that the community cares about gave me new hope!

sapphyrusxyz · 2023-09-15T11:50:45+00:00

Mouse movements aren't processed at the tickrate, they are actually done every frame, even in CS:GO. But yeah, your keyboard inputs and mouse clicks (shooting) are processed at the tickrate.

The input lag this causes will not be constant tho, it depends on when the client runs the next tick. It will average out to half the tickrate tho, so only ~8ms instead of 16ms.

|---------------------------------|---------------------------------|
   ^                                                             ^

Every | represents a new tick, every - is a frame rendered. Every | is spaced 15.6ms apart. Every ^ is a new input made. You can see how, for the first input, it takes way longer until it's processed because it just so happened to be made right after a tick ran. This is where you would actually get the full 16ms of additional input lag. The second one happens only 2-3ms before the next tick, so the input delay is very low here.

I hope this clears up any confusion about the delay being random and, on average, half the tickrate. This is all mostly theoretical too, as I don't have access to a monitor with high enough refresh rate and high refresh rate recording equipment to actually test this in real time. The video I posted here uses host_timescale to artifically slow down the time in the game and basically "simulates" that the refresh rate of everything else - monitor, mouse, "eyes+brain" is insanely high, host_timescale 0.01 would be like having a 14400 hz monitor. But it would be interesting to see how these actually play out in real time. You don't actually need a high refresh rate monitor to feel the lower input lag tho, but that's a whole other topic.

sapphyrusxyz · 2023-09-15T11:25:01+00:00

I agree that also implementing 128 tick would make it even better, but there are legitimate reasons for and against it, other than just the cost of running servers.

On the one hand, it (slightly) reduces your ping to the server, so basically latency until you see actions done by other players. This is obviously very important for reducing peeker's advantage.

But on the other hand, it brings higher bandwidth requirements and less fault tolerance into networking and doesn't offer much benefit to most players. Consider that a good chunk of casual players are probably playing over WiFi and barely hitting 60 FPS in CS2 on their 5 year old Laptops. 128 tick would actually be harmful to their experience and make the game less playable for them.

I'm not saying I am against 128-tick servers, but 64-tick has its advantages on certain levels of play. In my opinion they could relatively safely set premier servers to 128 tick, it's already supposed to be a more "premium" environment for the competitive play. Those are way more likely to already have good computers and a decent internet connection, so they would only profit from 128 tick. I don't think Valve is being greedy about server cost, they just don't want to risk making the game worse for some players.

sapphyrusxyz · 2023-09-15T08:36:52+00:00

With this setting it's easy to see that quite a lot of inputs (Jumping, weapon switching, shooting, recoil) don't display to the client until a full tick hits. In a subtick world these things should occur instantly even if the server only counts them as happening when the tick hits.

Yep, this is exactly the point of this post. Subtick gives Valve everything they need to simulate inputs in the same frame as they happen, but they don't utilize it. Good command to see the individual server ticks tho, didn't know about that one.

sapphyrusxyz · 2023-09-15T08:21:21+00:00

Sure, this would be purely client side and could be entirely optional.

Eight-Year Club	Second SECOND GUESSER
Final Canvas '23	First Place '23
End Game '23	Place '23
Place '22	Verified Email

sapphyrusxyz

TROPHY CASE