TokenNameValueTypes: Difference between revisions

From Bohemia Interactive Community
Jump to navigation Jump to search
m (put in main category)
mNo edit summary
Line 20: Line 20:
  #define true 1
  #define true 1
  LightOn = true;
  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.
'''Floats vs Integers'''
''In general'' the two types are quite distinct. Certainly, and specifically, the engine recognises them as being distinct. ''However'', some, very few TokenNames can be represented by both 'types'. See armor in the config reference for an example.
'''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. Be careful here when 'looking at' items that are, in fact, #defines. #defines are (mostly) integers.
#define MYTestCode 1
myTest=MYTestCode;
appears to be a string, it is not.


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

Revision as of 23:31, 5 July 2006

Token Name values

The ofp engine, and specifically, a binarised file (signature raP) 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'.

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.

Floats vs Integers

In general the two types are quite distinct. Certainly, and specifically, the engine recognises them as being distinct. However, some, very few TokenNames can be represented by both 'types'. See armor in the config reference for an example.

Strings

Anything enclosed in quotes ( "..." ) is automatically a string. In addition, anything that cannot be represented as a float or integer, is also a string. Be careful here when 'looking at' items that are, in fact, #defines. #defines are (mostly) integers.

  1. define MYTestCode 1
myTest=MYTestCode;

appears to be a string, it is not.

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