Re: [hlcoders] cl_restrict_server_commands fiasco
unbind all ? On 11/21/06, Mattie Casper [EMAIL PROTECTED] wrote: Identifying the individual commands to block is a hard problem, which makes me wonder if this isn't why Valve just went with the nuke switch regarding backwards compatibility and blocked everything. (Or perhaps they discovered a filesystem exploit in the field using the client's console. I doubt that, though, or this wouldn't have been optional.) When I tried to name off the individual commands that are simply too valuable not to have access to (connect, playgamesound, etc, etc), the list gets very long. In the end, it even included the infamous alias and bind commands. Even though these are evil commands for griefing players, for the very same reason, they're important for white hat administrators when they need to help newbies out. I run a number of newbie servers for my beta testing and I've found that new players have no grasp of the console and are very confused with how to bind anything custom or interesting (for stats, +jetpacks, etc). Giving the server access to help them bind (at their request) is an important tool we have to improve usability in the game. In addition, it's awfully helpful to get notified of +/- sorts of custom commands by creating, for example, a +jetpack alias on the client that sends the command to the server. In those cases, warning the user of the alias/bind (and allowing them to block it) would be an appropriate remedy. I wanted to respond before this thread died away completely, but this has really hurt the community in ways I couldn't have envisioned before. Typically, when Valve updates something major internally, it breaks things and plugin authors scramble to fix them. Often, the coders accept blame because they were using some unsupported trick or prying in areas Valve doesn't recommend. This time however, plugin authors are being blamed when they're using the supported commands they were given long ago. In the past, plugin writers have been yelled-at (by Valve even) when plugins doing unsupported things break lots of servers. Yet now everyone was using a supported API and with one flick of a switch, it was killed quietly without any nod to how impactful it would be. It's had a very dampening effect on the scripting community, blowing away swaths of popular scripts that relied, indirectly, on engine-ClientCommand(). True, the command is unreliable, it's risky, and half of its functionality works server-side, but that doesn't change the fact that it was heavily used in the field. As a platform, Source surely can't violate backwards compatibility like this without giving us some sort of new alternative (or identifying existing alternatives). Hopefully Valve will either unrestrict the most secure commands or code server-side replacements for those we've lost. At the very minimum, Valve should do better in communicating major regressions in backwards compatibility. If they can do that, it will at least prepare those gaming communities that stick around for the inevitable breaks. Best of luck, -Mattie http://mattie.info/cs/ - Original Message - From: David Anderson [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, November 18, 2006 1:18 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Yes, good point, that's unfortunate but true. I can't say I'm a good person to ask which commands, as I'm not very familiar with the client :) But I can take a guess that anything having to do with binds/aliases or client-side settings (i.e. cl_*) is fair game. I just think that at the very least, things that are sent from the server and aren't handled by the client should be properly passed back to the server. Obviously, users can use IServerPluginHelpers to simulate this, but I'm a big stickler for preserving backwards compatibility. Especially in this case when we're not even dealing with binary hacks. ~dvander http://www.bailopan.net/ Nick wrote: You have mentioned some good points. I am curious though which commands you would restrict? About it being default on, the problem is that users that know enough to enable cl_restrict_server_commands 1, are not the ones that need the command the most. The users that do not know how to set cl_restrict_server_commands 1 are the users that need it enabled the most. On 11/18/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like
Re: [hlcoders] cl_restrict_server_commands fiasco
Identifying the individual commands to block is a hard problem, which makes me wonder if this isn't why Valve just went with the nuke switch regarding backwards compatibility and blocked everything. (Or perhaps they discovered a filesystem exploit in the field using the client's console. I doubt that, though, or this wouldn't have been optional.) When I tried to name off the individual commands that are simply too valuable not to have access to (connect, playgamesound, etc, etc), the list gets very long. In the end, it even included the infamous alias and bind commands. Even though these are evil commands for griefing players, for the very same reason, they're important for white hat administrators when they need to help newbies out. I run a number of newbie servers for my beta testing and I've found that new players have no grasp of the console and are very confused with how to bind anything custom or interesting (for stats, +jetpacks, etc). Giving the server access to help them bind (at their request) is an important tool we have to improve usability in the game. In addition, it's awfully helpful to get notified of +/- sorts of custom commands by creating, for example, a +jetpack alias on the client that sends the command to the server. In those cases, warning the user of the alias/bind (and allowing them to block it) would be an appropriate remedy. I wanted to respond before this thread died away completely, but this has really hurt the community in ways I couldn't have envisioned before. Typically, when Valve updates something major internally, it breaks things and plugin authors scramble to fix them. Often, the coders accept blame because they were using some unsupported trick or prying in areas Valve doesn't recommend. This time however, plugin authors are being blamed when they're using the supported commands they were given long ago. In the past, plugin writers have been yelled-at (by Valve even) when plugins doing unsupported things break lots of servers. Yet now everyone was using a supported API and with one flick of a switch, it was killed quietly without any nod to how impactful it would be. It's had a very dampening effect on the scripting community, blowing away swaths of popular scripts that relied, indirectly, on engine-ClientCommand(). True, the command is unreliable, it's risky, and half of its functionality works server-side, but that doesn't change the fact that it was heavily used in the field. As a platform, Source surely can't violate backwards compatibility like this without giving us some sort of new alternative (or identifying existing alternatives). Hopefully Valve will either unrestrict the most secure commands or code server-side replacements for those we've lost. At the very minimum, Valve should do better in communicating major regressions in backwards compatibility. If they can do that, it will at least prepare those gaming communities that stick around for the inevitable breaks. Best of luck, -Mattie http://mattie.info/cs/ - Original Message - From: David Anderson [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, November 18, 2006 1:18 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Yes, good point, that's unfortunate but true. I can't say I'm a good person to ask which commands, as I'm not very familiar with the client :) But I can take a guess that anything having to do with binds/aliases or client-side settings (i.e. cl_*) is fair game. I just think that at the very least, things that are sent from the server and aren't handled by the client should be properly passed back to the server. Obviously, users can use IServerPluginHelpers to simulate this, but I'm a big stickler for preserving backwards compatibility. Especially in this case when we're not even dealing with binary hacks. ~dvander http://www.bailopan.net/ Nick wrote: You have mentioned some good points. I am curious though which commands you would restrict? About it being default on, the problem is that users that know enough to enable cl_restrict_server_commands 1, are not the ones that need the command the most. The users that do not know how to set cl_restrict_server_commands 1 are the users that need it enabled the most. On 11/18/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander
Re: [hlcoders] cl_restrict_server_commands fiasco
Hello, The function EmitSound is not ok for Quake sounds becouse the sound is located on an position... So when i play an sound like it gos 30 seconds and the player moves, he cant hear it... Is there no fonktion like the play command client side??? What can i do? Thanks! With friendly Reguards from Germany Ratman2000 - Original Message - From: David Anderson [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Sunday, November 19, 2006 7:55 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco You might want to look at public/engine/IEngineSound.h to do it manually. ~dvander http://www.bailopan.net/ Ratman2000 wrote: Hello, we cant use cvar-FindVar(convar)-SetValue(value); becouse its fully Server Side... The Problem is, that we cant force thinks like: play on client side to simple play an sound (mp3 file)... When we force the play command (i cant do any critical thinks with this command...) you become this message on client side: cl_restrict_server_commands (= 1) prevented server running command: play /ratmod/connect_sounds/admins/jesus.mp3 Why you have to block this command??? So what can we do to force the client to play sounds??? We havent an solution now... With friendly reguards from Germany Ratman2000 - Original Message - From: Adam amckern Mckern [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Sunday, November 19, 2006 4:06 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Why dont use just use cvar-FindVar(convar)-SetValue(value); I have been using it, becuase it allows you to hook around the sv_cheat flags that would block you with a stright engine-clientcommand. Adam --- LDuke [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I believe that is the exact command that is blocked by this cvar ( engine-ClientCommand( blahblah ) ). On 11/18/06, Nick [EMAIL PROTECTED] wrote: Can you list which exploits which need to be fixed? This question was asked earlier and I could not find a clear answer: Does this update break engine-ClientCommand( blahblah ) when done from server side dll? On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] (re: a) Obviously when Valve is attempting to fix a problem they are going to have to break compatibility with plugins/mods that rely on that problem behavior. Using this behavior as a workaround for client cvar exploits is bad because it has the effect of hiding the exploits when they need to be exposed and fixed. (re: b) cvars are already (or should be) divided into client and server, ranged to acceptable limits and in the extreme case marked FCVAR_CHEAT if they need to be set to a certain value for fair play. Adding further designation (like FCVAR_CLIENTPROTECT), or making lists breaks compatibility and masks exploits. (re: d) I agree it would be nice if Valve told us more about what's coming up, it might even be useful to them since our discussion might bring to light ... Nah, they're smarter than us, it's their product, and they can make competent decisions without us. Regards, Paul On 11/17/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice
Re: [hlcoders] cl_restrict_server_commands fiasco
-- [ Picked text/plain from multipart/alternative ] This is definitely a band-aid, not a fix. Here's one way to play a sound to all players (I think). enginesound-PrecacheSound(m_LoopSound, true); //m_LoopSound is char* pointing to location of sound file CRecipientFilter filter; filter.AddAllPlayers(); Vector x = pPLayer-GetAbsOrigin(); enginesound-EmitSound(filter, entindex(), CHAN_AUTO, m_LoopSound, 0.7, 0, 0, 100, x); On 11/19/06, Ratman2000 [EMAIL PROTECTED] wrote: Hello, The function EmitSound is not ok for Quake sounds becouse the sound is located on an position... So when i play an sound like it gos 30 seconds and the player moves, he cant hear it... Is there no fonktion like the play command client side??? What can i do? Thanks! With friendly Reguards from Germany Ratman2000 - Original Message - From: David Anderson [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Sunday, November 19, 2006 7:55 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco You might want to look at public/engine/IEngineSound.h to do it manually. ~dvander http://www.bailopan.net/ Ratman2000 wrote: Hello, we cant use cvar-FindVar(convar)-SetValue(value); becouse its fully Server Side... The Problem is, that we cant force thinks like: play on client side to simple play an sound (mp3 file)... When we force the play command (i cant do any critical thinks with this command...) you become this message on client side: cl_restrict_server_commands (= 1) prevented server running command: play /ratmod/connect_sounds/admins/jesus.mp3 Why you have to block this command??? So what can we do to force the client to play sounds??? We havent an solution now... With friendly reguards from Germany Ratman2000 - Original Message - From: Adam amckern Mckern [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Sunday, November 19, 2006 4:06 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Why dont use just use cvar-FindVar(convar)-SetValue(value); I have been using it, becuase it allows you to hook around the sv_cheat flags that would block you with a stright engine-clientcommand. Adam --- LDuke [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I believe that is the exact command that is blocked by this cvar ( engine-ClientCommand( blahblah ) ). On 11/18/06, Nick [EMAIL PROTECTED] wrote: Can you list which exploits which need to be fixed? This question was asked earlier and I could not find a clear answer: Does this update break engine-ClientCommand( blahblah ) when done from server side dll? On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] (re: a) Obviously when Valve is attempting to fix a problem they are going to have to break compatibility with plugins/mods that rely on that problem behavior. Using this behavior as a workaround for client cvar exploits is bad because it has the effect of hiding the exploits when they need to be exposed and fixed. (re: b) cvars are already (or should be) divided into client and server, ranged to acceptable limits and in the extreme case marked FCVAR_CHEAT if they need to be set to a certain value for fair play. Adding further designation (like FCVAR_CLIENTPROTECT), or making lists breaks compatibility and masks exploits. (re: d) I agree it would be nice if Valve told us more about what's coming up, it might even be useful to them since our discussion might bring to light ... Nah, they're smarter than us, it's their product, and they can make competent decisions without us. Regards, Paul On 11/17/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command
Re: [hlcoders] cl_restrict_server_commands fiasco
Hello, the problem is, that this function only *.wav files allows... I cant play *.mp3 files with this way :( Is there no other solution? With friendly reguards Ratman2000 - Original Message - From: Oliver [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Sunday, November 19, 2006 11:07 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco -- [ Picked text/plain from multipart/alternative ] This is definitely a band-aid, not a fix. Here's one way to play a sound to all players (I think). enginesound-PrecacheSound(m_LoopSound, true); //m_LoopSound is char* pointing to location of sound file CRecipientFilter filter; filter.AddAllPlayers(); Vector x = pPLayer-GetAbsOrigin(); enginesound-EmitSound(filter, entindex(), CHAN_AUTO, m_LoopSound, 0.7, 0, 0, 100, x); On 11/19/06, Ratman2000 [EMAIL PROTECTED] wrote: Hello, The function EmitSound is not ok for Quake sounds becouse the sound is located on an position... So when i play an sound like it gos 30 seconds and the player moves, he cant hear it... Is there no fonktion like the play command client side??? What can i do? Thanks! With friendly Reguards from Germany Ratman2000 - Original Message - From: David Anderson [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Sunday, November 19, 2006 7:55 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco You might want to look at public/engine/IEngineSound.h to do it manually. ~dvander http://www.bailopan.net/ Ratman2000 wrote: Hello, we cant use cvar-FindVar(convar)-SetValue(value); becouse its fully Server Side... The Problem is, that we cant force thinks like: play on client side to simple play an sound (mp3 file)... When we force the play command (i cant do any critical thinks with this command...) you become this message on client side: cl_restrict_server_commands (= 1) prevented server running command: play /ratmod/connect_sounds/admins/jesus.mp3 Why you have to block this command??? So what can we do to force the client to play sounds??? We havent an solution now... With friendly reguards from Germany Ratman2000 - Original Message - From: Adam amckern Mckern [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Sunday, November 19, 2006 4:06 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Why dont use just use cvar-FindVar(convar)-SetValue(value); I have been using it, becuase it allows you to hook around the sv_cheat flags that would block you with a stright engine-clientcommand. Adam --- LDuke [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I believe that is the exact command that is blocked by this cvar ( engine-ClientCommand( blahblah ) ). On 11/18/06, Nick [EMAIL PROTECTED] wrote: Can you list which exploits which need to be fixed? This question was asked earlier and I could not find a clear answer: Does this update break engine-ClientCommand( blahblah ) when done from server side dll? On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] (re: a) Obviously when Valve is attempting to fix a problem they are going to have to break compatibility with plugins/mods that rely on that problem behavior. Using this behavior as a workaround for client cvar exploits is bad because it has the effect of hiding the exploits when they need to be exposed and fixed. (re: b) cvars are already (or should be) divided into client and server, ranged to acceptable limits and in the extreme case marked FCVAR_CHEAT if they need to be set to a certain value for fair play. Adding further designation (like FCVAR_CLIENTPROTECT), or making lists breaks compatibility and masks exploits. (re: d) I agree it would be nice if Valve told us more about what's coming up, it might even be useful to them since our discussion might bring to light ... Nah, they're smarter than us, it's their product, and they can make competent decisions without us. Regards, Paul On 11/17/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net
RE: [hlcoders] cl_restrict_server_commands fiasco
First, my apologies for mis-posting my original message - I watch both [hlds] (the admin listserv) and this one - and I inadvertently posted to the wrong list. If you have not been following the other list, then you might not be fully aware of the dismay this update has caused, almost universally, in the admin community. Your point regarding the desirability of the vendor to correct exploitable cvars (and more) rather than rely on the mod developers is well taken. In fact, this point of view has been long expressed by the admin community. On the whole, the admin community has been consistent and persistent in its call to Valve to address many issues. Here is a snip from a typical posting: Players who cannot by hit because they have manipulated their rates to make them unhittable or refuse to use decent rates despite having 5ms pings and broadband connections Players who refuse to get flashed Players who can see through smoke Players who can see through transparent walls that the source engine allows Players who hit you more than a second after you have disappeared around the corner 33 tickrate servers being considered by Valve as the acceptable default server setup Most default CS SRCDS setting being completely crap A Valve approved API nobody uses because its completely useless Plugins that have to be used because Valve considers these issues should be dealt by plugin creators and on a per server operator basis, rather than doing anything about it themselves Could this list of issues that are significantly more important than server operators trying to bring some semblance of fairness to Counter-Strike:Source go on and on forever? You stated: If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Nothing would make the admin community happier than not to have to mess with 3rd party administrative tools, if Valve would only address the problems, which have been clearly identified for a very long time, as you say: out of the box. Admins do not relish having unannounced server updates dropped on them, then having to scramble to bring back their downed servers and watch their traffic go down, as the cheater and hackers run rampant. With respect to this update, it has been said, and I fully agree, that the Player should have the right to protect the settings on their computer when they join a server. Someone used a java analogy, on this list, which was quite apt. Equally though, the GSPs and hobbyists, who run the many servers which are foundational to the players' game experience, must be afforded the means to ensure fair and balanced play. If the underlying flaws in the game engine cannot be directly addressed, then admins can only apply the tools with which they are equipped. If all you are given is a hammer (pardon the pun), then all screws are nails. If the client's ability to adjust cvars to rate hack, see through walls, etc is fully within their control, then, equally, a means must be provided to the server operators to deny access to players who chose to do so. Valve sent out an update that gave choice to the player community - but negated efforts of the admin community to operate fair and balanced game servers and, in fact, actually broke many servers which were running mods. Mods, by the way, which are developed by THIS community. My criticism of Valve still stands. They have not responded to this issue nor publicly expressed any interest in addressing the situation or even having the courtesy to explain their rationale. I may be wrong in my assessment with respect to courage, on their part. But the lack of common courtesy and respect for one community, which keeps their products alive, is apparent and long-standing. Frazer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Peloski Sent: Friday, November 17, 2006 10:40 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] cl_restrict_server_commands fiasco -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your
Re: [hlcoders] cl_restrict_server_commands fiasco
Hello, is this new command in the engine or in the client.dll? I mean does it break all engine-ClientCommand( blahblah ) I do in my Mod's server.dll code without having a way to disable it in my code? For instance set the player model depending on what team they are on, and that changes cl_playermodel... And its used in Valve's own commentary system. That would be broken then, too. If it is the case, the client.dll can still change any clientside convar, right? If so, I would implement a user message that will do the exact same thing as engine-ClientCommand, and just bypass it. evil me. And can I still do engine-GetClientConVarValue() ? I'm a little confused if this actually affects mod .dlls or just server plugins. Regards, Octi - Original Message - From: Ratman2000 [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, November 18, 2006 8:46 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Hello, my biggest problem with the update is, that it brokes my Quake Sounds System... I have exect on the client the play command... But what can i now do??? =]-RS-[=Ratman2000 connected cl_restrict_server_commands (= 1) prevented server running command: play /ratmod/connect_sounds/tachmusik.mp3 Is there another way, to play the sound by the user??? I hope anybody can helps me! Thanks! With friendly reguards from Germany Ratman2000 - Original Message - From: David Anderson [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, November 18, 2006 8:18 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Yes, good point, that's unfortunate but true. I can't say I'm a good person to ask which commands, as I'm not very familiar with the client :) But I can take a guess that anything having to do with binds/aliases or client-side settings (i.e. cl_*) is fair game. I just think that at the very least, things that are sent from the server and aren't handled by the client should be properly passed back to the server. Obviously, users can use IServerPluginHelpers to simulate this, but I'm a big stickler for preserving backwards compatibility. Especially in this case when we're not even dealing with binary hacks. ~dvander http://www.bailopan.net/ Nick wrote: You have mentioned some good points. I am curious though which commands you would restrict? About it being default on, the problem is that users that know enough to enable cl_restrict_server_commands 1, are not the ones that need the command the most. The users that do not know how to set cl_restrict_server_commands 1 are the users that need it enabled the most. On 11/18/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards
RE: [hlcoders] cl_restrict_server_commands fiasco
P.S. I never called them morons. Frazer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frazer Sent: Saturday, November 18, 2006 9:50 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] cl_restrict_server_commands fiasco First, my apologies for mis-posting my original message - I watch both [hlds] (the admin listserv) and this one - and I inadvertently posted to the wrong list. If you have not been following the other list, then you might not be fully aware of the dismay this update has caused, almost universally, in the admin community. Your point regarding the desirability of the vendor to correct exploitable cvars (and more) rather than rely on the mod developers is well taken. In fact, this point of view has been long expressed by the admin community. On the whole, the admin community has been consistent and persistent in its call to Valve to address many issues. Here is a snip from a typical posting: Players who cannot by hit because they have manipulated their rates to make them unhittable or refuse to use decent rates despite having 5ms pings and broadband connections Players who refuse to get flashed Players who can see through smoke Players who can see through transparent walls that the source engine allows Players who hit you more than a second after you have disappeared around the corner 33 tickrate servers being considered by Valve as the acceptable default server setup Most default CS SRCDS setting being completely crap A Valve approved API nobody uses because its completely useless Plugins that have to be used because Valve considers these issues should be dealt by plugin creators and on a per server operator basis, rather than doing anything about it themselves Could this list of issues that are significantly more important than server operators trying to bring some semblance of fairness to Counter-Strike:Source go on and on forever? You stated: If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Nothing would make the admin community happier than not to have to mess with 3rd party administrative tools, if Valve would only address the problems, which have been clearly identified for a very long time, as you say: out of the box. Admins do not relish having unannounced server updates dropped on them, then having to scramble to bring back their downed servers and watch their traffic go down, as the cheater and hackers run rampant. With respect to this update, it has been said, and I fully agree, that the Player should have the right to protect the settings on their computer when they join a server. Someone used a java analogy, on this list, which was quite apt. Equally though, the GSPs and hobbyists, who run the many servers which are foundational to the players' game experience, must be afforded the means to ensure fair and balanced play. If the underlying flaws in the game engine cannot be directly addressed, then admins can only apply the tools with which they are equipped. If all you are given is a hammer (pardon the pun), then all screws are nails. If the client's ability to adjust cvars to rate hack, see through walls, etc is fully within their control, then, equally, a means must be provided to the server operators to deny access to players who chose to do so. Valve sent out an update that gave choice to the player community - but negated efforts of the admin community to operate fair and balanced game servers and, in fact, actually broke many servers which were running mods. Mods, by the way, which are developed by THIS community. My criticism of Valve still stands. They have not responded to this issue nor publicly expressed any interest in addressing the situation or even having the courtesy to explain their rationale. I may be wrong in my assessment with respect to courage, on their part. But the lack of common courtesy and respect for one community, which keeps their products alive, is apparent and long-standing. Frazer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Peloski Sent: Friday, November 17, 2006 10:40 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] cl_restrict_server_commands fiasco -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access
Re: [hlcoders] cl_restrict_server_commands fiasco
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] The cvar is client.dll thus the cl_ prefix. Jochen Werner wrote: Hello, is this new command in the engine or in the client.dll? I mean does it break all engine-ClientCommand( blahblah ) I do in my Mod's server.dll code without having a way to disable it in my code? For instance set the player model depending on what team they are on, and that changes cl_playermodel... And its used in Valve's own commentary system. That would be broken then, too. If it is the case, the client.dll can still change any clientside convar, right? If so, I would implement a user message that will do the exact same thing as engine-ClientCommand, and just bypass it. evil me. And can I still do engine-GetClientConVarValue() ? I'm a little confused if this actually affects mod .dlls or just server plugins. Regards, Octi - Original Message - From: Ratman2000 [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, November 18, 2006 8:46 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Hello, my biggest problem with the update is, that it brokes my Quake Sounds System... I have exect on the client the play command... But what can i now do??? =]-RS-[=Ratman2000 connected cl_restrict_server_commands (= 1) prevented server running command: play /ratmod/connect_sounds/tachmusik.mp3 Is there another way, to play the sound by the user??? I hope anybody can helps me! Thanks! With friendly reguards from Germany Ratman2000 - Original Message - From: David Anderson [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, November 18, 2006 8:18 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Yes, good point, that's unfortunate but true. I can't say I'm a good person to ask which commands, as I'm not very familiar with the client :) But I can take a guess that anything having to do with binds/aliases or client-side settings (i.e. cl_*) is fair game. I just think that at the very least, things that are sent from the server and aren't handled by the client should be properly passed back to the server. Obviously, users can use IServerPluginHelpers to simulate this, but I'm a big stickler for preserving backwards compatibility. Especially in this case when we're not even dealing with binary hacks. ~dvander http://www.bailopan.net/ Nick wrote: You have mentioned some good points. I am curious though which commands you would restrict? About it being default on, the problem is that users that know enough to enable cl_restrict_server_commands 1, are not the ones that need the command the most. The users that do not know how to set cl_restrict_server_commands 1 are the users that need it enabled the most. On 11/18/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul
Re: [hlcoders] cl_restrict_server_commands fiasco
-- [ Picked text/plain from multipart/alternative ] (re: a) Obviously when Valve is attempting to fix a problem they are going to have to break compatibility with plugins/mods that rely on that problem behavior. Using this behavior as a workaround for client cvar exploits is bad because it has the effect of hiding the exploits when they need to be exposed and fixed. (re: b) cvars are already (or should be) divided into client and server, ranged to acceptable limits and in the extreme case marked FCVAR_CHEAT if they need to be set to a certain value for fair play. Adding further designation (like FCVAR_CLIENTPROTECT), or making lists breaks compatibility and masks exploits. (re: d) I agree it would be nice if Valve told us more about what's coming up, it might even be useful to them since our discussion might bring to light ... Nah, they're smarter than us, it's their product, and they can make competent decisions without us. Regards, Paul On 11/17/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- - Benjamin Davison -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list
Re: [hlcoders] cl_restrict_server_commands fiasco
Can you list which exploits which need to be fixed? This question was asked earlier and I could not find a clear answer: Does this update break engine-ClientCommand( blahblah ) when done from server side dll? On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] (re: a) Obviously when Valve is attempting to fix a problem they are going to have to break compatibility with plugins/mods that rely on that problem behavior. Using this behavior as a workaround for client cvar exploits is bad because it has the effect of hiding the exploits when they need to be exposed and fixed. (re: b) cvars are already (or should be) divided into client and server, ranged to acceptable limits and in the extreme case marked FCVAR_CHEAT if they need to be set to a certain value for fair play. Adding further designation (like FCVAR_CLIENTPROTECT), or making lists breaks compatibility and masks exploits. (re: d) I agree it would be nice if Valve told us more about what's coming up, it might even be useful to them since our discussion might bring to light ... Nah, they're smarter than us, it's their product, and they can make competent decisions without us. Regards, Paul On 11/17/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- - Benjamin Davison -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
-- [ Picked text/plain from multipart/alternative ] I believe that is the exact command that is blocked by this cvar ( engine-ClientCommand( blahblah ) ). On 11/18/06, Nick [EMAIL PROTECTED] wrote: Can you list which exploits which need to be fixed? This question was asked earlier and I could not find a clear answer: Does this update break engine-ClientCommand( blahblah ) when done from server side dll? On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] (re: a) Obviously when Valve is attempting to fix a problem they are going to have to break compatibility with plugins/mods that rely on that problem behavior. Using this behavior as a workaround for client cvar exploits is bad because it has the effect of hiding the exploits when they need to be exposed and fixed. (re: b) cvars are already (or should be) divided into client and server, ranged to acceptable limits and in the extreme case marked FCVAR_CHEAT if they need to be set to a certain value for fair play. Adding further designation (like FCVAR_CLIENTPROTECT), or making lists breaks compatibility and masks exploits. (re: d) I agree it would be nice if Valve told us more about what's coming up, it might even be useful to them since our discussion might bring to light ... Nah, they're smarter than us, it's their product, and they can make competent decisions without us. Regards, Paul On 11/17/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit:
Re: [hlcoders] cl_restrict_server_commands fiasco
Why dont use just use cvar-FindVar(convar)-SetValue(value); I have been using it, becuase it allows you to hook around the sv_cheat flags that would block you with a stright engine-clientcommand. Adam --- LDuke [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I believe that is the exact command that is blocked by this cvar ( engine-ClientCommand( blahblah ) ). On 11/18/06, Nick [EMAIL PROTECTED] wrote: Can you list which exploits which need to be fixed? This question was asked earlier and I could not find a clear answer: Does this update break engine-ClientCommand( blahblah ) when done from server side dll? On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] (re: a) Obviously when Valve is attempting to fix a problem they are going to have to break compatibility with plugins/mods that rely on that problem behavior. Using this behavior as a workaround for client cvar exploits is bad because it has the effect of hiding the exploits when they need to be exposed and fixed. (re: b) cvars are already (or should be) divided into client and server, ranged to acceptable limits and in the extreme case marked FCVAR_CHEAT if they need to be set to a certain value for fair play. Adding further designation (like FCVAR_CLIENTPROTECT), or making lists breaks compatibility and masks exploits. (re: d) I agree it would be nice if Valve told us more about what's coming up, it might even be useful to them since our discussion might bring to light ... Nah, they're smarter than us, it's their product, and they can make competent decisions without us. Regards, Paul On 11/17/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy
Re: [hlcoders] cl_restrict_server_commands fiasco
You might want to look at public/engine/IEngineSound.h to do it manually. ~dvander http://www.bailopan.net/ Ratman2000 wrote: Hello, we cant use cvar-FindVar(convar)-SetValue(value); becouse its fully Server Side... The Problem is, that we cant force thinks like: play on client side to simple play an sound (mp3 file)... When we force the play command (i cant do any critical thinks with this command...) you become this message on client side: cl_restrict_server_commands (= 1) prevented server running command: play /ratmod/connect_sounds/admins/jesus.mp3 Why you have to block this command??? So what can we do to force the client to play sounds??? We havent an solution now... With friendly reguards from Germany Ratman2000 - Original Message - From: Adam amckern Mckern [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Sunday, November 19, 2006 4:06 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Why dont use just use cvar-FindVar(convar)-SetValue(value); I have been using it, becuase it allows you to hook around the sv_cheat flags that would block you with a stright engine-clientcommand. Adam --- LDuke [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I believe that is the exact command that is blocked by this cvar ( engine-ClientCommand( blahblah ) ). On 11/18/06, Nick [EMAIL PROTECTED] wrote: Can you list which exploits which need to be fixed? This question was asked earlier and I could not find a clear answer: Does this update break engine-ClientCommand( blahblah ) when done from server side dll? On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] (re: a) Obviously when Valve is attempting to fix a problem they are going to have to break compatibility with plugins/mods that rely on that problem behavior. Using this behavior as a workaround for client cvar exploits is bad because it has the effect of hiding the exploits when they need to be exposed and fixed. (re: b) cvars are already (or should be) divided into client and server, ranged to acceptable limits and in the extreme case marked FCVAR_CHEAT if they need to be set to a certain value for fair play. Adding further designation (like FCVAR_CLIENTPROTECT), or making lists breaks compatibility and masks exploits. (re: d) I agree it would be nice if Valve told us more about what's coming up, it might even be useful to them since our discussion might bring to light ... Nah, they're smarter than us, it's their product, and they can make competent decisions without us. Regards, Paul On 11/17/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting
[hlcoders] cl_restrict_server_commands fiasco
For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
Your link is broken. The correct link is http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=3303.15; On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
I dont understand why you sending it to the coders mail list - if you want to talk to valve email them directly, you can find there contact addreses on the VDC. Adam --- Nick [EMAIL PROTECTED] wrote: Your link is broken. The correct link is http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=3303.15; On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Nigredo Studios http://www.nigredostudios.com Sponsored Link Mortgage rates near 39yr lows. $510k for $1,698/mo. Calculate new payment! www.LowerMyBills.com/lre ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
Frazer wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 For anyone who has'nt seen this, Valve have added the command : cl_restrict_server_commands Which makes it impossible for any plugin to carry out changes to client variables... This means rate hackers will now have free reign as we cannot change their rates, we probably won't even be able to detect what they are set to. It also means you cannot set sounds, skins or anything else which involves client exec. To me this seems analogous to blocking JavaScript in my web browser. If I don't want some server admin screwing with my settings, I should have the ability to control what someone else does to my machine. You, as a server operator, are free to prevent anyone from joining your server, so assuming you have the ability to retrieve the value of this cvar from the client, you would be able to control who plays on your server. It sounds like Valve gave customers the ability to restrict an exploit in their game. I would bet there are an order of magnitude more servers running straight vanilla CS or DoD code on them than there are servers running plugins that modify customer's settings. If Valve wants to protect a customer's machine from being modified by some unknown server that they connect to, why shouldn't that be the default option? People that want to connect to servers that modify the customer's settings can be told how to disable this cvar. -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
-- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
-- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- - Benjamin Davison -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- - Benjamin Davison -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
You have mentioned some good points. I am curious though which commands you would restrict? About it being default on, the problem is that users that know enough to enable cl_restrict_server_commands 1, are not the ones that need the command the most. The users that do not know how to set cl_restrict_server_commands 1 are the users that need it enabled the most. On 11/18/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- - Benjamin Davison -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
Yes, good point, that's unfortunate but true. I can't say I'm a good person to ask which commands, as I'm not very familiar with the client :) But I can take a guess that anything having to do with binds/aliases or client-side settings (i.e. cl_*) is fair game. I just think that at the very least, things that are sent from the server and aren't handled by the client should be properly passed back to the server. Obviously, users can use IServerPluginHelpers to simulate this, but I'm a big stickler for preserving backwards compatibility. Especially in this case when we're not even dealing with binary hacks. ~dvander http://www.bailopan.net/ Nick wrote: You have mentioned some good points. I am curious though which commands you would restrict? About it being default on, the problem is that users that know enough to enable cl_restrict_server_commands 1, are not the ones that need the command the most. The users that do not know how to set cl_restrict_server_commands 1 are the users that need it enabled the most. On 11/18/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- - Benjamin Davison -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives,
Re: [hlcoders] cl_restrict_server_commands fiasco
Hello, my biggest problem with the update is, that it brokes my Quake Sounds System... I have exect on the client the play command... But what can i now do??? =]-RS-[=Ratman2000 connected cl_restrict_server_commands (= 1) prevented server running command: play /ratmod/connect_sounds/tachmusik.mp3 Is there another way, to play the sound by the user??? I hope anybody can helps me! Thanks! With friendly reguards from Germany Ratman2000 - Original Message - From: David Anderson [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, November 18, 2006 8:18 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Yes, good point, that's unfortunate but true. I can't say I'm a good person to ask which commands, as I'm not very familiar with the client :) But I can take a guess that anything having to do with binds/aliases or client-side settings (i.e. cl_*) is fair game. I just think that at the very least, things that are sent from the server and aren't handled by the client should be properly passed back to the server. Obviously, users can use IServerPluginHelpers to simulate this, but I'm a big stickler for preserving backwards compatibility. Especially in this case when we're not even dealing with binary hacks. ~dvander http://www.bailopan.net/ Nick wrote: You have mentioned some good points. I am curious though which commands you would restrict? About it being default on, the problem is that users that know enough to enable cl_restrict_server_commands 1, are not the ones that need the command the most. The users that do not know how to set cl_restrict_server_commands 1 are the users that need it enabled the most. On 11/18/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your