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 to
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 the
