Regarding exploits to snaps and rate...

[ensiform]

I would strongly urge all JKA coders to create a cvar and limit how low snaps and rate can go. default minsnaps to 10 and minrate to 1500. I've recently seen many people on JA+ betaServer abusing snaps 1 to make them "lag". It might also be wise to put a lower and upper limit on com_maxFPS of 30 and 130 because setting that below 30 is a cheat, and anything above 130 doesnt really matter hell, above 30 doesnt really either and anything above 200 can actually cause you to get connection interupted even if you dont have net lag.

 

Here's what i did:

 

g_local.h -

 

extern vmCvar_t	sv_minSnaps;
extern vmCvar_t	sv_minRate;

 

g_main.c -

 

vmCvar_t	sv_minSnaps;
vmCvar_t	sv_minRate;

 

...

 

{ &sv_minSnaps, "sv_minSnaps", "10", 0, 0, qfalse },
{ &sv_minRate, "sv_minRate", "1500", 0, 0, qfalse },

 

g_client.c -

 

ClientConnect below the ban check statement:

 

// check snaps
value = Info_ValueForKey( userinfo, "snaps" );
if ( sv_minSnaps.integer > 0 && atoi(value) < sv_minSnaps.integer ) {
return va("Your snaps is too low (%d). Minimum: %d.", atoi(value), sv_minSnaps.integer );
}

// check rate
value = Info_ValueForKey( userinfo, "rate" );
if ( sv_minRate.integer > 0 && atoi(value) < sv_minRate.integer ) {
return va("Your rate is too low (%d). Minimum: %d.", atoi(value), sv_minRate.integer );
}

 

ClientUserInfoChanged above the set name part:

 

// check snaps
s = Info_ValueForKey( userinfo, "snaps" );
if ( sv_minSnaps.integer > 0 && atoi(s) < sv_minSnaps.integer ) {
Info_SetValueForKey( userinfo, "snaps", va("%d", sv_minSnaps.integer) );
trap_SetUserinfo( clientNum, userinfo );
}

// check rate
s = Info_ValueForKey( userinfo, "rate" );
if ( sv_minRate.integer > 0 && atoi(s) < sv_minRate.integer ) {
Info_SetValueForKey( userinfo, "rate", va("%d", sv_minRate.integer) );
trap_SetUserinfo( clientNum, userinfo );
}

[Tinny]

Alrighty, thanks for the heads up bro.

[ensiform]

no problem

[slider]

what snaps does and what rate does?

 

rate is the number of frame per second?

 

or is it snaps?

 

 

also what this lags produced by changing their value gives to the player as advantages?

[bzug0]

snaps - specifies the ammount of packets that server sends to you

rate - specifies the number of bytes that the server can send to the you per second, you can thing of this like your maximum connection speed.

[bzug0]

btw the exploits you reffer iis just to get lagged and skip a lot of frames maybe to avoid contact?

[ensiform]

indeed.

 

rate is bits per second actually.

[bzug0]

oops lol you're right xD

[dtriniman]

Or if you want you can set it in your cfg

 

/snaps 40

 

/rate 25000

 

and heres another one that lowers ur ping by lowering ur packets

 

/cl_maxpackets 15

[ensiform]

15? the default is 30... try /cl_maxpackets 100.

[dtriniman]

Exactly. That's why you go to 15 so its lower, and 15 is the lowest you can go. 100 is ridiculous ur just having the opposite effect.

[ensiform]

no, you want it higher to allow more packets. i ping 18-25 on wild jedi with my connection settings. i live in minnesota and the server is in dallas, texas.

 

rate 25000

cl_maxpackets 100

cl_timenudge -40

snaps 40

[dtriniman]

When mine was at 30 I hada certain ping when I dropped it to 15 my ping became lower. I'll test out 100 and get back to you.

[MDN14]

maybe this is a n00b question, but what is cl_timenudge?

[ensiform]

dont think it really helps in base but it does with Unlagged.

 

actually nvm it is affected, heres a comment from the q3 engine:

 

// cl_timeNudge is a user adjustable cvar that allows more
// or less latency to be added in the interest of better 
// smoothness or better responsiveness.

[razorace]

If I read this correctly, doesn't this fix block users from connecting if their setting is weird? Wouldn't it be better to just correct the value and allow users to connect?

[ensiform]

well i dunno, it seems as though it doesnt actually set it for some reason when i actually tested it 100% on a live server, maybe update wasnt called or smth i dunno.