Standard SV CVAR checks

[ReyalP]

btw if you want to do connection checks allowing snaps to be anything ovcommand "sv_cvar b_antilag EQ 1"

o_O
That's a pretty weird restriction. Given that b_antilag lets each client decide how their own shots are tested, why would you force them to use a particular method ? Your b_antilag setting *only* affects your shots. Nothing else.

[deej]

Guess we'll remove that then. Now I'll have to have the config recertified too ...

On the other hand I was figuring that forcing people to use Bani's antilag method would level the playing field as much as possible. Since its default value is 1 I'd really wanted to prevent people from turning it off (TBH so that they wouldn't bitch about the quality of my server when they play bad ).

[jump3r]

so, what about writing *complete* list of useful and useless cvar restrictions?

btw. why is cl_freelook defaultly rest. to 1?

[ReyalP]

so, what about writing *complete* list of useful and useless cvar restrictions?

Opinions vary.

btw. why is cl_freelook defaultly rest. to 1?

Because otherwise you can lock your crosshair at head height.

[DG]

- restricting subdivisions? lol, same as the r_depthbits. that's garbage

?

- restricting cl_yawspeed & cl_pitchspeed is absurdity made by CB admins (c). why players can't make their own mortar scripts? that's part of this game! everyone can (could) use that, so that's problem of this player, if he didn't have that.

it was heavily requested by community, anyway the restrictions will be pointless in next expro. Not everyone considers automated aiming and anti-recoil to be part of the game, and people can do a lot of things that still arent OK even though everyone could do them, likewise there's lots of OK things that only some people can do. Everyone being able to do something isnt exactly a sane argument.

- rate at 2500 and/or maxpackets at 15 = brutal warping players, tested
- etpro antiwarp is leet improvement, but it's not The God

If admins want to increase rate/maxpackets to 10000/60 (for example) and cut out modemers and single-chan isdn it's no skin of my nose, but I cant exactly be suggesting cutting them out because some admins blindly cut+paste without bothing to read what they're doing. If you RTFA it's clear these should be considered minimal.


A literally complete list of wether to restrict every cvar would be very, very long and largely useless.

I'll probably revise that page later to up rate to min 3500 and maxpackets min 20, but only on the etpro restriction side (auto cvar adjustment).

[booger]

restricting cl_yawspeed & cl_pitchspeed is absurdity made by CB admins (c). why players can't make their own mortar scripts? that's part of this game! everyone can (could) use that, so that's problem of this player, if he didn't have that.

That had little to do with mortor scripts,more to do with 'snap turn' scripts for rambos.

[dragon]

if r_lodcurveerror is less than 250 on some ORIGINAL maps (ie battery for a start) the player can get a slight advantage in some areas due to objects being rounded instead of angled. It's certainly enough advantage to know there's someone coming.

And hey, I raised this thread so we could discuss all these cvars and try to determine what should ALWAYS be included and what is merely optional. Good to see the debate

[Decade]

- restricting cl_yawspeed & cl_pitchspeed is absurdity made by CB admins (c). why players can't make their own mortar scripts? that's part of this game! everyone can (could) use that, so that's problem of this player, if he didn't have that.

it was heavily requested by community, anyway the restrictions will be pointless in next expro.

Why? What happens in the next etpro?
Personally I like these restrictions because I made a script that allows me to have almost zero recoil with sniper rifle even if cl_yawspeed and cl_pitchspeed are zero.

[DG]

you'll have to dig through the forum to find exactly what bani posted about it, since i cba to

[hiro]

FWIW, forcing r_depthbits is not effective. r_depthbits is only a hint to the game, it will often choose a different value to match what your hardware can provide in a given color depth.

It also requires a vid_restart to take effect.

DGs cvar restriction page has some good stuff:
http://www.rtcw.jolt.co.uk/content/enem ... tions.html

I take that to mean forcing it to 24 will override what the game has determined is the most suitable for the hardware, which would thus result in loss of performance for the player affected. I couldn't find much info about r_depthbits when I searched and it doesn't appear to be on DG's otherwise comprehensive list. I did find this info on a UT site:

This controls the z buffer depth used, defaults to 24 bits when using 32 bit colour but some driver sets support 16 bit z buffer depth when rendering in 32 bit colour. If you have a card that supports 32 bit rendering but have limited memory or memory bandwidth due to running at high resolutions or a card with SDRAM then try setting this to 16. If you notice visual problems set this back to it's default of 0 which then uses desktop colour depth.

So how can r_depthbits be exploited, and is it enough of a hack to warrant forcing it to 24 if there's a chance there may be players who are using it to help with older hardware?


Apart from that I've come up with this list of cvar checks, please say if it's either missing something or if any reommended settings should be optional, or vice versa.

RECOMMENDED

command "sv_cvar cg_bobup IN -0.005 0.005"
command "sv_cvar cg_errordecay EQ 100"
command "sv_cvar cg_fov IN 90 120"
command "sv_cvar cg_shadows IN 0 1"
command "sv_cvar cl_freelook EQ 1"
command "sv_cvar m_pitch OUT -0.015 0.015"
command "sv_cvar m_yaw IN -0.022 0.022"
command "sv_cvar r_allowextensions EQ 1"
command "sv_cvar r_ati_fsaa_samples EQ 0"
command "sv_cvar r_ati_truform_tess EQ 0"
command "sv_cvar r_clampToEdge EQ 1"
command "sv_cvar r_depthbits EQ 24"
command "sv_cvar r_detailtextures EQ 0"
command "sv_cvar r_ext_ATI_pntriangles EQ 0"
command "sv_cvar r_ext_texture_filter_anisotropic EQ 0"
command "sv_cvar r_flares IN 0 1"
command "sv_cvar r_lodcurveerror GE 250"
command "sv_cvar r_nv_fogdist_mode INCLUDE NV GL_EYE_RADIAL_NV"
command "sv_cvar r_primitives IN 0 2"
command "sv_cvar r_subdivisions IN 1 64"
command "sv_cvar rate IN 3200 25000"


OPTIONAL
To reduce use of scripts:
command "sv_cvar cl_freelook EQ 1"
command "sv_cvar cl_pitchspeed IN 0 140"
command "sv_cvar cl_yawspeed IN 0 140"

To safeguard unlocking:
command "sv_cvar cg_thirdperson EQ 0"
command "sv_cvar r_drawentities EQ 1"
command "sv_cvar r_drawfoliage EQ 1"
command "sv_cvar r_drawworld EQ 1"
command "sv_cvar r_lightmap EQ 0"
command "sv_cvar r_mapoverbrightbits IN 0 3"
command "sv_cvar r_overbrightbits IN 0 1"
command "sv_cvar r_showmodelbounds EQ 0"
command "sv_cvar r_shownormals EQ 0"
command "sv_cvar r_showtris EQ 0"
command "sv_cvar r_wolffog EQ 1"
command "sv_cvar r_znear EQ 3"


Finally, can anyone venture a definitive answer as to whether these connection settings are still relevant with antiwarp? Snaps & maxpackets would appear to be redundant, however is it advisable to force players to within desirable values? For timenudge it seems that it should be forced to 0 when the server has antiwarp on, which I'd imagine all comp servers would use.

command "sv_cvar snaps IN 20 40"
command "sv_cvar cl_maxpackets IN 20 125"
command "sv_cvar cl_timenudge EQ 0"

[EagleReloaded]

I don't know why people still get freedom with snaps, if all servers simply run sv_fps 20 then 30 is out of sync and 40 means receiving two identical updates in a row, at least that was my understanding of how it all tied together, I'm probably wrong.

r_drawFoliage EQ 1 is a bad one to include as I discovered for myself last night when my former clan scrimmed on Radar and discovered grass had returned - forcecvar can't overwrite sv_cvar so the map radar {} part of the config had no effect, and neither did using forcecvar manually - all it lead to was a CVAR violation warning on match start.

Is r_drawFoliage even worth monitoring anymore? Any maps we play with grass we have it turned off, and it makes no difference on the others, so why not just leave it at 0 all the time?

[ReyalP]

I don't know why people still get freedom with snaps, if all servers simply run sv_fps 20 then 30 is out of sync and 40 means receiving two identical updates in a row, at least that was my understanding of how it all tied together, I'm probably wrong.

The engine only sends snaps every server frame, at most. Rain mentioned that snaps > sv_fps may throw off the rate limiting calculation (causing you to get rate limited even when you are under your rate), but beyond that, should have no effect. You certainly don't get extra snaps.

take that to mean forcing it to 24 will override what the game has determined is the most suitable for the hardware,

Not really. It will tell the game you'd like 24 bits of depth buffer. OpenGL offers the game a limited number of 'pixelformats' which are various combinations of color bits, z buffer bits etc. Setting r_depthbits tells it that, all else being equal, you'd like one with a 24 bit z buffer, or as close as possible.

On many cards, 16 bit color implies a 16 bit z buffer, and 24/32 bit color implies a 24 bit z buffer. In that case, your setting of r_depthbits does nothing.

You could require r_colorbits >=24 (as well as r_depthbits >= 24), but piles extra punishment on people with low end cards.

I still say there is no reason to restrict timenudge, but if it makes you feel warm and fuzzy, help yourself.

AFAIK maxpackets is internally limited to 100 (unless ET thinks you are a LAN, in which case it send one packet per frame, no matter what) so there isn't much reason to enforce an upper limit on that.

What you do with your net settings limits depends a bit on what your setting up your config server. On a pub, I would use settings that would be workable for a modem player, even if it let players be somewhat warpy. For a competition environment, where you can expect your players to be on broadband, you might want to set things a bit stricter

[hiro]

thanks, that sheds light on the depthbits, although I still haven't seen any screenshot evidence of what it can do when used for ill gain.

I thought that restricting all three of those connection settings was largely pointless with current versions of etpro, however I was concerned about timenudge from this:

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.

or is that refering to etmain antilag?

[deej]

As I said in my first post, Rain said that snaps =< 20. Setting it higher then 20 can have a negative affect so it's better to protect players against themselves IMO.

Setting it < 20 can be handy for dial-up players. How low you should go there I have no idea. That's why I set our server to 10 =< snaps =< 20. The 10 is a wild guess I admit.

[hiro]

snaps <20 is very useful if you're stuck on dialup.

So would it be useful to put a line like this in our config?

Code: Select all

command "sv_cvar snaps IN 1 20"

Or what should the minimum number of snaps be then? 5 / 10?

Well, setting snaps over 20 won't send more than 20 when using sv_fps 20, setting snaps lower than 20 only changes what the player sees (if they want to make their lives harder, then /snaps 1 is the way to go), so there's probably not much point in limiting snaps at all.

Based on that post and others from the old snaps thread, if you're going to check them at all then IN 1 20 is the way to go, and that would only be to save the few players who might set snaps to between 20 & 40 either misguidedly or accidentally.

edit: instead of IN 1 20, maybe OUT 20 40 would be better so players who think they want 40 won't imagine that they've had their setting changed for the worse