Quote:
Originally Posted by backwards
Ever since the original version of the hit registry plugin i wrote it has fixed all the issues in your public release. It uses simpler logic to just always lag compensate all players, rather then trying to check if someone is visible within fov or far away based on being teleported. Which your plugin is trying to do but still will fail in situations and is just wasted cpu cycles.
You aren't even aware of the interoplation issues that mostly affect high velocity game play. When clients send user commands to the server they just include tick_count for the server to backtrack players to previous points in history. This information lacks frame data. If a server is running at 100 tickrate and the client has 300 fps then he will see 2 extra frames with interpolation of the enemys postion that never actually exist on a server side tick. Thus the server can't teleport the player to the correct frame out of the 3 and just uses the closest tick which leads to many missed shots.
This is what a server would see at 64 tick rate and a player flying at max velocity:
This is what a client would see with client side interpolation at 300 fps:
If you increase the tickrate on the server to 128 it would have double the accuracy but its still not good enough for players with higher fps then the servers tickrate:
The only real solution a dedicated server can use to solve this interpolation issue from the missing client attack frame is to account for all of the missing 2 frames out of 3 (from this examples 100 tick and 300fps):
Simply increasing the hitbox size with the players velocity dynamically will cover the missing gaps and help reduce the interpolation issue which is the only way possible without modifying client files.
Triggers wouldn't break as updating the hitbox between a OnStartLagCompensation and OnFinishLagCompensation would have no vphysics checks for triggers. Shotguns would work the same way as well.
All plugins I'm commissioned for and sale always include full source code if it's written in source pawn or not. It appears you just like to make things up?
This video appears to be someones plugin just trying to mimic my plugin with the same mindset you had. Just making extremely large hitboxs without accounting for velocity or distance from attacker to victim.
Not sure why you are spreading false information but you should worry about fixing your own plugins before calling out others while making assumptions. You are missing many things that can increase hit registry in csgo. |
Ah yes I remember, I think we talked about that before years ago, I'm quite outdated on that and I would need to check myself to be sure but,
it isn't exactly why commands are sent per ticks and not by frame ? (let's ignore the fact that we can have fps lower than tickrate here)
I mean we do not get only tick_count but also cl_interp etc...
Isn't it what the purpose of lag compensation is doing, since it also compensates for interpolation as-well during backtrack (since these hitboxes technically don't exist server-side,
so lag compensation needs to do its own interpolation between two intervals) ? (
https://github.com/ValveSoftware/sou...ation.cpp#L508)
My point is, I don't remember much the details about how Valve interpolation is done, but the only issue I can see with it is that during interpolation,
is that if Lerp is not a multiple of a tick interval, if you shoot under that tick, the shot will be firing at a player position that never existed like you said during that tick,
and I can see why it is a problem because you have no way to know how the frames were processed between the ticks inside the client,
you got only interpolation (Lerp ms) and tick_count information, but you have no information how the frames and interpolation were processed in the first place (so how it was interpolated in the client exactly),
so it is not really precise, I got that.
Though now, theoretically if Lerp a multiple of a tick interval (hence why I always set my Lerp to a tick interval).
it should fire at the server position that existed previously since interpolation should only interpolate and not extrapolate between the intervals,
it also even increases in precision if we remove the networked variables compression too.
But that implies if Valve did their interpolation correctly in the first place.
If it extrapolates instead of interpolating, or Valve code's interpolates weirdly, then yeah you have no way to get precise stuffs at all, and there's no way to fix it at all sadly.
This is why most of hacks are doing their own interpolation so they are not filled with Valve's broken stuff I suppose nowadays.
Personally I don't like much the idea of making hitboxes bigger even if it seems to fix it, it only makes the problem worse, it might work maybe when players are walking, but when surfing, the difference is so large between the intervals that the bigger hitboxes are not even enough (actually it makes things worse cause you can hit even more by aiming behind the player and does not hit even by aiming player correctly). At least as a player I didn't have a good experience playing with it years ago. Some people seem to like it though.
I think that, rather than making hitboxes larger, maybe it's possible modify the hitboxes to "interpolate"/expand between two hitboxes within two intervals (or exactly between lerp ms to the closest tick interval), and that seems a better idea to me than making them bigger.
But yes in practice that sounds hard to make.
As a side note, I really liked this post that details pretty much everything what I said:
https://www.unknowncheats.me/forum/c...rpolation.html