Standard SV CVAR checks

[DG]

or is that refering to etmain antilag?

etpro antilag. tbh getting reliable info on any connection stuff is very difficult and anyway lots of people whined regardless, while nobody seems to demand timenudge anymore so its not a problem to restrict it. The page needs an update especially regarding the "general player views" comments.

[ouroboro]

the snaps issue really drives me nuts. i know rain says anything >20 is redundant, but i *know* it does *something*, because when i set mine to 40 i get a LOT more yellow at the bottom of my lagometer. i've bound keys to 20 & 40 and sat there tapping them and watching the color go green, yellow, green, yellow. it's not in my mind. i just wish snaps would be universally enforced to one setting so i wouldn't have to keep wondering which setting is best. :S

[ReyalP]

the snaps issue really drives me nuts. i know rain says anything >20 is redundant, but i *know* it does *something*, because when i set mine to 40 i get a LOT more yellow at the bottom of my lagometer. i've bound keys to 20 & 40 and sat there tapping them and watching the color go green, yellow, green, yellow. it's not in my mind. i just wish snaps would be universally enforced to one setting so i wouldn't have to keep wondering which setting is best. :S

You should read his whole post then.

The engine never sends more than 1 snap per frame. However, setting your snaps higher confuses the rate limiting code (it apperently assumes that you would actually get 40 snaps). So if you set snaps 40, the game may think you are over rate, even when you aren't, and limit you, thus giving yellow in your lagometer.

(I wonder if this was fixed in 2.6 ?)

[ouroboro]

ok ok. please remember that i am reeeeallly dumb

so, if the server's maxrate is 25000, and i'm set at 25000, why would snaps 40 cause an issue? how can the game limit me any more than maxrate already does? are you saying that, if i were to use snaps 20, i'd actually get a bit more info than maxrate wanted to give me, but at snaps 40 it is strictly enforced?

if that babbling made no sense, can you just confirm that snaps 40 IS in fact BAD for ME? if so, i'll try to forget about it even when i see other people using 40 (actually i won't, it'll continue to bug me and i'll always wonder if they might be getting some advantage from 40 so i'll still end up using it).

