[rtcw.co.uk logo] homelink


Cvar Restrictions

Contents

Introduction
Tweaking vs. Cheating
Cvar Unlockers
ETPro Mod
Recommended Cvar Restrictions
Dubious Cvar Restrictions
100% Pointless checks
Conclusion
Further Reading / Bibliography

Introduction

This page is to outline and explain cvar restrictions recommended for Enemy Territory - why I recommend them and why other checks frequently used are not useful - or may even cause problems unnecessarily. Explanation and background is given for common misconceptions regarding cvar "tweaking", and an attempt is made to address the wide range of attitudes and views on the subject.

Other than the cvars listed here, I'm not aware of any other possible cvar "exploits" - veterans of RTCW and other games based on the Quake3 engine should bear in mind ET is a different game and many cvars are either removed or are restricted in the gamecode. Hacking aside, what constitutes cheating or an unfair advantage is often subjective and open to personal opinion, with a wide scale of grey area and differing views.

I am not going to go through all the tweaks for improving fps or anything else. This article is only interested in cvar restrictions which I use on the RTCW.co.uk servers and believe other admins should consider for their servers or competitions. Naturally this also means explaining why some other frequently used restrictions are not recommended.

I am not going to explain the PB cvar restriction system, it is already done perfectly well in the "Punkbuster for Server Admins" help document provided, an (updated) online version of which can be found on the Evenbalance website.

The settings here are public server orientated, with notes regarding clanwar settings. The only area I would consider changing for clanwar settings is perhaps to require higher rate and cl_maxpackets settings, since modem players are uncommon in tournaments and anyway such players are far more likely to be knowledgeable enough to alter their settings.



Tweaking vs. Cheating


There is some confusion that if someone is modifying cvars, they must be cheating. You modify cvars when you set the options in the ingame menu's - most tweaking in ET is actually just setting those same settings, but using the .cfg file instead. You also change cvar settings when you change team, change class, change weapon... All these things are settings (variables) and hence use cvars.

The most important thing to remember is no matter how different or ugly the view may be, this is irrelevant. What other players have to put up with is of absolutely no concern, all that does matter is wether they actually have a significant unfair advantage. After the first couple of days, for many people eye-candy ceases to be exciting and gameplay -- smooth and playable FPS -- becomes all that matters, and this is what most "tweaking" or "cfg" is about. In most games, the various forms of brightness is the other main reason, but in ET really you can see everything there is to see via ingame settings. Certain cvars however can be used for what is irrefutably cheating, any argument that "if its not an external hack it's not cheating" is clearly nonsense from people who are not aware what is actually possible with game cvars.

Screenshots of various brightness settings can seem quite dramatic, but if you look more carefully there's rarely anything to see that would go unnoticed when using ingame settings. Further, there are many ways to change brightness without using ingame cvars: driver settings, monitor settings and legitimate external programs. Different hardware (particularily video card, driver version and monitor) result in different screen brightnesses, so even a screenshot from one player may look much more bright or dark on another computer - and lets not forget about the strong jpeg image compression. The provided screenshots are all taken with settings somewhat similar to what would likely be used by a "tweaker", a fairly bright display with close to minimal graphics settings. This usually means they show something approaching a worst-case scenario.

However, it is important to emphasise that I'm not interested in trying to argue the whole "tweakers vs cheaters" thing either way. These "dabates" just go on and on forever and rarely gets solved for more than a day. Even if you care to take a more restrictive approach to settings, the explanations here are useful as information.



Cvar Unlockers

In ET, some cvars are cheat-protected by the game, meaning clients (players) should not be able to change them manually, or sometimes only to within a specific range. These differ from hardcoded cvars, which are restricted in the engine and setting them outside of range has no effect - all that will happen is the game will use the closest allowed value, for example r_picmip is hardcoded to between 0 and 3, if you try to set a value of 5 the game will simply use it as 3.

There has been hacks released which bypass the game's cheat-cvar protection, enabling cheaters to use the cvars. There is rather a lot of these cvars, it is not plausable or practical to restrict them all. Cheat-cvar abuse is pretty trivial compared to using other hacks available on the same cheater sites, and regardless unlockers have long since fallen out of interest on them. If you wish to restrict cheat-protected cvars, some suggested ones are provided. I dont think it is worthwhile to generally recommend restricting them though.

By default Punkbuster restricts certain cvars, but only a few - r_showNormals and cg_thirdperson for example. They also do detect some unlocker hacks. Players using hacked ET.exe's can potentially be picked up using the MD5Tool, but you need to set it to examine the exact place where the hacked file differs from the genuine one. ETPro, at time of writing anyway, does not further restrict any locked cvars, with the exception of those relating to tracers.

Note you should not ban players who are kicked for any cvar violations, and this includes locked cvars being out of range. As mentioned, it is often possible (without hacks) to set the locked cvars outside of range but they will actually function only to the nearest allowed value. Both PB and ETPro's methods of cvar restrictions are highly effective and there is no concern that a player can return with an undetected unlocker and go cheating. Also, you have to be very cautious setting restrictions on locked cvars, as often they are changed by the game engine, so you cannot simply go through them all setting PB to kick if any are not at the default value.



ETPro Mod & Cvar restrictions


When using ETPro modification (version 3 and later), you can use Punkbuster cvar restrictions as normal. However ETPro offers an alternative method which may be preffered. Broadly, ETPro's system has similar functionality but instead of just kicking player's out of the server for having a restricted cvar at the wrong setting, it will instead change the setting to the nearest "allowed" value. More information, including explanation of syntax can be found on the ETPro forum.

When using ETPro, an extra precaution to take is to check you are not restricting cvars that are being 'forced' on the client by the server configuration. For example, it is not uncommon for servers to have set forcecvar r_drawfoliage 0, with this of course you must avoid also restricting the cvar to a different setting.

Something else that should be considered is ETPro has changed some of the coding, and for example the connection settings are less easily abused to cause the player to warp. However, none of the restrictions recommended here will give any problems wether ETPro is used or not, so you can consider them optional - that is, provided b_antiwarp is set to 1 on the server.



Recommended Cvar Restrictions

