pb_sv_cvar [cvar_name] [iN|OUT|INCLUDE|EXCLUDE] [Param1] [optional_Param2] ... PB will kick players with cvars in/outside the specified range.
IN = setting has to be between Param1 & Param2 inclusive.
If no Param2 is present, setting must equal Param1.
OUT = setting may not be between Param1 & Param2, both Param1 & Param2 are not allowed as well.
If no Param2 present, setting may not equal Param1.
INCLUDE = setting must include the string given in Param1.
EXCLUDE = setting may not include the string given in Param1.
Does not change or remove previous blocks of same cvar, both will operate, unless a "pb_sv_cvarempty" was issued.
thus
pb_sv_cvar com_maxfps OUT 0.0001 43
pb_sv_cvar com_maxfps OUT 151 1000
pb_sv_cvar com_maxfps OUT 0
would equal
pb_sv_cvar com_maxfps IN 44 150 // 43 is connected with a no-recoil exploit of q3e
as said i see no use to restrict 0 (uncapped) as only a stable FPS value will have any effect on jumping/recoil/hitboxes.
333 is in connection with a hitbox delay exploit (player is hard to hit), has not v. much to do with jumping. Sorry to destruct your illusions, but this "unfair advantage" to be able to do the special jumps is a result of practice, i.e. of wasting time on boring Trickjump Maps like e.g. this guy --> http://www.youtube.com/watch?v=cDXpxSDB3TE who always used com_maxfps 76 or 125. (no, to restrict these values was ... dorky)
P.S.:
]\com_maxfps
"com_maxfps" is:"125" default:"85"
]\condump sof2_fps.txt
whatever.