Mikero – User talk

From Bohemia Interactive Community
Jump to navigation Jump to search
m (Text replacement - "Killzone Kid" to "Killzone_Kid")
 
(32 intermediate revisions by 10 users not shown)
Line 1: Line 1:
I edited several changes you made about scripting types, because they were not valid for scripting. I suppose you mixed scripting and config writing here.
--[[User:Suma|Suma]] 11:41, 30 June 2006 (CEST)


yes. i did. Since there's nothing really 'out there' for addon token names, i'm starting somewhere




Hi Mikero, please check [[Talk:CfgVehicles Config Reference | this]]. Thanks.
== Booleans ==


--[[User:Raedor|Raedor]] 13:19, 3 July 2006 (CEST)
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
<code style="display: block">thisistrue = truE;
thisisfalse = FaLse;
</code>


done, thanks
then run the following commands in debug console:


--[[User:Mikero|ook?]] 14:37, 7 July 2006 (CEST)
<code style="display: block">hint str getMissionConfigValue "thisistrue"; //"truE"
hint str getMissionConfigValue "thisisfalse"; //"FaLse"
</code>


== Terry Pratchett fan? ==
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:


Just wondered, because of your alias :-) --[[User:Hardrock|hardrock]] 01:57, 21 July 2006 (CEST)
<code style="display: block">hint str getNumber (getMissionConfig "thisistrue"); //1
hint str getNumber (getMissionConfig "thisisfalse"); //0
</code>


I would sometimes prefer my Sig to be Vimes );  --[[User:Mikero|ook?]] 02:00, 21 July 2006 (CEST)
If there are #defines in config that explicitly link true to 1 and false to 0, then it could be for some other reason. [[User:Killzone_Kid|Killzone_Kid]] ([[User talk: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
<code style="display: block">#define true 1</code>
is used then every <tt>true</tt> will be replaced with 1 on preprocessor level, however <tt>TrUe</tt> will not. So I tweaked config param for APC_Wheeled_03_base_F to see if <tt>TrUe</tt> will be recognised as <tt>true</tt> without define
<syntaxhighlight lang=cpp>
........
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;
......
</syntaxhighlight>
After this ^^^ nothing has changed. Then I tweaked it other way round to see if <tt>FAlse</tt> will be recognised as <tt>false</tt> without define.
<syntaxhighlight lang=cpp>
........
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;
......
</syntaxhighlight>
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. [[User:Killzone_Kid|Killzone_Kid]] ([[User talk: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).
~
[[User:Mikero|ook?]]

Latest revision as of 13:48, 12 March 2024


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