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 loooong 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_smf&Itemid=26&topic=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
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
