Paul Peloski 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.
No, this could have been implemented without breaking backwards
compatibility. But I think we fundamentally disagree on the importance
of compatibility. I take Microsoft's stance - if someone writes code
against your API, it should work forever (think about why - you don't
want users mistrusting your platform or refusing to update for fear of
unknown breakage). Valve already does compatibility with 3rd party mods
nicely, just not with plugins. That's most likely why the '2' option
wasn't set to the default.
(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.
No, it doesn't. It's the correct implementation. If something is
handled by the server, and not the client, it only makes sense that the
server should be allowed to send and then receive its own trigger
(since, in theory, it could simply run the trigger regardless). One of
my plugins broke because it was doing just that, which is harmless since
it's not an actual client command.
(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.
Yes, it's their product, but that's got nothing to do with whether or
not people are satisfied with its changes. Eventually there will be a
breaking point when I walk away from Source and never think about coming
back. A few developers I know have already done this. Alas, it's
something we do in our free time, so it's not a big deal.
~dvander
http://www.bailopan.net/
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 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
