User talk:Mikero

Booleans

I believe your version of the description of boolean is misleading so I reverted it, and this is why. For mission config you do not need any #defines for true or false, it works fine without any. Also implying that such #define is required, means that you cannot use TRUE or True or TrUe, because #define is case sensitive, however, it is possible to use any of the above. Here is a little experiment. Create description.ext with thisistrue = truE; thisisfalse = FaLse;

then run the following commands in debug console:

hint str getMissionConfigValue "thisistrue"; //"truE" hint str getMissionConfigValue "thisisfalse"; //"FaLse"

As you can see, in config they are indeed treated as strings like you said. However when forced to number in the engine, they become 1 or 0 accordingly:

hint str getNumber (getMissionConfig "thisistrue"); //1 hint str getNumber (getMissionConfig "thisisfalse"); //0

If there are #defines in config that explicitly link true to 1 and false to 0, then it could be for some other reason. Killzone_Kid (talk) 01:24, 13 July 2016 (CEST)

---

you are confusing what the engine is coded to look for with the sqX language processor. sqx 'accepts' case insensitive "true" and "false" as being a boolean const. The engine does not. A string is a string is a string. In the (equivalent of) the engine's c language

if (some_boolean==1) do_something();

There is no engine code to:

if (!strcmp(some_boolean,"true")) do_something();

All paramfiles (config,rvmat,bisurf, fsm, desc.ext, mission.sqm) require true and false to be defined. This is why #include "commondefs.h" exists and why it is normally placed at top of file.

Note that in paramfiles "true" is not the same thing as true. eg quotes are intended to specifically retain this expression as a string and is done so with the express knowledge that the variable is intended for use by the sqx language processor, not, the engine.

Your example of using sqx hints is misleading you. You are using sqx on an engine variable and assuming they are one and the same.

OK, I will not use sqx. Pure config this time. I think we can agree that #define is case sensitive therefore if

#define true 1 is used then every true will be replaced with 1 on preprocessor level, however TrUe will not. So I tweaked config param for APC_Wheeled_03_base_F to see if TrUe will be recognised as true without define

........
						gunnerGetOutAction	= GetOutLow;
						gunnerOpticsModel	= "\A3\weapons_f\reticle\Optics_Commander_02_F";
						gunnerOpticsEffect[]= {};

						isPersonTurret 		= TrUe; /* <-- over here, was true originally */
						personTurretAction 	= "vehicle_turnout_2";

						minOutElev = -10;	maxOutElev = +25;	initOutElev = 0;
						minOutTurn = -90;	maxOutTurn = +40;	initOutTurn = 0;
......

After this ^^^ nothing has changed. Then I tweaked it other way round to see if FAlse will be recognised as false without define.

........
						gunnerGetOutAction	= GetOutLow;
						gunnerOpticsModel	= "\A3\weapons_f\reticle\Optics_Commander_02_F";
						gunnerOpticsEffect[]= {};

						isPersonTurret 		= FAlse; /* <-- over here, was true originally */
						personTurretAction 	= "vehicle_turnout_2";

						minOutElev = -10;	maxOutElev = +25;	initOutElev = 0;
						minOutTurn = -90;	maxOutTurn = +40;	initOutTurn = 0;
......

Rest assured FFV got removed in this configuration. I think this shows it pretty well that #define true/false is not nescessary, however when used there could be other reasons for it. Killzone_Kid (talk) 21:04, 16 July 2016 (CEST) ---

---

that's good research. would you be good enough to test that variable against 0 and 1 please?

bis have moved goalposts here. true/false did not work at some time in the past, perhaps still doesn't for some vars and was the reason for them being defined in #include "commondefs.h" in arma2. Hmmmmmm............

I'll have to search around for how i tested this. small memory jog was canFloat for the bmp/m113 vehicles.

The other thing you have to be aware of is that the above true false declarations are actually invalid. In a properly written config, they will be converted by the compiler (or the engine) into 1 and zero because of the almost-always-included commondefs.h (or equivalent). Bis can't have it both ways. They either want true and false to be 1 and zero, or not. They can't be half-pregnant. since the very same config MIGHT also have other true false variables that expect, or at least, formerly expected 1 and zero. This holds true *even* if they now account for this internally because commondefs will still be there in legacy addons (and missions).