sv_pure

[Fluffy Frufflebottoms]

Sv_Pure will only work on servers which are not using custom mods. Just as sv_pure disables custom skins and textures, it also disables them server side also; in other words its basically like running a modded server that's broken and mod less.

Yes its possible to change this, but overall its not worth the time of handling it.

sv_pure, when set to 1, will check a whitelist file and determine which resources are permitted indiscriminately from the local client, which have to match those present on the server, and which have to be fetched from the Steam cache. I'm not familiar with using sv_pure for mod resources, but the '1' option seems as if it'd permit mods to function perfectly fine with the appropriate whitelist. Even if that isn't the case, regular materials, such as walls and prop skins, that are not altered by mods can almost certainly be restricted to stock by using sv_pure.

As far as time/benefit goes, crafting a fairly simple whitelist to fight people who cheat seems to me like it'd be worth the time.

[Rezel]

You have to look at it more objectively fluffy; let's first use lets say the zombiemod, or the gun game as an example - First off per mod you have on each of those servers you have to configure it so it will allow this particular mod to operate, now lets add that in with all the mods that are on each of the servers separately... It's a lot of work.

Secondly the server has to quarry more, meaning its more for it to handle, the Limitations are not with the processor but its with the SRCDS itself. The more you ask it to handle the more chance its going to crash and have issues. EVEN if we properly tested this to get it to be correct, it would take more time than its even worth. There's already enough crashing issues standing as it is, do we really want to destabilize it more just so we can rid of a few retarded skins?

We could definitely put it on the pub, but surely the gun game would not be worth the time. Zombie mod... Absolutely not.

[Sin]

Even more reason to put Pub #1 on it's own dedicated server. AMIRIGHT?!

[Rezel]

No, it would not help more as you have totally missed the point I'm trying to get across to you...

The flaws in the SRCDS ( Source Dedicated Server) will more than likely be the major cause to most of the issues on the server far before you even dampen the Hosting server. What would be the point of moving it to a new server if your just going to hit the same problem with the program that runs the pub.

[ZERO]

It may be possible for me to just allow everything except for particular things like:
All map textures
Weapon stuff for snipers

That would allow most custom stuff but remove the stuff at highest risk of being bad.

[Fluffy Frufflebottoms]

You have to look at it more objectively fluffy; let's first use lets say the zombiemod, or the gun game as an example - First off per mod you have on each of those servers you have to configure it so it will allow this particular mod to operate, now lets add that in with all the mods that are on each of the servers separately... It's a lot of work.

Secondly the server has to quarry more, meaning its more for it to handle, the Limitations are not with the processor but its with the SRCDS itself. The more you ask it to handle the more chance its going to crash and have issues. EVEN if we properly tested this to get it to be correct, it would take more time than its even worth. There's already enough crashing issues standing as it is, do we really want to destabilize it more just so we can rid of a few retarded skins?

We could definitely put it on the pub, but surely the gun game would not be worth the time. Zombie mod... Absolutely not.

I certainly am looking at it objectively. Resources for mods such as GunGame and ZombieMod are typically held in independent folders that can be exempt from cyclic redundancy checks, and even if the mods were messy, it'd be a matter of doing a directory diff between a clean installation and an installation with the mod, and exempting the changed files. It is at most ten minutes of work per server if it has to be done the hard way.

Additionally, the cyclic redundancy checks are not remarkably intensive. The hashes are calculated client-side, and sent to the server for comparison. If I recall correctly, the hashes for server resources are only performed when the server initially starts up. I understand that there are complexities when mods are involved, but I do think that you're grossly overestimating them.

It may be possible for me to just allow everything except for particular things like:
All map textures
Weapon stuff for snipers

That would allow most custom stuff but remove the stuff at highest risk of being bad.

I would personally prefer at least player skins added to that list, but I realise that some people put skins before just about everything else in this game. There certainly can't be any argument against checking for map and prop textures.

[Chikun]

It may be possible for me to just allow everything except for particular things like:
All map textures
Weapon stuff for snipers

That would allow most custom stuff but remove the stuff at highest risk of being bad.

How does the phrase go? The simplest answer is often the best answer?

[Rezel]

I am not grossly overestimating them, as I have had to deal with sv_pure many times before. Besides that you might end up loosing more people by doing that as most of us like custom skins. There is no real reason to do it, yeah someones going to use some cheap skins but compared to bigger fish its not really a big issue.

How does the phrase go? The simplest answer is often the best answer?

There's also K.I.S.S - Keep It Simple Stupid, but in this case you can just remove the Stupid.

[acolyte_to_jippity]

honestly, the only ones you should bother putting on the whitelist is map textures. nothing else. at all.

if someone is going to cheat w/ the snipers, then they could just as easy put a dot on their screen. it's not going to change anything.

[Steamer]

Map/prop textures over all. Everything else is just meh.
Agreed with the dot.
Less hacker catching.... QQ