[GoldSrc] Restrict the FPS limit from Server-Side

[Rainnegan]

There are users with hacks that can patch the FPS limit on the client and get more than 1000 fps. By doing this and using a Strafe Hack, they can fly around on the map.

https://youtu.be/SURXT7ZMz6k

Honestly, i don't understand why they want to get more than 500 fps ...

[metita]

Players should be allowed to play on whatever fps they want, what we need to do is address how FPS are affecting gameplay, behavior should not change when people are on different FPS.

[Rainnegan]

Players should be allowed to play on whatever fps they want, what we need to do is address how FPS are affecting gameplay, behavior should not change when people are on different FPS.

Setting fps to more than 100 will make client_PreThink work more faster (eating more resources from server), and too other fuctions, imagine with 1000 fps, also, what is the point to play to more than 500 fps ? ... =/

[StevenKal]

None, humans's eyes just don't see the difference above that. And as you said this calls some engine API functions much more, and this can also have a different effect on plugins using such functions (like PreThink) and with frames, as with the parachute, the animation speed and some effects will be multiplied/divised according to the frames/FPS, which can lead to different behavior between clients, and incorrect behavior (open a parachute on a map where you have 25 FPS [a map with high <w|e>_polys], this almost does not stop the fall and you die!). The workaround is to use other kind of "think" function, or a loop at through server frame but with adjustements, because server's frames can also vary a bit, or be changed in force via CVar "sys_ticrate".

As other negative point, this uses much more computer's resources (CPU/GPU), so except for testing its power (or the difference between some graphics settings), it's useless.

The only positive point I could see, is the fact this might only be good (as on cinema), when you make videos and slowdown them, higher amount of FPS are kept.

Lock the FPS to 100 could be a solution, but I'm more in favor of freedom, and people should be able to play with the FPS they want, for testing purpose or other reason.

[Rainnegan]

None, humans's eyes just don't see the difference above that. And as you said this calls some engine API functions much more, and this can also have a different effect on plugins using such functions (like PreThink) and with frames, as with the parachute, the animation speed and some effects will be multiplied/divised according to the frames/FPS, which can lead to different behavior between clients, and incorrect behavior (open a parachute on a map where you have 25 FPS [a map with high <w|e>_polys], this almost does not stop the fall and you die!). The workaround is to use other kind of "think" function, or a loop at through server frame but with adjustements, because server's frames can also vary a bit, or be changed in force via CVar "sys_ticrate".

As other negative point, this uses much more computer's resources (CPU/GPU), so except for testing its power (or the difference between some graphics settings), it's useless.

The only positive point I could see, is the fact this might only be good (as on cinema), when you make videos and slowdown them, higher amount of FPS are kept.

Lock the FPS to 100 could be a solution, but I'm more in favor of freedom, and people should be able to play with the FPS they want, for testing purpose or other reason.

Reasons to limit FPS to 100 while on Multiplayer: · Avoid eating CPU usage to server. · Avoid eating CPU/GPU usage on client. · Avoid making more easier control the weapon's recoil. · Avoid making more easier to do No-Fall-Damage exploit. · Avoid destroy the game with Auto-Strafes Hacks and higher fps. · Avoid stay on the air (like to check if someone will pass over some path or something).

Reasons to NOT block fps to 100 while on Multiplayer: · Testing purpose?, try it on Singleplayer. · Freedom?, it's better to stay the game more secure and give a better gameplay.

There is no a valid reason to use higher fps on Multiplayer games honestly.

[RauliTop]

Well, some people on surf or bhop servers will need more than 100 fps.

A cvar to set a limit for fps on the server-side it's the best option.

[afwn90cj93201nixr2e1re]

Players should be allowed to play on whatever fps they want, what we need to do is address how FPS are affecting gameplay, behavior should not change when people are on different FPS.

