Thank you for bringing this topic up @GPF .
C doesn’t have Boolean actually. in Trem code (from quake 3) there is an enum that acts like a boolean values :
typedef enum {qfalse, qtrue} qboolean;
However, the way enums work in C, qfalse acts like it has the value 0, and qtrue acts like he has the value 1. The way the “truth” values of logic expressions in C are determined (such as those used in if statements), 0 and NULL are treated like it is “false”, and anything other than those two values are treated like it is “true.”
It is also important to know that cvars can store floats, ints, and strings (actually a char array), but they don’t store any qbooleans, which is why cvars that are used to just to disable/enable things use integer values, treating 0 as “off” and 1 as “on”, however, with such cvars you can use any int value other than 0 and they would still have the same effect of using 1 (assuming the particular cvar’s usage isn’t coded in a “weird” way).
With that said g_friendlyFire and g_friendlyBuildableFire have been modded on test7341 so that they represent the percentage of damage you can do to teammates and team buildables respectively. So the value of “75” for g_friendlyFire means that you would do 75% of the damage you would otherwise do to enemy/neutral targets that could take damage.
I’m not sure why g_unlagged is set to “500”, looking at the code, it is meant to be strictly an “enable”/“disable” cvar. We did do some work on other branches related to lag spikes, and it is possible this is related to that, or the value was set by mistake. Something that I have noticed occasionally, sometimes when we have crashed the server from bugs like segfaults, the values in some cvars have changed. But in any case, at least for the branches we are currently testing on the server, g_unlagged set to “500” behaves the same exact way as if it was set to “1.”