Hello,
I'm here just to describe some issues that some of you may be aware of,
but I would like to give some of my knowledge of what can be done to improve Source Engine games in general.
The issues/solutions discussed can be implemented in SP or any low-level language.
I am mainly focused on Surf Combat (in CS:S or CS:GO) servers, but I believe these fixes can also improve the whole Source Engine in general.
1) First biggest issue: network compression.
The Source Engine games have a huge problem with network compression, which makes in some situation the game unplayable because of prediction errors.
Before, when Source Engine was mostly done (around 2000s), we had very low bandwidth on modems so network compression was really important.
My idea is that Valve implemented probably their own method for compressing because compressing the whole packet wasn't enough,
so they implemented a compression method to send entity structures / networked variables over the network. (SendPropVector with proxy hooks with specified amount of bits, etc...)
But nowadays, I guess most of people have 1 megabyte/second of download at least and I don't think this method of compression is necessary anymore.
This was already discussed somewhere in this forum even though I knew about this earlier (https://forums.alliedmods.net/showthread.php?t=314962),
but it is possible to disable the compression in networked variables by setting sv_sendtables to 1 and
by invaliding the CRC check here: https://github.com/VSES/SourceEngine...lient.cpp#L835
Now as for why you want to do that,
atleast on specific variables is because you can remove the network compression on animation layers and angles, position etc. of an entity which results in better alignment between server and client hitboxes.
There's also the fact that we can remove the limits of m_vecBaseVelocity, so it can render this extension useless: https://forums.alliedmods.net/showthread.php?t=195008
it fixes also problems with trigger_push 'force' value to be more than -1000/1000 on each axis: https://github.com/ValveSoftware/sou...ayer.cpp#L7967
We can also remove the limits of m_fFlags in Source Engine / CS:GO which will fix push triggers that is demonstrated here: https://forums.alliedmods.net/showthread.php?t=267131
Please, do not use this plugin in your servers, it does not respect the physics of the game originally,
if you have been using it for a bhop/surf server you can be ready to remove all your times, as it invalidates all of them since physics changed (except if trigger_push wasn't used).
Now as for why it will fix it properly, it is because it is an issue with client prediction because of the network compression not sending the FL_BASEVELOCITY flag in first place,
so it doesn't apply m_vecBaseVelocity in the new origin and results in prediction issues.
See these references:
https://github.com/alliedmodders/hl2...ayer.cpp#L7983
https://github.com/alliedmodders/hl2...ayer.cpp#L7884
https://github.com/alliedmodders/hl2...c/const.h#L117
As you can see FL_BASEVELOCITY is after the limit of PLAYER_FLAG_BITS (which is 11 bits currently),
so the FL_BASEVELOCITY is never actually sent to the client and results in unsmooth movements due to client prediction issues.
It renders this calculation not even being executed in CS:GO (in fact it can't even call it even if FL_BASEVELOCITY flag is set due to FL_CONVEYOR being the 13th bit):
https://github.com/perilouswithadoll...tion.cpp#L1012
Worse, it sets the entity's base velocity to zero so it breaks totally the triggers, because now game movement code can not even process base velocity since it is zero in first place:
https://github.com/perilouswithadoll...tion.cpp#L1021
This was not an issue on CS:S or other Source Engine games because CheckMovingGround wasn't implemented yet.
Though there's still the fact that it executes this code in client side for all Source Engine games, when it should not:
https://github.com/alliedmodders/hl2...ared.cpp#L1815
Also, I must say that if you use these fixes, you server demos will be broken because sv_sendtables was an experimental feature and was never really properly implemented by Valve, but this can be fixed of course.
If I had a chance to work at Valve I would probably write the fix for it (or continue to work on it).
Fun fact, this experimental feature is vulnerable to a crash and can be probably exploited for a Remote Code Execution in both client - server side, but I did not investigate further either, have fun searching.
As a last final note, I have discussed here just some issues of the networked variables compression but there might be other issues that I may be not aware of and get magically fixed by removing variables compression.
I am done now kinda with the explanations of this first part, but you see why now every variables should be decompressed by default as it avoid the game to be a broken game in first place.
2) Not so big issues in lag compensation.
Besides pose parameters that are fixed now in CS:GO (not sure about CS:S and other games) thanks to Altimor,
there is some issues that Surf Servers will encounter,
First issue is the 1 tick delay in the local player's screen and the game's one due to interpolation and RunCommand logic which is known to public:
https://forums.alliedmods.net/showthread.php?t=315405
The second issue is the teleport check, which is known to hack vs hack coders because of fakelag, but maybe not other people:
https://github.com/ValveSoftware/sou...ation.cpp#L463
Although it may seem a good idea at first because it does not require the real logic to check when a player has teleported,
it breaks lag compensation when others players are going too fast in surf.
Remove that check, or implement a better one.
You might also increase the value of this check a bit or remove it completely so high ping players can hit accurately:
https://github.com/ValveSoftware/sou...ation.cpp#L390
A message to Surf Combat servers: Please dear God, do not use bigger hitboxes for God sake, this breaks the game, do not use it please, I'm begging you. Thanks.
There's also an issue with interpolation that breaks a bit lag compensation in this game that I need to investigate further,
but this can't be really fixed (don't take my word for it though, it may be fixable and I might correct this post further if I want to continue to investigate on that I like to solve impossible things)
as it is more a client side problem, though, I think it is because it uses Hermite interpolation rather than a simple linear interpolation (would need INTERPOLATE_LINEAR_ONLY I guess).
That is all for now, but I might edit this post for future fixes of Source Engine that is possible to do server side, don't hesitate also to share you knowledge.
I don't have really those issues solved by a plugin so I'm waiting some slaves to do it for me, if they can, it would be great for the community.
I can also do it if you pay me.
Ping me also if there is errors on my post, I'll correct them.
Cya!