TokenNameValueTypes: Difference between revisions

From Bohemia Interactive Community
Jump to navigation Jump to search
mNo edit summary
m (Some wiki formatting)
(11 intermediate revisions by 7 users not shown)
Line 1: Line 1:
==Intro==
{{TOC|side}}
<big>Token Name values</big>
<big>Token Name values</big>


The ofp engine, and specifically, a raPified (binarised) file identifies only a few different 'types' of Token Name
The {{ofp}} engine, and specifically, a raPified (binarised) file identifies only a few different 'types' of Token Name


aString = "A string";
<syntaxhighlight lang="cpp">
anInteger = 1234567;
aString = "A string";
aFloat = 0.0123;
anInteger = 1234567;
anArray[] = {.....};
aFloat = 0.0123;
anArray[] = { ... };
</syntaxhighlight>


Everything that can be stated in a config.cpp, a description.ext, a mission.sqm for TokenName value pairs devolves to one of the above 'types'.
Everything that can be stated in a [[Config.cpp]], a [[Description.ext]], a [[Mission.sqm]] for TokenName value pairs devolves to one of the above 'types'.
 
 
== Integers ==
 
<syntaxhighlight lang="cpp">
anInteger = 99;
</syntaxhighlight>
 
integer values are signed values held in four bytes of memory when raPified.
 
=== Boolean ===


==Boolean==
Separately, a '''fifth''' type exists called boolean.
Separately, a '''fifth''' type exists called boolean.


aBoolean = 0;
<syntaxhighlight lang="cpp">
aBoolean = 0;
</syntaxhighlight>


''In fact'' the engine only stores and 'sees' this value as an integer. But by convention in humanly readable text files (config.cpp vs config.bin), integers that can only have zero or non zero values are declared in statements as
''In fact'' the engine only stores and 'sees' this value as an integer. But by convention in humanly readable text files (config.cpp vs config.bin), integers that can only have zero or non zero values are declared in statements as


#define false 0
<syntaxhighlight lang="cpp">
#define true 1
#define false 0
LightOn = true;
#define true 1
LightOn = true;
</syntaxhighlight>


A '''boolean''' as such, ''does not exist'' in binarised (raP) files. It is an integer. It is ''only'' a poetic licence for an author when creating text (config.cpp) files.
A '''boolean''' as such, ''does not exist'' in binarised (raP) files. It is an integer. It is ''only'' a poetic licence for an author when creating text (config.cpp) files.


==Integers==
=== Degrees ===
 
a signed integer between -360 and +360. There is no degrees type. It is simply a poetic licence in well written config.cpp's, similar to boolean.


anInteger = 99;


integer values are signed values held in four bytes of memory when raPified.
== Floats ==


===Degrees===
<syntaxhighlight lang="cpp">
aFloat = 1.0;
</syntaxhighlight>


a signed integer between -360 and +360. There is no degrees type. It is simply a poetic licence in well written config.cpp's, similar to boolean.
float values are held in four bytes of memory when raPified. Note that this automatically means it is not, in C terms a double.


==Floats==


aFloat=1.0;
== Strings ==


float values are held in four bytes of memory when raPified. Note that this automatically means it is not, in C terms a double.
<syntaxhighlight lang="cpp">
aString = "text";
anotherString = "42";
</syntaxhighlight>


==Strings==
'''<u>Anything</u>''' enclosed in quotes ( "..." ) is automatically a string. <u>In addition</u>, anything that cannot be represented as a float or integer, is also a string.


'''<u>Anything</u>''' enclosed in quotes ( "..." ) is automatically a string. <u>In addition</u>, anything that cannot be represented as a float or integer, is also a string.
=== MathFormula ===
===MathFormula===


A catch to the unwary is
A catch to the unwary is


aString= 1 * 6 + 99/3;
<syntaxhighlight lang="cpp">
aString = 1 * 6 + 99 / 3;
</syntaxhighlight>


this is '''not''' binarised into an integer (or a float), but remains 'in string'
this is '''not''' binarised into an integer (or a float), but remains 'in string'