In other issues(which also related to cvar's) by this user you taking another position, lol, very kind, keep that way.

Reasons to limit FPS to 100 while on Multiplayer: · Avoid eating CPU usage to server.

What? Rly? Seems like you are using PreThink or something like that in some abstract VM just for fps calculation. PreThink features can be used on mod servers for example surf/hns/kreedz and other stuff where we need more performance for better response on each move.

· Avoid making more easier control the weapon's recoil.

better performance and faster calculation, you can react faster than in 1 or 30 fps. Set fps_max to 30 and try to play on surf servers with 10aa, set it to 60 and again...

· Avoid making more easier to do No-Fall-Damage exploit.

:/, it's should be fixed in server side and in lag compen. system, which was broken in 2013. I can also make it on 100/101 fps without hacks, how restriction gonna fix it?'

· Avoid destroy the game with Auto-Strafes Hacks and higher fps.

I can make 80-90 synced 10-12 strafes without hack's with 100/101 fps on 100aa servers, so, and how that related to client side? If you don't wanna allow strafe hack's you should make some calculation, but it's also just stupid way to detect cheats and you gonna loose on prof. HNS/kreedz players.

None, humans's eyes just don't see the difference above that.

eyes - yes, hands, brain - no.

By doing this and using a Strafe Hack, they can fly around on the map.

expected engine behaviour, see quake gameplays, it's also related to speedhacks(speedhacks and slow-down stuff).

[hashnimo]

Reasons to limit FPS to 100 while on Multiplayer: · Avoid eating CPU usage to server. · Avoid eating CPU/GPU usage on client. · Avoid making more easier control the weapon's recoil. · Avoid making more easier to do No-Fall-Damage exploit. · Avoid destroy the game with Auto-Strafes Hacks and higher fps. · Avoid stay on the air (like to check if someone will pass over some path or something).

Reasons to NOT block fps to 100 while on Multiplayer: · Testing purpose?, try it on Singleplayer. · Freedom?, it's better to stay the game more secure and give a better gameplay.

Damn that's a long list of exploits for those who have better hardware.

Maybe it would be ideal to pick an exact number to put an FPS limit until there's no unexpected gameplay behavior. Probably it's not just a rounded number like 100 if someone can push those numbers as much as they can to test the behavior. So there won't be a reason to complain for limiting the FPS to that exact number since it's the max the engine can do for a fair gameplay.

[afwn90cj93201nixr2e1re]

now fps already restricted by 999.

[hashnimo]

now fps already restricted by 999.

Is it server-side? As OP stated, hackers patch it locally and they have the ability to overcome the limit whether it's for hacking or not. This should be taken to server-side then. The amount of issues he posted have shown it's time to put the work to server development. Else these exploits he revealed will destroy the game sooner or later.

When there's a chance to exploit, hackers never think twice to use it.

[afwn90cj93201nixr2e1re]

This should be taken to server-side then

it's also possible now without any changes OP just don't wanna use it.

The amount of issues he posted have shown it's time to put the work to server development

Just shown that he is newbie in GoldSRC development.

Else these exploits he revealed will destroy the game sooner or later.

So, this "exploits"(which arent exploits at all, just engine limitations and bugs, which are also posted in some issues here(duplicate)) exists since 2000, seems like game still alive.

When there's a chance to exploit, hackers never think twice to use it.

Seems like you never find any exploits, kids - yes, hackers and ppls who found it - no, just testing and throwing to gabarage.

[Rainnegan]

Well, some people on surf or bhop servers will need more than 100 fps.

A cvar to set a limit for fps on the server-side it's the best option.

Yep!, sv_fps_limit or someting like that can be a good solution for all problems related to high fps.

[hashnimo]

sv_fps_limit or someting like that

Hmm, it doesn't seem to blend well with 2 underscores for some weird reason. Suggestion: sv_maxfps

[Rainnegan]

sv_fps_limit or someting like that

Hmm, it doesn't seem to blend well with 2 underscores for some weird reason. Suggestion: sv_maxfps

Really nice!, i adjunct two methods to detect client's FPS (just in case), obviously this can get better, but is just a idea:

new Float:gF_PreThinkTime[33]
new gL_ClientFPS[33]

public client_PreThink ( id )
{
    new Float:GameTime = get_gametime ( )
    gL_ClientFPS[id]++

    if ( gF_PreThinkTime[id] < GameTime )
    {
        server_print ( "FPS: %i", gL_ClientFPS[id] )
        gL_ClientFPS[id] = 0
        gF_PreThinkTime[id] = GameTime + 1.0
    }
}

new Float:gF_ClientFPS[33]

register_forward ( FM_CmdStart, "Fw_CmdStart", 0 )

public Fw_CmdStart ( const id, const uc_handle, const seed )
{
    new MSec = get_uc ( uc_handle, UC_Msec )

    gF_ClientFPS[id] = ( 1 / ( MSec * 0.001 ) )

    server_print ( "FPS: %f", gF_ClientFPS[id] )
}

[RauliTop]

Also, there are problems/bugs with low FPS values.

So, sv_maxfps and sv_minfps will be needed. Those server cvars will restrict fps_max (client), not player's FPS because that depends on his computer.

[Maxi605]

Players should be allowed to play on whatever fps they want, what we need to do is address how FPS are affecting gameplay, behavior should not change when people are on different FPS.

And so they should, but the administrator of the server should be able to decide. i get your point, it would be a cheap solution to the issue, but for the meantime it wouldn't be a bad solution.

[djearthquake]

Why not make video public instead of private? Least expensive CPU method: client fps_max query. https://github.com/djearthquake/amxx/blob/main/scripting/valve/fps_check_finale.sma. Experiment with lowering sv_maxvelocity.