[yuusuke]

Originally Posted by Natsheh sv_maxcmdrate 101 sv_mincmdrate 101 Limit the cmd rate then. Not sure how is this related to limit the fps.

HLDS doesn't have sv_cmdrate function, so server can't limit cl_cmdrate from clients.

The easiest way to prevent a client who is using fps_max 100.5+ is to check fps_override 1.

Client can't have fps=100.5+ on its display without fps_override 1.

[Napoleon_be]

Originally Posted by yuusuke HLDS doesn't have sv_cmdrate function, so server can't limit cl_cmdrate from clients. The easiest way to prevent a client who is using fps_max 100.5+ is to check fps_override 1. Client can't have fps=100.5+ on its display without fps_override 1.

Why would u wanna kick people with fps_override "1" but no higher FPS than 100.5?

You shouldn't be kicking people for that sole reason.

[yuusuke]

Originally Posted by Napoleon_be Why would u wanna kick people with fps_override "1" but no higher FPS than 100.5? You shouldn't be kicking people for that sole reason.

fps_max 300, cl_cmdrate 300, fps_override 1 = client sending 300 p/s (client's real FPS is 300.5, real packet rate is 300)
fps_max 300, cl_cmdrate 300, fps_override 0 = client sending 101 p/s (client's real FPS is 100.5, real packet rate is 101)
fps_max 300, cl_cmdrate 101, fps_override 1 = client sending 101 p/s (client's real FPS is 300.5, real packet rate is 101)
fps_max 100, cl_cmdrate 300, fps_override 1 = client sending 101 p/s (client's real FPS is 100.5, real packet rate is 101)

I don't wanna kick a client who has higher FPS on his display,
but when he has fps_max 300, fps_override 1, and cl_cmdrate 300 in the same time,
server will receive lots of flooding packets from him.

If I don't want clients to use high FPS, I will check fps_override.
If I don't want server to receive flooding packets, I need to check fps_max , fps_override, and cl_cmdrate.

[DJEarthQuake]

Originally Posted by yuusuke HLDS doesn't have sv_cmdrate function, so server can't limit cl_cmdrate from clients. The easiest way to prevent a client who is using fps_max 100.5+ is to check fps_override 1. Client can't have fps=100.5+ on its display without fps_override 1.

If one needs to kick on intent; here's the precursor approach. The spoiler has both styles.

https://forums.alliedmods.net/showpo...64&postcount=3

The no nonsense tell player where they stand on connect, kick now at the door. Otherwise later uncouthly on performance after they are already settled in. Both styles can be tested individually or simultaneously and clearly precursor is more efficient.

[ddag1]

Nice plugin! Can you please add a CVAR to enable/disable it?

[Natsheh]

Sure ill add the ability to unhook the functions when the plugin is paused.

[thEsp]

This plugin is dull and I'm surprised it wasn't unapproved. For once it's inaccurate, second it's been already made countless times, third the FPS issue most likely has to do with non-steam versions of the game.

[DJEarthQuake]

FPS has nothing to do with Steam or not.

[Natsheh]

Originally Posted by thEsp This plugin is dull and I'm surprised it wasn't unapproved. For once it's inaccurate, second it's been already made countless times, third the FPS issue most likely has to do with non-steam versions of the game.

1. Inaccurate how? The plugin checks the player fps each second with 99% correct rate.
2. If it has been made countless times post a link approving your doubts.
3. Nonsteam ? Read again the previous posts before posting some useless claims, i already said higher fps increases the forwards that are called depending on the user fps, which will increase the cpu run time.

[thEsp]

You must be so delusional to think your plugin is unique of some sort. Back in the day players had problems with high FPS rates where the player movement would deteriorate and the game would become choppy. Considering the fact non-steam servers usually run old versions of the game, that's one fair reason why somebody would want to limit their players' FPS. Anyway there's a reason why sys_ticrate exists.