Boolean cvars have integer values on test7341

When I do /serverstatus on test7341, I see:

g_friendlyFire " 75"
g_friendlyBuildableFire “100”
g_unlagged “500”

Above cvars are booleans and should be set to either "0’"or “1’”… above values are probably seen as a “1’” but its not very elegant. Just saying to prevent unexpected server-behaviour.

Maybe they changed how those values worked for the server than how they worked on Tremulous 1.1? What kind of unexpected server behavior should we, er, expect?

@Hendrich

When you answer “maybe” to a “yes” or “no” question … expect the unexpected :wink:

If I had written the Quake3 code … I would expect the server to crash at boot. But since the code is written by more competent devs, I guess that the booleans are probably set to “1”, unless explicitly set to “0”. (just guessing coz I didnt take a look at the source code for this).

2 Likes

Thank you for bringing this topic up @GPF :slight_smile: .

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.”

4 Likes

@dGr8LookinSparky

Thank you taking the time to look into it and also thank you for the extensive info !

1 Like