See [[#At the End of the Day]] for what actually happens to this 'string'.
See {{HashLink|#At the End of the Day}} for what actually happens to this 'string'.


==Arrays[]={...};==
 
== Arrays ==


Arrays are of unrestricted content in terms of what 'types' they can have in them, and, their number.  
Arrays are of unrestricted content in terms of what 'types' they can have in them, and, their number.  
Line 61: Line 84:
Arrays can have mixtures of type in the same array
Arrays can have mixtures of type in the same array


sound[] = {"fuel_explosion",10.000000,1};
<syntaxhighlight lang="cpp">
sound[] = { "fuel_explosion", 10.000000, 1 };
</syntaxhighlight>


Quite frequently a specific array will have a fixed number of dimensions. For instance
Quite frequently a specific array will have a fixed number of dimensions. For instance


color[]={1.0,0.3,0.6,0.0};
<syntaxhighlight lang="cpp">
color[] = { 1.0, 0.3, 0.6, 0.0 };
</syntaxhighlight>


The fact is, the color array as used by the ofp engine, has, 4 values. (all of them floats)
The fact is, the color array as used by the {{ofp}} engine, has, 4 values. (all of them floats)


However consider this
However consider this
Line 77: Line 104:
Other models carry more (or less).
Other models carry more (or less).


==At the End of the Day==
 
== At the End of the Day ==


The engine will always look at its raPified (binarised) data in the context it wants. A config.cpp - generally a text file - will always be processed into an internal config.bin (raPified) before use by the engine.
The engine will always look at its raPified (binarised) data in the context it wants. A config.cpp - generally a text file - will always be processed into an internal config.bin (raPified) before use by the engine.
Line 83: Line 111:
Thus, while a value is stated to be a float
Thus, while a value is stated to be a float


count=1.0;
<syntaxhighlight lang="cpp">
count = 1.0;
</syntaxhighlight>


it is only the '''TokenName''' that is of interest to the engine initially.
it is only the '''TokenName''' that is of interest to the engine initially.
Line 89: Line 119:
Thus
Thus


count="1.0"; // a string
<syntaxhighlight lang="cpp">
count=1;     // an integer
count = 1; // an integer
count="1"     // a string that looks like an integer
count = "1"; // a string that looks like an integer
count = 1.0; // a float
count = "1.0"; // a string that looks like an integer
</syntaxhighlight>


'''all''' represent the floating value '''1.0'''.
'''all''' represent the floating value '''1.0'''.
Line 101: Line 134:
For examples of this duality see [[CfgVehicles Config Reference#count|armor]], and [[CfgVehicles Config Reference#count|count]] in the [[CfgVehicles Config Reference|config reference]].
For examples of this duality see [[CfgVehicles Config Reference#count|armor]], and [[CfgVehicles Config Reference#count|count]] in the [[CfgVehicles Config Reference|config reference]].


[[Category:Operation Flashpoint: Modelling]]
 
[[Category:ArmA: Addon Configuration]]
{{GameCategory|ofp|Modelling}}
{{GameCategory|arma1|Addon Configuration}}

Revision as of 14:26, 20 October 2021

Token Name values

The Operation Flashpoint engine, and specifically, a raPified (binarised) file identifies only a few different 'types' of Token Name

aString = "A string";
anInteger = 1234567;
aFloat = 0.0123;
anArray[] = { ... };

Everything that can be stated in a Config.cpp, a Description.ext, a Mission.sqm for TokenName value pairs devolves to one of the above 'types'.


Integers

anInteger = 99;

integer values are signed values held in four bytes of memory when raPified.

Boolean

Separately, a fifth type exists called boolean.

aBoolean = 0;

In fact the engine only stores and 'sees' this value as an integer. But by convention in humanly readable text files (config.cpp vs config.bin), integers that can only have zero or non zero values are declared in statements as

#define false 0
#define true 1
LightOn = true;

A boolean as such, does not exist in binarised (raP) files. It is an integer. It is only a poetic licence for an author when creating text (config.cpp) files.

Degrees

a signed integer between -360 and +360. There is no degrees type. It is simply a poetic licence in well written config.cpp's, similar to boolean.


Floats

aFloat = 1.0;

float values are held in four bytes of memory when raPified. Note that this automatically means it is not, in C terms a double.


Strings

aString = "text";
anotherString = "42";

Anything enclosed in quotes ( "..." ) is automatically a string. In addition, anything that cannot be represented as a float or integer, is also a string.

MathFormula

A catch to the unwary is

aString = 1 * 6 + 99 / 3;

this is not binarised into an integer (or a float), but remains 'in string'

See At the End of the Day for what actually happens to this 'string'.


Arrays

Arrays are of unrestricted content in terms of what 'types' they can have in them, and, their number.

Arrays, can be (and often are) embedded within arrays.

Arrays can have mixtures of type in the same array

sound[] = { "fuel_explosion", 10.000000, 1 };

Quite frequently a specific array will have a fixed number of dimensions. For instance

color[] = { 1.0, 0.3, 0.6, 0.0 };

The fact is, the color array as used by the Operation Flashpoint engine, has, 4 values. (all of them floats)

However consider this

cargoAction[]={"ManActM113Medic","ManActM113Medic","ManActM113Injured"};

the number of elements in this array, happens to be 3, and happens to describe a Medic bmp that can carry three soldiers!

Other models carry more (or less).


At the End of the Day

The engine will always look at its raPified (binarised) data in the context it wants. A config.cpp - generally a text file - will always be processed into an internal config.bin (raPified) before use by the engine.

Thus, while a value is stated to be a float

count = 1.0;

it is only the TokenName that is of interest to the engine initially.

Thus

count = 1;			// an integer
count = "1";		// a string that looks like an integer
count = 1.0;		// a float
count = "1.0";		// a string that looks like an integer

all represent the floating value 1.0.

The engine will massage the token name to relevence.

In config.cpp, and thus its raPified equivalent config.bin, it is a matter of convenience and an ease in processing load to write the TokenName in the 'type' most often used.

For examples of this duality see armor, and count in the config reference.