This is why I think one of the sv_pure modes work the way I originally
asked.
No manipulation by lists plugin or admin, there would be no questioning as
the content would have to be from steam if default and allow from disk with
CRC if from a custom map.
This would not only benefits the competiti
--Off topic
This is truelly getting pathetic. I remember when source ran so smooth where
lag was fixable with rate scripts and admins had full control over there
servers. But ever since steam/valve started with there updates and the o' so
special cl_restrict_server_commands 1 crap ,it isnt even wo
--
[ Picked text/plain from multipart/alternative ]
This is my understanding of the problem
An unsavoury Server Adminsitrator could in theory, whitelist certain
textures as allowable, whilst still giving the apperance of being a pure
server. When server admin or players who are aware of changes to
This is true, it would have to be restrictive.. I'm not sure how it
would work. Perhaps it is best it be left untampered.
On 5/15/07, Keeper <[EMAIL PROTECTED]> wrote:
As a plugin maker, I request this not be "touchable" by us. The idea of
sv_pure would totally be useless if people such as myse
As a plugin maker, I request this not be "touchable" by us. The idea of
sv_pure would totally be useless if people such as myself were able to
"adjust" some of the pure settings. Some would argue that sv_pure 2 would
completely disable any interface for the plugins all together.
I also think it
This is exactly why I asked that sv_pure 2 work as if is default steam
content use steam if not in steam allow from disk and do CRC
That gives the players the knowledge of knowing the server is 1, using only
steam for all default content and 2, doing CRCs on any custom map content.
I feel the var
Hmm, okay.. will there be any interface or something of the sort that
allows plugins to toy with the pure mode system?
On 5/14/07, Jason Ruymen <[EMAIL PROTECTED]> wrote:
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Updates to the Source Dedica
Who said you were going to have a choice? As far as I have read Valve is
going to hard lock values and the client exec. Locking the values is long
over due, it is the client exec locking that I can not understand.
YMAC
On 5/15/07 1:45 AM, "Adam Sando" <[EMAIL PROTECTED]> wrote:
> Secondly, the
I concur. I personally know several people that are pissed at the moment.
Guess they'll have to actually learn how to do some of that stuff now ;)
Thanks for the help Valve!
Keeper
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adam Sando
Sent: Tuesday,
--
[ Picked text/plain from multipart/alternative ]
No you dont need the wait command for buyscripts, buyscripts operate
entirely without wait commands. Wait commands are usually used for recoil
control scripts or similar. As for color correction, even though its fairly
innocent in itself, you can
Ahh right, okay - thanks for clearing that up for me.
Matthias Wieloch wrote:
>From my little knowledge:
The "wait" command is usually used in buyscripts. But unfortunately you can
also find it in cheat scripts.
For the colorcorrection: I could imagine this being used for wallhacks.
So from my
>From my little knowledge:
The "wait" command is usually used in buyscripts. But unfortunately you can
also find it in cheat scripts.
For the colorcorrection: I could imagine this being used for wallhacks.
So from my point it's a good way to reduce cheating on a server.
Btw: can is someone still
Wow... How is that useful?
Jason Ruymen wrote:
- Added sv_allow_wait_command. If set to 0, then clients can't use
"wait"
- Added sv_allow_color_correction. If set to 0, then clients can't use
mat_colorcorrection
___
To unsubscribe, edit your list pref
13 matches
Mail list logo