Client Command Reset Plugin Released

[CSN NewsBot]

L. Duke, the man behind the VIP Mod for CS: Source, has done it again. His latest release will probably come as a God-send to a few server admins out there. His plugin forces the new client variable "cl_restrict_server_commands" to 0 when the connecting client has it locally set to 1.

Server admins can head on over to L. Duke's site to check out the plugin for themselves and to find a download link.

[DevgruSeal H.E]

Well that's just ironic. Executing "cl_restrict_server_commands 0" on a client who restricts server commands?



Also, just re-execute it back to 1 or 2 when in game, unless he blocked it from being changed...

[omgomgz]

Why would you want it at 0? I don't play CS.

[MikeJ]

If a server plugin is able to change a client command that is supposed to restrict server's from being able to change a client command, then the command is broken and valve needs to fix it or just remove it.

[Zips]

No, the cvar isn't broken. I saw the explanation as to how it works. There are still a few questions up in the air about it, however.

[FlyingMongoose]

The command isn't broken really. The command does what it's suppose to. When the cvar is enabled it doesn't allow some plugins to read information sent to them from the client since the plugin is requesting the information from the client.



Example: Map vote

Server displays a menu on the client, some plugins rely on client side code to show this, and it doesn't work because this cvar blocks it, so the map vote never goes through.



Example: Cvar-Blocking plugins (like CAL's old DSP, zBlock, and Cvar-X)

They request the information from the client so that it can find out if it's consistent with what's coded into the plugin. The cvar, if enabled blocks the request, causing these plugins to not be able to check the client and generally having them fail authentication with it, these plugins will generally kick or ban players who fail authentication.

[MikeJ]

Well, what I mean is, it's broken in a sense that if it can be bypassed by the server it's a completely irrelevant cvar to the client because it's now out of their control whether they want it enabled or disabled, which was the entire point of the cvar in the first place. I assume the plugin itself could be made to not give the client warning or notice first, if that's not the case then I guess I misunderstand how the plugin works.



Edit: I also assumed the command was also supposed to stop admins from changing cvars on the client like using admin_exec_client (or whatever it is) bind "mouse1" "kill" or "cl_restrict_server_commands 0" If not then I guess this is no different than a server enforcing cl_downloadfilter or something.

[IC dead people]

I agree this makes "cl_restrict_server_commands" useless (some would argue it already was).



Yet another reason to stick all your personal config in "1337_p1r47_N1Nj4!.cfg" and add it's exec to valve.rc or autoexec for HL1 (I think?)



More than one of my friends has been victim of immature admins abusing there role.

[Thortok2000]

How much you want to bet this functionality gets disabled real quick?

[-:Nighthawk:-]

I've always just write-protected my config.cfg file, and it's served me faithfully this long. Even if an admin feels like being abusive, the changes he or she makes disappear the next time I start CS up, and it doesn't break anything for the server.



The cvar change was a very poorly thought-out addition in the first place. With a little more consideration, any of these possibilities would have been far superior:

• Prompt: warn that functionality might be lost and/or they will be disconnected from server if this variable isn't set to allow running commands.
  
  
• Protect: allow running commands, but make them session-specific, and reset to initial values upon disconnect from server.
  
  
• Limit: only allow certain commands to be run, disallowing key-binding and other such intentional abuse.

But... this is VALVe we're talking about, and the quick-update Steam mentality has continued to be "make changes first, think about rammifications later."