Game Versions: recommendations refer to usage of ET2.60, the latest patched version of Enemy Territory. The ETPro restrictions relate to usage of ETPro 3.2.0. Older versions do not need to omit any of these restrictions, however please consult other sections for a few possible additions.


  • Using Punkbuster:

    pb_sv_cvar rate IN 2500 25000
    pb_sv_cvar snaps IN 20 40
    pb_sv_cvar cl_maxpackets IN 15 100
    pb_sv_cvar cl_timenudge IN 0
    pb_sv_cvar cl_freelook IN 1
    pb_sv_cvar cl_yawspeed IN 0 140
    pb_sv_cvar cl_pitchspeed IN 0 140
    pb_sv_cvar m_pitch OUT -0.015 0.015
    pb_sv_cvar m_yaw IN -0.022 0.022
    pb_sv_cvar cg_bobup IN 0 0.005
    pb_sv_cvar cg_shadows IN 0 1
    pb_sv_cvar cg_fov IN 90 125
    pb_sv_cvar r_flares IN 0 1
    pb_sv_cvar r_primitives IN 0 2
    pb_sv_cvar r_nv_fogdist_mode INCLUDE NV
    pb_sv_cvar r_clamptoedge IN 1

    // See Also: pb_sv_cvar r_detailTextures IN 0
    // Optionally also, to double-protect cheat cvars:
    pb_sv_cvar r_drawworld IN 1
    pb_sv_cvar r_drawfoliage IN 1
    pb_sv_cvar r_znear IN 3
    pb_sv_cvar r_showtris IN 0
    pb_sv_cvar r_drawentities IN 1
    pb_sv_cvar r_showmodelbounds IN 0
    pb_sv_cvar r_lightmap IN 0
    pb_sv_cvar cg_tracerlength IN 160
    pb_sv_cvar cg_tracerSpeed IN 4500
    pb_sV_cvar cg_tracerwidth IN 0.8
    pb_sv_cvar cg_tracerchance IN 0.4
  • Using ETPro cvar restrictions:

    sv_cvar rate IN 3200 25000
    sv_cvar snaps IN 20 40
    sv_cvar cl_maxpackets IN 20 100
    sv_cvar cl_timenudge EQ 0
    sv_cvar cl_freelook EQ 1
    sv_cvar m_pitch OUT -0.015 0.015
    sv_cvar m_yaw IN -0.022 0.022
    sv_cvar cg_bobup IN 0 0.005
    sv_cvar cg_shadows IN 0 1
    sv_cvar cg_fov IN 90 125
    sv_cvar r_flares IN 0 1
    sv_cvar r_primitives IN 0 2
    sv_cvar r_nv_fogdist_mode INCLUDE NV GL_EYE_RADIAL_NV
    sv_cvar r_detailTextures EQ 0
    sv_cvar r_clamptoedge EQ 1

    // Optionally also, to double-protect cheat cvars:
    sv_cvar r_drawworld EQ 1
    sv_cvar r_drawfoliage EQ 1
    sv_cvar r_znear EQ 3
    sv_cvar r_showtris EQ 0
    sv_cvar r_drawentities EQ 1
    sv_cvar r_showmodelbounds EQ 0
    sv_cvar r_lightmap EQ 0



    Usage Note: when using the ETPro restriction system via a .config file,
    use the following syntax:
    command "sv_cvar rate IN 3200 25000"


  • pb_sv_cvar rate IN 2500 25000

    Players using a setting below 2500 will be very jerky and possibly forcing warping or making themselves very hard to hit. 2500 is the default for 56k modems and really is very low, a 56k modemer should really try 3000 even on a poor 4kps connection to get better gameplay. Maybe more of an issue is scripts setup to change between rate settings, using a low setting while reloading to minimise weakness. 25000 is the upper limit as the Q3 code itself has a cap of 25000. A broad range of rate settings are therefore allowed to cover all those perfectly reasonable while not allowing those which are unnecessary.

    Clan-related organisations should consider 3000 at a minimum, or if you would rather have players who have at least an ISDN-equivalent connection, then 5000 should be the lower value, to allow some room for low-quality voice comms. 56k players can play fine (better!) with rate 3000, but on a public you cannot really expect these players to have a clue about changing the default connection settings by opening the console and typing in commands.

    Note another possible misuse of the connection settings is to make ping look very bad, in order to demand clanwar takes place on a server where they have an advantage, rather than the one best overall.

    Note: connection setting restrictions are possibly unnecessary for servers running ETPro with b_antiwarp 1. These restrictions should not cause any negative side effects however. Further, a large portion of players perceive issues with low connection settings, so it's probably a good idea to leave them on even if just to hedge your bets, satisfy ignorance or whatever.

    Revision, 22/4/5: increased the minimum rate to 3200 for ETPro restrictions only. This should be fine for 56k modem and ETPro's restriction system will automatically correct any lower values, so this restriction range not allowing for a default value should not be any problem. I'd suggest 7000 for public servers if you don't care about 56k players or ISDN'ers having voice comms.


    pb_sv_cvar snaps IN 20 40

    Snaps should only be 20 or 40, nothing else makes any sense to use (see exception, below). If you want to know what snaps actually does, lets quote reyalP, who is also backed up by Bani and Rain in this convenient thread:

    Snaps is how many snapshots you want the server to send you, per second. The server can only generate a snap each server frame, since a snap is defined by the state generated in the server frame. So for the server to send you more than sv_fps snaps wouldn't make any sense. Now, the ET code has bee known to do things that don't make sense, but if it did something dumb like sending you 2 identical snaps per frame, it should show up in network traffic and likely weirdness on your client. By observation, it doesn't.

    Since sv_fps should definately always be left as 20, it only makes sense for players to use snaps at 20.

    [...] there will definitely be problems (some not necessarily visible) if sv_fps is not set to 20. We definitely now recommend that all servers (especially league servers) run with sv_fps 20 set.
    - SD lead game designer Loki

    However many players do state a preference for snaps 40 (perhaps due to the placebo effect). The worst possible effect of snaps 40 is duplication of transmissions, which would eat up a bit more rate allowance, and ping information on the scoreboard can become even more incorrect (scoreboard pings are very unreliable and easily manipulated, they are calculated and not simple results of an OS 'ping' command). None of this is a real problem for anyone else so you might as well let them use it, although for competition use it may be smart to require snaps of 20 when teams are checking servers for acceptable connections (just check this via /players output).

    If your server specifically caters for 56k dialup users, you might want to except the norm and allow snaps of 10. This setting is overly warpy for normal servers (and dialup users should still be able to use 20 without problem), but 10 may play better for 56k as it results in a lower bandwidth usage, the primary issue for such connections.

    I am aware of various supposed literatire on the topic giving various contrasting explanations of snaps, most of which also contradict each other:

    According to the Keen cvar page, which for starters is Quake3, says "server run[s] at 40Hz, so use 40, 20, or 10". Another interpretation which basically amounts to the same thing as far as this article is concerned is that sv_fps is always set to 20, and the client's snaps should be a multiple of the server's sv_fps, see Upset Chaps. A further interpretation says client's actual snaps will reduce (but cannot increase) to server's sv_fps, so players who have the bandwidth should set snaps 40 even if a server has set sv_fps to 30, for example (dig around here for info). I'm yet to see a Wolf server running sv_fps at anything other than 20 however, if you DO change it on your server then consider setting pb_cvar snaps IN 40, maybe, but expect a lot of players to be getting kicked.

    Even if you subscribe to these Quake3 snaps explanations, there is a common denominator which still results in there being no apparent reason for players to use a snaps setting other than 20 or 40.

    ETPro Note: connection setting restrictions are possibly unnecessary for servers running ETPro with b_antiwarp 1. These restrictions should not cause any negative side effects however. Further, a large portion of players perceive issues with low connection settings even with b_antiwarp, so it's a good idea to leave them on even if just to hedge your bets, satisfy ignorance or whatever.



    pb_sv_cvar cl_maxpackets IN 15 100

    A third connection setting, and again the reasons are associated with laggy, warping players. the maxpackets setting, as the name suggests, sets "set the transmission packet size or how many packets are sent to client" (Keen). The higher your maxpackets, the more is sent and the smaller each packet of data is - hence, the more frequently they arrive. Each packet however wastes some of your rate in the form of for example packet headers, so players on a low rate setting (modemers) should have a fairly low cl_maxpackets setting. Since the packets go both ways, players on low maxpackets will not only find other players are jerky to them, but all other players will also find this player to have jerky movements, which can make them hard to shoot. If that sounds reasonably easy to understand, there's a contradictory explanation of cl_maxpackets on Upset Chaps, but the end result is still cl_maxpackets IN 15 100: "the default setting for cl_maxpackets is 30, usable range is 15 to 100 on the Internet", although there is a caveat in what appears to be an edited update "maximum 125 under [Q3] point release 1.32 or above", and ET does appear to include the Q3 engine update related to Q3 1.32 point release.

    Whichever you buy into, 15 is the default setting for "modem", and there is no good reason for any players to use a lower setting, infact most modem players should try a higher setting to around 20-30 anyway, and see if it works better for them. In a cup or league environment where good connections are more important -- and players are much more likely to have them -- cl_maxpackets IN 30 100 is probably a better setting, although an upper limit of 125 is arguable. Modem players participating in clan play are also likely to understand how to adjust their settings appropriately.

    Note the punkbuster.cfg provided with ET suggests IN -15 100: the -15 can safely be assumed to be a typo!

    Note: connection setting restrictions are possibly unnecessary for servers running ETPro with b_antiwarp 1. These restrictions should not cause any negative side effects however. Further, a large portion of players perceive issues with low connection settings, so it's probably a good idea to leave them on even if just to hedge your bets, satisfy ignorance or whatever.

    Revision, 22/4/5: increased minimum to 20, to equal server snapshot frequency. I'd only recommend this by default when using ETPro's cvar restriction system however, since a default setting is outwith this range (ETPro will adjust the cvar for the client).


    pb_sv_cvar cl_timenudge IN 0

    Timenudge can be unpredictable when set positive or too much negative. In theory should not have any affect upon how they appear on other player's screens or indeed the server, but no reason in any case to have this cvar set to something outside -50 to 0. See Alternate Fire's Unlagged FAQ to clear up some misgivings about timenudge, if you want to take their word for it. Upset Chaps also describes timenudge as "client side prediction", with no hint that this setting can affect other players in any way. Excessive info (if you're inclined to presume it is remotely accurate) on timenudge can also be found in this document which at first glance appears to claim to all be written by arQon, but on closer inspection it seems only the lower part is and that the top part is someone else's interpretation based on that. Going on the Unlagged FAQ, allowing -30 to 0 actually seems most sensible use for tweakers, but there doesnt seem to be any real issues with -50 to 0 either.

    However, before you get lost in the myrad of conflicting crap about timenudge, be aware that in ET the norm is for servers to enable antilag coding. This coding compensates for the player's ping, and does it well. Although the way it works is not particularily significant, only how effective is significant, I am led to beleive that whereas normally it would assume all actions are taking place at the moment it is performing the relevant calculations, it instead calculates based upon the assumption that data it receives is at least "ping" duration late.

    If you bothered to read anything about timenudge, you've probably realised Antilag makes "tn" somewhat redundant. Players should not use timenudge on antilag servers, as there would be timenudge prediction on top of the ping compensation of antilag. Combine this with the widespread perception (prejudice?) that timenudge can be used to cause the player to warp in a matter difficult to shoot at -- a perception that conveniently ignores the fact that any player is more likely to use timenudge as a result of a poor 'net connection, rather than to cause one -- and the suggestion is therefore to restrict this cvar to equalling nil. However, were antilag coding be not used, the recommendation switches to -50 to 0 (even though players are perhaps best to confine themselves to between -30 and 0), or just go with whatever results in the least whines like everywhere else.

    Note: connection setting restrictions are possibly unnecessary for servers running ETPro with b_antiwarp 1. These restrictions should not cause any negative side effects however. Further, a large portion of players perceive issues with low connection settings, so it's probably a good idea to leave them on even if just to hedge your bets, satisfy ignorance or whatever.


    pb_sv_cvar cl_freelook IN 1

    Associated with scripts to lock the mouse at headheight, moving only from side to side. This setting is perhaps overly zealous since some players presumably do still like moving with the mouse DooM I style, but at least at one time there was much hype about scripts setting the crosshair at headheight, locked on the vertical axis so aim consists of side-to-side movement.

    Update: this cvar could be useful for undesirable scripts (no-recoil, mortar) if allowed 0.


    pb_sv_cvar cl_yawspeed IN 0 140
    pb_sv_cvar cl_pitchspeed IN 0 140

    These restrictions counter some "mortar bot" scripts which have been made to essentially automate the targeting with the mortar. There are some other suspect uses of the cl_yaw/pitchspeed cvars but the mortar scripts are of most concern, and anyway the other things seem to be tackled between these restrictions and cl_freelook IN 0.

    cl_pitchspeed sets the speed that the player looks up and down if using the keyboard keys for looking up and down, while cl_yawspeed sets the speed for looking left and right. However the commands for these keys, (+lookup, +lookdown, +left & +right) also work in scripts to automatically line up and set the angle of the mortar weapon. The scripts are not particularily straightforward to use, for example they only work from set positions and have to start from the correct angle and whatnot, requires the user to tweak for their FPS settings, plus they are also inflexible in that of course they will only target the pre-made target locations.

    With free reign over cl_pitchspeed and cl_yawspeed, the mortar bots can be fairly reliable, fast to target and quite deadly. The scripts can be defeated entirely by only allowing these cvars to have the value of 0, and this is currently used in European leagues. I've relaxed the reccomendation here to allow between 0 and the default of 140 because some players do like to play the mortar one-handed on a ciggy break, for example, and the maximum speed of 140 still makes the mortar scripts less reliable (and crucially, at least as slow as a human, yet still nowhere near as flexible and skilled as a talented mortar player).

    Further, 140 being in the allowed range means it will not be a problem as a Punkbuster-enforced restriction: 140 is the default value and so if 140 is not allowed then players would have to manually change their settings or be kicked from the server. When using ETPro to restrict cvars then going with the League's restriction of 0-only is more palatable, since ETPro will force cvars into the allowed range and there's no problems.

    Update: cl_yawspeed and cl_pitchspeed are no longer useful restrictions if ETPro 3.2.0 is being used, as +lookup and +lookdown have been nuked. This resolves the above.



    pb_sv_cvar m_pitch OUT -0.015 0.015
    pb_sv_cvar m_yaw IN -0.022 0.022


    These can be used together to lock the mouse at headheight, or at least make the mouse far less sensitive on the vertical (pitch) axis than the horazontal (yaw) axis. The settings work in relation to each other so it is necessary to set these to ensure m_pitch is at least 2/3 of what m_yaw is set to. Default for both is 0.022. If this seems unclear, and especially if you are wondering why it isnt pb_sv_cvar m_yaw IN 0.022, check this page I scribbled up, has MSPaint illustrations and everything.


    pb_sv_cvar cg_bobup IN 0 0.005

    Ahaha, the one cvar which really can be used as a clear cheat. When set to 0, a common "tweak", this cvar simply eliminates the little "bob" you get when walking along, simulating the up-down-up-down view when walking along. Some players find it more natural with the bob, some find it makes them feel sick, others just find it that tiny bit easier to aim without any bob. The difference really is subtle though. Both the default 0.005 and 0 are hence perfectly reasonable, and any setting in the middle is just that, same thing but a bit less of it.

    Problem? When set to negative numbers, it has the effect of bobbing down - down through the floor. Unfortunately, when looking from under the floor, you can look right through it and into other rooms. A "floorhack" which although very inconvenient (to say the least, you try it off-line) but you can script it to a toggle, quite a bonus for clanwar in particular so you can determine other team's tactics. Really is little to no use for 1v1 (again, try it offline and you'll see it's impossible to aim like that - and no you cannot shoot through the floor you're looking through) and unlikely to be much benefit for public play where standing still and listening, waiting or leaning tells you more.

    Note the other bob settings do not have any effect like this. See the screenshot of bobup at I think -0.5:

    cg_bobup at -0.5.


    pb_sv_cvar cg_shadows IN 0 1

    Having 0 shadows a common tweak, note shadows are only the utterly pointless little round blob under players, not shadows cast by buildings or whatever. Setting shadows at >1 mixed with r_stencilbits 8 however can be very buggy and they can be drawn through walls, giving the player notice someone is waiting for them. Actually, r_stencilbits is a very buggy cvar and it is hard to make this work, but there is no reason to have cg_shadows at anything other than 0 or 1 so a simple cost-free PB cvar restriction.


    pb_sv_cvar cg_fov IN 90 125

    FOV below 90 could be used as a zoom function, but is cheat protected anyway. In RTCW, over approx 125 allows in a couple of specific positions a minor wallhack effect, an example on RTCW is if you lean in the right place behind the forward bunker door on mp_beach you can see players getting near and run around to shoot engineers. I'm not actually aware of any such places in ET, but I havent looked extensively and it does seem a bit silly when players get excessive peripheral vision (at the expense of long range visability).

    A few players actually report better fps with the higher FOV, presumably something to do with the scaling at distances, since a lot more of what is onscreen appears further away. Most servers seem to allow either 90-120 fov, or 90 to 125, basically same thing so I suppose the 125 would actually be a more sensible upper limit. Note all the other screenshots are taken with FOV 107, which I use normally and much prefer over 90 due to the feel of greater speed that is caused by the perspective it makes (no, it doesn't actually make you any faster at all).

    There is no definite need to restrict this cvar in ET, but a sufficiently large majority of players do appear to feel it is desirable to have some limit upon the field of view of players, on the basis of the increased peripheral vision. It seems very few players - if any - prefer a fov greater than 125 anyway, so while there is little "scientific" justification for the restriction, also there seems to be negligible negative impact of restricting this cvar to a reasonably flexible range: between 90 and 125.

    Screenshots pretty much just show the difference in view, since havent found an exploit:

    FOV 90
    FOV 120
    FOV 180


    pb_sv_cvar r_flares IN 0 1

    Flares set above the default 1 can show dynamic lights through walls, i.e. can actually see the yellow of dynamite being put down from very far away and through several walls. Also makes the gunflash of shooting players much more noticable. flares at 0 is a tweak but only serves the player a disadvantage, a tradeoff for a little fps. On older cards dynamic light actually does take a fair bit of rendering, older cards do not support it in hardware or do not support it very well in hardware - GF2 does it "ok" and GF3 and up really wont notice any detrimental effect on FPS of ET's dynamic lights.

    Screenshot shows r_flares at 3 with the flare of dynamite being put down at the fueldump, visble from inside the building nearby. Hardly a big advantage, but a couple of seconds advance warning just might be enough to change the outcome of a clanwar, and there is no legitimate reason to have this setting above 1 anyway.

    r_flares at 3


    pb_sv_cvar r_primitives IN 0 2

    Thanks Bani & Rain:
    "r_primitives 3 causes bizarre texture rendering problems in RtCW and ET, which could potentially be used to make players higher contrast in the distance."


    pb_sv_cvar r_nv_fogdist_mode INCLUDE NV

    Thanks Bani & Rain:
    "remove: r_ext_NV_fog_dist
    this doesnt work the same in ET anymore. see r_nv_fogdist_mode

    add: pb_sv_cvar r_nv_fogdist_mode INCLUDE NV'
    this is the correct fog check for ET. "


    pb_sv_cvar r_detailTextures IN 0

    r_detailTextures 1 combined with other settings creates a fullbright affect. Debatable as to the necessity of this restriction, since in reality very little tweaking is required to be able to see right up to the fog and into shadows anyway, but then r_detailTextures 1 does make it rather retina-burning bright and players stand out significantly more against the plain white background.

    Detail textures is an option in the in-game menu, and I think r_detailTextures 1 is also default when ET installer detects a reasonably fast computer... This makes it a very debatable restriction. I'm confident to recommend it when ETPro restrictions are being used (since that just changes the setting), but much less so for the PB restriction system, as it may result in a lot of kicking (particularily of newer players). For that reason I've left it out of the PB recommended table above, to aviod problems for servers that just copy & pasted without RTFA.

    r_detailTextures at 1
    r_detailTextures at 0


    pb_sv_cvar r_clamptoedge IN 1

    On ATI cards setting this to 0 removes fog, improving long range visability. The inclreased visability is not as extreme as might be assumed, as the game still clips away everything just a little further away than the "wall of fog", however it is further away, and makes players who would otherwise have been in partial fog much clearer (fogging is partially gradual).

    Arguably this would be a convenient setting for a FPS boost, but since there is a clear and significant unfair visability advantage -- and worse, it is not available to all players -- then it should not be allowed.

    r_clamptoedge at 1 (ATI card)
    r_clamptoedge at 0 (ATI card)


    pb_sv_cvar r_drawworld IN 1
    pb_sv_cvar r_drawfoliage IN 1
    pb_sv_cvar r_znear IN 3
    pb_sv_cvar r_showtris IN 0
    pb_sv_cvar r_drawentities IN 1
    pb_sv_cvar r_showmodelbounds IN 0
    pb_sv_cvar r_lightmap IN 0
    pb_sv_cvar cg_tracerlength IN 160
    pb_sv_cvar cg_tracerSpeed IN 4500
    pb_sV_cvar cg_tracerwidth IN 0.8
    pb_sv_cvar cg_tracerchance IN 0.4


    These are cheat-protected and/or hardcoded cvars, but there are hacks available which can bypass the cheat protection. Punkbuster does now (by default) check and kick for some cheat protected cvars being out of the allowed range, but not all of them.

    This is not an exhaustive list of cheat-protected cvars that PB does not kick for by default, but these are the most "interesting" ones that are worth ensuring are enforced. That is, of those I've checked. I cant say I've done the mammoth task of going through anything like every single cheat-protected cvar to find out every possible naughty effect and then going testing to see wether or not PB kicks for it. Further still, some cvars may only be suspect when in combination with another cvar, and some cheat-protected cvars have different values depending on the setting of certain 100% legit cvars.

    There is no good reason why any of these cvars should be at any other setting, so it would be prudent to include them in the cvar restrictions. Note I advise against banning players for any cvar violations, and this includes these cheat-protected ones. Without hacks, or any intention of cheating, it is possible to set some cvars to a different level than "allowed", but the game will only actually use an allowed setting, so it is possible some players will be kicked who were not intending to cheat. Also, the pb_sv_cvar enforcement is very strong so there is no concern of a player using any other cvar hack to bypass the detection.

    Evenbalance said they are still working on adding more cheat-protected cvars by default, so hopefully adding these restrictions is only needed in the short to medium term - although for PB other issues like compatibility and detecting hacks rightfully take priority.

    Note in ETPro mod cg_tracerlength IN 160; cg_tracerSpeed IN 4500; cg_tracerwidth IN 0.8 and cg_tracerchance IN 0.4 are pointless restrictions, as when playing online in etpro 3.x.x, these cvars are hardcoded so it doesnt matter if players hack them or not -- it will have zero effect. so theres no point to limit them in either pb or etpro (source).

    Update 12th March 2005: At the previous time of writing, cvar hacks ("unlockers") were available and of concern. More recently however I've not seen any on cheater sites and they are not really of much concern anymore. The above checks shouldnt cause any issues for any bona-fide players, so I neither strongly encourage nor discourage admins from including the above restrictions - I'd say I'm mildly in favour of keeping them.



    Dubious Cvar Restrictions


  • Dubious When Using ETMain:

    cg_errordecay IN 100
    cg_atmosphericeffects IN 1
    com_maxfps OUT 0.00001 40
    cg_zoomDefaultSniper IN 0 125
    r_softwareGL IN 0
    r_allowextensions IN 0
    r_rmse IN 0 75
    r_picmip IN 0 3
    r_gamma IN 0 3
    r_intensity IN 0 1.5
    r_overbrightbits IN 0 3
    r_mapoverbrightbits IN 0 3
    r_subdivisions IN 1 4
    cg_autoaction IN x
    pb_sv_cvar r_ext_texture_filter_anisotropic in 0
    r_ati_fsaa_samples in 0
    r_ati_truform_tess in 0
    r_ext_ATI_pntriangles in 0
  • Dubious When Using ETPro:

    cg_errordecay IN 100
    cg_atmosphericeffects IN 1
    com_maxfps OUT 0.00001 40
    cg_zoomDefaultSniper IN 0 125
    r_softwareGL IN 0
    r_allowextensions IN 0
    r_rmse IN 0 75
    r_picmip IN 0 3
    r_gamma IN 0 3
    r_intensity IN 0 1.5
    r_overbrightbits IN 0 3
    r_mapoverbrightbits IN 0 3
    r_subdivisions IN 1 4
    cg_autoaction IN x
    r_ext_texture_filter_anisotropic in 0
    r_ati_fsaa_samples in 0
    r_ati_truform_tess in 0
    r_ext_ATI_pntriangles in 0


  • pb_sv_cvar cg_errordecay IN 100

    Set very high this can cause a wallhack effect, similar to negative cg_bobup but through walls rather than floors. Note the setting's effects probably cannot be simulated offline. Although no known exploits exist with cg_errordecay between 0 - 100, there is also no known justification for having cg_errordecay at anything other than it's default value of 100.

    Screenshot, from inside the first axis spawn room in Goldrush:
    cg_errordecay at 999999

    Update: According to Bani this cvar isnt necessary when using [a now quite old] ETPro, but there doesnt seem to be any reason to remove it either. Bani also noted no errors noticed until cg_errordecay exceeded 500.

    Update 2: Errordecay has been fixed with ET2.60 ("Fixed large cg_errordecay values exploit" source: 2.60 Readme).
    cg_errordecay IN 100 should still be used on servers running ET2.56 (aka ET1.02).



    pb_sv_cvar cg_atmosphericeffects IN 1

    I beleive this setting should not be used as the rain and snow really makes no difference in visability at all, yet removing it can have a very significant effect on fps on some systems. The latter screens show the most snow on screen I could find, and you do not have any advantage from removing the tiny snowflakes. Called them rain/snow 0/1 for simplicity.

    No rain vs rain
    No snow vs snow
    No snow vs snow


    pb_sv_cvar com_maxfps OUT 0.00001 40

    In RTCW, FPS affects the sniper rifle recoil, so you would restrict this to limit how much players can force very little recoil. Anyone is a eejit to set maxfps below 40 anyway (use 43 if you get this low fps), so there isnt really a reason not to have this - it doesnt prevent anyone actually getting under 40fps, only forcing it so.

    However, in ET sniper recoil is NOT affected by FPS, so there isnt any need for this restriction.


    cg_zoomDefaultSniper IN 0 125

    In RTCW, cg_zoomdefaultsniper set to very high levels can give a wallhack-like effect when using binoculars. At the edges of the screen the player can see through the walls at certain points (similar to cg_fov in that game).

    In ET however, the "fisheye" view still happens but it does not allow players to see through walls (presumably for the same reason cg_fov does not allow wallhack effect in ET). There is no necessity for this cvar to be restricted in ET, although arguably it is reasonable to restrict it in order to be consistent with the reasoning behing restricting cg_fov.

    cg_zoomDefaultSniper 20 (default)
    cg_zoomDefaultSniper 125
    cg_zoomDefaultSniper 300
    cg_zoomDefaultSniper 20 in RTCW (default)
    cg_zoomDefaultSniper 125 in RTCW
    cg_zoomDefaultSniper 300 in RTCW


    pb_sv_cvar r_softwareGL IN 0

    Again quoting SCDS_reyalP from a SplashDamage forum thread:

    Curiously, r_softwareGL doesn't seem to be a valid cvar. It may be a typo of r_allowSoftwareGL, which is.
    This permits the game to use software rendering if no hardware support is available. Normally, quake3 games just quit with an error if there is no hardware opengl. I don't know what exploits are associated with allowing software rendering, aside from single digit frame rates. Probably some opengl hack, but you can do that without software gl.


    Unless anyone has something to add to this, the cvar restriction seems pointless (although it also appears that using it doesnt cause problems for anyone anyway, so feel free if you want to be uber prudent).


    pb_sv_cvar r_allowextensions IN 0

    This cvar is included in the punkbuster cvar restrictions supplied with ET, although they do note in all the ET server .cfg's they are just examples, and anyway I think these cfg's are simply provided by nice people from the beta and/or open ET Test, some of it from cfg I uploaded on SD forums, they're not made and provided by SD programmers.

    I have no idea what this setting actually is for, but it does cause problems - especially it seems for some Radeon (Mobility?) users. A cvar restriction that appears to have no use and yet causes serious problems is a bad one. If anyone does know of a misuse of this please leave a comment.

    Maybe more light on the setting provided by SCDS_reyalP in a vaguely relevant thread on the SplashDamage forums:

    r_allowextensions lets the renderer use opengl extensions. So this config requires users to have extensions enabled. Normally opengl extensions are a good thing (you can get faster performance, better eyecandy etc) but some drivers have buggy implementations of the extensions. So requireing them to be enabled may prevent some people (mostly with older or oddball video cards) from playing.

    And from another:

    There are cvars to turn on/off most of the extensions individually, and these are mostly not restricted by PB. [...]


    Most of the extenstion cvars will be of the form r_ext_blahblah with 1 being enabled, and 0 being disabled.

    I don't quite understand why servers require gl extensions in the first place. It seems odd that there would be an exploit based turning extensions OFF.


    It would appear there may be driver hacks that can make use of extensions, or perhaps more likely fear that their might be.


    pb_sv_cvar r_rmse IN 0 75

    Update: This cvar no longer does anything, as of the 1.02 patch (thanks Bani), so is no longer included in the recommended set of cvar restrictions. However, it still works in prior versions of ET, and the restriction should be included there. On 1.02 servers using the restriction should not cause any problems - it's just completely pointless.

    Increasing RMSE can have a significant FPS increase on some systems, at the expense of textures being very blurred (quite similar to picmip, although note this affects HUD and console text also). High RMSE in RTCW had an effect similar to picmip 5, of removing leaves from tree's (specifically on mp_ice). Checking it on ET and it really doesnt seem to have anything like as significant an effect, compare the screens - yes it looks a lot uglier, but does it provide any visability advantage? Perhaps there being less patterns on the screen makes players stand out a little more, by reducing RMSE the effect is much less pronounced. Having checked this more throughly I think I'm now going to allow low (e.g. max of 75) use of rmse.

    For the screenshots, bear in mind the comment I made earlier, I am already running picmip at it's highest of 3 so the blurring effect of rmse is shown at it's maximum in these screenshots.

    RMSE 0
    RMSE 200


    pb_sv_cvar r_picmip IN 0 3
    pb_sv_cvar r_gamma IN 0 3
    pb_sv_cvar r_intensity IN 0 1.5
    pb_sv_cvar r_overbrightbits IN 0 3
    pb_sv_cvar r_mapoverbrightbits IN 0 3


    These settings are relics of cvar restrictions from RTCW, and are either cheat-protected or hardcoded within these ranges. There is a case (or more usually a flamewar thread) to be made for setting them in more restrictive ranges, but this is 100% opinion based; the only objective judgement is that there is no exploit associated with these cvars.

    In my personal opinion, the ranges for these cvars as restricted in the game engine do well to balance the arguments about tweaking for performance vs. advantage; these cvars are not an issue like they were in RTCW. It's worth noting that more can be done to tweak brightness using external programs - ones that are popular for bona fide reasons.

    As noted under other cvar restrictions which are recommended on this page, there are hacks which bypass the game's cvar cheat-protection, but these cvars are hardly of any concern compared to other cheat-protected cvars. That said, it should be noted that some of these cvars are arguably more suspect than others, and it is a call of judgement and personal preference.

    Hence, I consider adding these cvars to the PB restriction as pointless unless you want to be more restrictive, and even then I consider there being dubious merit in doing so.


    pb_sv_cvar r_subdivisions IN 1 4

    Put simply, r_subdivisions controls how "curvy" curves are. The higher you set this, the more they look just like a bunch of straight lines - though at least in theory there is a small FPS increase like this.

    The problem in Quake3 is high subdivisions can cause portions on map that are normally nice joined up curves to have big gaps that you can see through (see here for some pics).

    However in ET there seems to be nowhere that has this problem, no exploitable effect from it anywhere, the worst you get is some messed up graphics (pic, note the rails and the netting - thanks senator). It seems there are a very few locations where there are some gaps which can allow players to see a sliver through a wall, notably on Oasis by the arch near the South Gun. This makes it possible to soundly argue either way wether to restrict this cvar, on the one hand there is at least one location where it could be exploited with significance, on the other the availability of exploiting it is pretty small and the cvar is a widely used one as an FPS tweak. Unfortunately, while there seems to be relatively few vales for this settings that result in the textues being pulled apart, they are spread around so really it's a case of restricting between 1 and 4 or not at all. My opinion on this is that due to the widespread use of the relevant setting as an FPS tweak, unless major leagues in your area start restricting for this then don't bother, unless perhaps you already go for a highly restrictive approach towards settings in which case adding this would also make sense.

    On at least one custom map, namely Frostbite, there is a more concerning issue of being able to see right through certain walls (thanks hiro). I recommend this cvar restriction if you use that map, although r_subdivisions IN 1 64 should suffice for that purpose.

    Some further discussion on this cvar can be found in, for example, this thread on ETPro forums; if you're interested in further investigation of r_subdivisions then you might want to experiment with r_lodcurveerror & r_lodcurvebias at the same time. Note for custom mappers: anywhere 'unstitching' does occur on a custom map, the mapper should "Patch meshes which touch should have their vertices lined up exactly, and be func_grouped to they change LOD together. Or compile with -patchmeta." (quote from ReyalP).

    r_subdivisions 4 - default, no see-through
    r_subdivisions 8 - small see-through
    r_subdivisions 40 - wider see-through
    r_subdivisions 80 - no see-through
    r_subdivisions 120 - no see-through



    pb_sv_cvar cg_autoaction IN x

    This is used in the planetwolfenstein.de ET cup, presumably as a method of ensuring all players take demo's and no pissing about. Probably works well for them in their specific cup setting, but generally this cvar restriction is not recommended, and is really bad for a public server. Just as a note to show how utterly irrelevant they are for public server, this is what the autoaction settings do:

    1 - Start a demo at the start of the round
    2 - Take a screenshot at the end of the round
    4 - Save game stats to a file at the end of the round


    3,5,6,7 - Add up the above for multi-function, e.g. "7" will perform 1+2+4.


    pb_sv_cvar r_ext_texture_filter_anisotropic in 0
    pb_sv_cvar r_ati_fsaa_samples in 0
    pb_sv_cvar r_ati_truform_tess in 0
    pb_sv_cvar r_ext_ATI_pntriangles in 0


    According to the TWL when they adopted them for rtcw: "Disable due to the latest ATI cards can use values for wallhacking". They later dropped them because they couldnt figure out how this wallhack was meant to be done. Further, these restrictions caused significant problems because the middle two are restricted against the default settings (even for players with Nvidia cards).

    I dont have a ATi card so cannot have a go at testing myself, although to hazard a guess I would say r_ext_texture_filter_anisotropic and r_ati_fsaa_samples are listed there because FSAA is known to stop screen capture working with ATi drivers prior to Catalyst 3.8. Hence use of FSAA would prevent PB screen captures from working. r_ati_fsaa_samples and r_ati_truform_tess is thought to be involved with a wallhack effect that can appear with use of a messenger, although since the effect only occurs when receiving a message and doesnt last for long, the ability to exploit it is somewhat debateable.

    I welcome any information how these can be used as a wallhack (plenty of admins seem interested too), though these cvar restrictions would still have a distinct downside (certainly for public servers) since they go against the defaults - less of a problem with ETPro method of restrictions than Punkbuster's.




    100% Pointless checks

    These settings are seen often in ET cvar restriction setups, but there is no need for any of them, they are useless. Some are clearly just copy & pasted over from RTCW restrictions.

  • Pointless When Using ETMain/PB:

    r_showNormals IN 0
    cg_thirdPerson IN 0
    r_wolffog IN 1
    cg_bobpitch IN 0 0.002
    cg_bobroll IN 0 0.002
    cg_bobyaw IN 0 0.002
    r_picmip2 IN 0 3
    cg_reticletype IN 1
    r_ext_NV_fog_dist IN 0
    pb_sv_task 300 600 "pb_sv_cvarsrch com_maxfps"
    pb_sv_task 600 600 "pb_sv_bindsrch com_maxfps"







  • Pointless Using ETPro:

    r_showNormals IN 0
    cg_thirdPerson IN 0
    r_wolffog IN 1
    cg_bobpitch IN 0 0.002
    cg_bobroll IN 0 0.002
    cg_bobyaw IN 0 0.002
    r_picmip2 IN 0 3
    cg_reticletype IN 1
    r_ext_NV_fog_dist IN 0
    pb_sv_task 300 600 "pb_sv_cvarsrch com_maxfps"
    pb_sv_task 600 600 "pb_sv_bindsrch com_maxfps"
    cg_tracerlength IN 160
    cg_tracerSpeed IN 4500
    cg_tracerwidth IN 0.8
    cg_tracerchance IN 0.4
    cl_yawspeed IN 0 140
    cl_pitchspeed IN 0 140
    b_hitsounds IN 0


  • pb_sv_cvar r_showNormals IN 0
    pb_sv_cvar cg_thirdPerson IN 0
    pb_sv_cvar r_wolffog IN 1

    These are cheat protected cvars, and although there are hacks to bypass the game's cvar cheat protection, PB itself kicks players when these cheat-protected cvars are outside normal settings (violation #20005), so there is no point adding them. Earlier versions of PB was not kicking for any cheat-protected cvar violation, unless it was specified by the admin, but now it seems they have fixed the problem and PB does indeed now kick for many cheat-protected cvars being outside of the allowed ranges - but not all of them, hence there being another set of cheat-protected cvars in the recommended list.



    pb_sv_cvar cg_bobpitch IN 0 0.002
    pb_sv_cvar cg_bobroll IN 0 0.002
    pb_sv_cvar cg_bobyaw IN 0 0.002

    These settings do not have any exploit effect, unlike cg_bobup.



    pb_sv_cvar r_picmip2 IN 0 3

    Cvar does not exist in ET.



    pb_sv_cvar r_uifullscreen IN 0

    Cvar does not remove fog, or have any other known exploit effect in ET (unlike rtcw).



    pb_sv_cvar cg_reticletype IN 1

    Cvar does not exist in ET.

    NB: The cvar is was listed on the server cfg at TWL webpage, but is NOT used in their actual cfg - which comes with ETPro. It appears to be the latter that is correct, at time of writing, and the cvar restriction is not necessary. In rtcw the cvar at 0 removes the binoc HUD (which also makes the cg_zoomDefaultSniper exploit more effective).



    pb_sv_cvar r_ext_NV_fog_dist IN 0

    Cvar does not exist in ET. Instead use pb_sv_cvar r_nv_fogdist_mode INCLUDE NV (see above).



    pb_sv_task 300 600 "pb_sv_cvarsrch com_maxfps"
    pb_sv_task 600 600 "pb_sv_bindsrch com_maxfps"

    FPS does not affect the sniper recoil in ET, com_maxfps is not any sort of issue, and nor is use of it in any keybinds or scripts.

    Incidentally, many players do have little scripts to toggle FPS caps anyway, usually because some maps are much more friendly to slower systems than others (e.g. Goldrush is easier on systems than Radar). 99% of admins who copy and paste the (poor) Evenbalance suggested cvar restrictions would not be checking logs for it, nor would have much clue about interpreting it. A similar restriction sometimes used on RTCW OSP restrictions involves "forcefps", a cvar which appears not to exist in ET. Setting cvar restrictions on forcefps by the way does not work even in RTCW, "forcefps" is a command and not a stored cvar.



    b_hitsounds IN 0

    If you wish to prevent player's using ETPro's hitsounds feature, use the server setting instead. I don't recommend disallowing hitsounds, but if you want to then this is how to do it:

    b_sv_hitsounds (default 1, enable)
    0 = server globally disables hitsounds
    1 = server allows clients to use hitsounds
    (Source: ETPro changelog)




    Conclusion

    I recommend all admins running Punkbuster on their servers to include the cvar checks that are shown above, for the reasons given.

    I suggest admins do not use the "dubious" or "100% pointless" checks, although most of them will not cause problems so those ones hadly matter. I recommend more strongly however that admins do not use the couple of dubious/pointless checks that do cause problems for people. It seems these checks are making life difficult for some players for no good reason whatsoever.

    Just how much value and trust you want to place on the articles used as backup (namely the Keen, Upset Chaps and Unlagged FAQ documents) is up to you, especially since the connection explanations given in them are sometimes contradictory, but all the suggested cvar restrictions here are fairly conservative and I beleive are supported by a prudent view of each of these articles.

    I hope this article nudges admins towards using a standard punkbuster cvar restriction config, which comprahensively removes cvar-related exploits yet aviods causing problems for anybody. I have shown why the Evenbalance and ET suggested restrictions are imperfect, and where many ET cups have been inefficient - although not actually causing problems. Perhaps equally important, a standard set of restrictions that are used widely has the best chance of being understood, allowing players to know what is and is not acceptable by the community in general. Note that the recommended restrictions are thoroughly pre-tested on a couple of busy public servers.

    Any omissions, errors, or any other contructive comments are welcome by email to the address below - or try the enemy territory forum. Please RTFA beforehand. Already several such feedback (wether directly or via some forum discussion somewhere) has been incorporated - thanks particularily SCDS_reyalP, Vio, Rain, Bani, shakes, hiro, dragon.

    EMail: [Email addy image]



    Further Reading / Bibliography

    Please note that pages written about different games have varying amount of relevance to Enemy Territory. These games reffered to below are all based on the Quake 3 engine, however the Q3 engine itself has seen updates via patches, then came RTCW which added significantly to the engine, and ET again made relevant changes over RTCW's Q3-engine incarnation.

    Team Warfare League Rules/PB cvar restrictions (ET)
    ClanBase Rules/PB cvar restrictions (ET)
    Pack's suggested PB cvar restrictions (RTCW)
    Evenbalance suggested PB cvar restrictions (RTCW & ET)
    CAL Rules/PB cvar restrictions (RTCW)
    Punkbuster Manual for Server Admins (ET)
    Upset Chaps Connection Tweaks (Quake 3)
    Commander Keen's Quake 3 Arena Console Page (Quake 3)
    Alternate Fire Unlagged FAQ (Quake 3)
    "arQon" Timenudge/Q3 Networking Explanation (Quake 3)
    GameAdmins (RTCW, ET, Q3)



    Written by and � DG, www.rtcw.co.uk
    Originally posted (here) 21st July 2003
    Restrictions last updated 18th May 2005.



    Contents

    Enemy Territory & RTCW UK