imagine me making the frustrated screeching sound from the "myg0t pwns you 2" flash movie ( http://pwned.nl )

[ReyalP]

ok ok. please remember that i am reeeeallly dumb

so, if the server's maxrate is 25000, and i'm set at 25000, why would snaps 40 cause an issue? how can the game limit me any more than maxrate already does? are you saying that, if i were to use snaps 20, i'd actually get a bit more info than maxrate wanted to give me, but at snaps 40 it is strictly enforced?

No. If you set snaps 40, the part of the server that calculates when it should limit your rate will incorrectly assume that you are getting 2x as much data, and so limit you much sooner than it should. If your snaps is 20, then the rate limiting calculation matches what is actually happening, and you will only be rate limited if you truely would exceed your rate.

(note, the above is my interpretation of hearsay from |Rain|. It sounds reasonable, but I haven't verified it myself.)

[ouroboro]

excellent, that made sense to my pea brain. snaps 20 it is and shall forever be for me then!

thank you

[hiro]

well this is what I've narrowed it down to, anyone see anything they don't like? I've removed r_depthbits in absence of any evidence of wrong doing and a few of our players have mentioned seeing it in their cvar backups, presumably they had it tweaked to 16 in hope of fps gain.

Code: Select all

	command "sv_cvar rate IN 3500 25000"	
	command "sv_cvar snaps IN 1 20"
	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 cg_thirdperson EQ 0"
	command "sv_cvar cl_freelook EQ 1"
	command "sv_cvar cl_maxpackets IN 20 100"
	command "sv_cvar cl_pitchspeed IN 0 140"
	command "sv_cvar cl_timenudge EQ 0"
	command "sv_cvar cl_yawspeed IN 0 140"
	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_detailtextures EQ 0"
	command "sv_cvar r_drawentities EQ 1"
	command "sv_cvar r_drawworld EQ 1"
	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_lightmap EQ 0"	
	command "sv_cvar r_lodcurveerror GE 100"
	command "sv_cvar r_mapoverbrightbits IN 0 3"
	command "sv_cvar r_nv_fogdist_mode INCLUDE NV GL_EYE_RADIAL_NV"
	command "sv_cvar r_overbrightbits IN 0 1"
	command "sv_cvar r_primitives IN 0 2"
	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_subdivisions IN 1 64"
	command "sv_cvar r_wolffog EQ 1"
	command "sv_cvar r_znear EQ 3"

[deej]

I'd eliminate the following because of no known exploits AFAIK:

Code: Select all

command "sv_cvar r_ati_fsaa_samples EQ 0"
command "sv_cvar r_ati_truform_tess EQ 0"
command "sv_cvar r_ext_ATI_pntriangles EQ 0"
command "sv_cvar r_ext_texture_filter_anisotropic EQ 0" <- corrected in 2.60 &#40;README says&#58; it now works &#58;p&#41;
command "sv_cvar r_mapoverbrightbits IN 0 3"
command "sv_cvar r_overbrightbits IN 0 1"

Here's the minimum stuff we impose (and yes I stick to my conviction that b_antilag should be forced 1).

Code: Select all

command "sv_cvar b_antilag EQ 1"
command "sv_cvar rate IN 3500 25000" 
command "sv_cvar snaps IN 10 20" 
command "sv_cvar cl_maxpackets IN 20 100" 
command "sv_cvar cl_timenudge EQ 0" 
command "sv_cvar cl_freelook EQ 1" 
command "sv_cvar cg_bobup IN 0 0.005" 
command "sv_cvar cg_errordecay EQ 100" 
command "sv_cvar cg_shadows IN 0 1" 
command "sv_cvar cg_fov IN 90 125" 
command "sv_cvar m_pitch OUT -0.015 0.015" 
command "sv_cvar m_yaw IN -0.022 0.022" 
command "sv_cvar r_flares IN 0 1" 
command "sv_cvar r_primitives IN 0 2" 
command "sv_cvar r_nv_fogdist_mode INCLUDE NV GL_EYE_RADIAL_NV" 
command "sv_cvar r_clamptoedge EQ 1" 
command "sv_cvar r_drawworld EQ 1" 
command "sv_cvar r_znear EQ 3" 
command "sv_cvar r_showtris EQ 0" 
command "sv_cvar r_drawentities EQ 1" 
command "sv_cvar r_showmodelbounds EQ 0"
command "sv_cvar r_colorMipLevels EQ 0"
command "sv_cvar pmove_fixed EQ 0"  <- I think this one is redundant with b_fixedphysicsfps to 125 no?

[DG]

agreeing with above eliminations and also:

command "sv_cvar cg_errordecay EQ 100"
- the problem is fixed in 2.60 iirc

command "sv_cvar cg_thirdperson EQ 0"
command "sv_cvar r_shownormals EQ 0"
command "sv_cvar r_wolffog EQ 1"
- PB detects these cvars even without any PB_sv_cvar, possibly several others

command "sv_cvar cl_pitchspeed IN 0 140"
command "sv_cvar cl_yawspeed IN 0 140"
- function these relate to is eliminated in 3.1.12+

command "sv_cvar r_subdivisions IN 1 64"
command "sv_cvar r_lodcurveerror GE 100"
- not really sure why you've gone with these...

[dragon]

sv_cvar r_lodcurveerror GE 100

On some maps, the rounding that can occur with a low number, can give you an advantage in spotting people behind objects. Personally, I think this should be locked at default 250.

Battery has several exploitable areas where a low lodcurveerror gives you an advantage. (And even a 1 second advantage is an advantage)

[hiro]

re lodcurveerror, you need to go under 20 for it to be of any real benfit. it's easy to test as it dosen't require a vid restart.

subdivisons set to 0 or over 64 allows players to lean though a wall and see into axis spawn on Frostbite, which is one of the most popular maps in our ladder.

the r_ati_* restrictions are there due to the supposed msn wallhack, though I tend to agree that it overkill. I don't think it's beyound the realms of possibility that a player may ask someone else over ventrilo to message them when they are standing on the other side of a wall. But I don't have an ati card so I'm just gong on hearsay, if you think these restrictons are unnecessary I'll happily ditch them.

there's also some restrictions in there to safeguard unlocking of cvars like brightbits, although again I've never heard of this actually happening, only that it's theoretically possible. true or false?

the stuff that's fixed in 2.60 we'll obvioulsy remove when we upgrade our servers, we're still on 2.56 & 3.1.19

thanks to everyone who's helped out in this thread

[EagleReloaded]

I've got a Radeon 9600, just tested those settings, got my friend to block/unblock me over and over so the popup kept appearing, the wallhack still happened. So you may as well remove them.

[ReyalP]

Here's the minimum stuff we impose (and yes I stick to my conviction that b_antilag should be forced 1).

FFS. You do understand that it only affects the player who has it set, right ? that is if I set b_antilag 1, the my shots are unlagged. If I set 0, then my shots are not unlagged. If I set it to 2, then my shots use etmain style antilag. It has absolutely no effect on other people. It has abosuletely no effect on movement, warping, the perceived 'laggyness' of the server or anything except the hit detection of my hitscan weapons.

[ouroboro]

/me scratches reyalP between the ears until he purrs...

[deej]

Here's the minimum stuff we impose (and yes I stick to my conviction that b_antilag should be forced 1).

FFS. You do understand that it only affects the player who has it set, right ? that is if I set b_antilag 1, the my shots are unlagged. If I set 0, then my shots are not unlagged. If I set it to 2, then my shots use etmain style antilag. It has absolutely no effect on other people. It has abosuletely no effect on movement, warping, the perceived 'laggyness' of the server or anything except the hit detection of my hitscan weapons.

Point taken.