Config.cpp/bin File Format: Difference between revisions

From Bohemia Interactive Community
Jump to navigation Jump to search
mNo edit summary
 
m (Text replacement - "\[ *(https?:\/\/[^ = ]+) +([^= ]+) *\]" to "{{Link|$1|$2}}")
 
(11 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{unsupported-doc}}
{{TOC|side}}
==Intro==
{{Feature|UnsupportedDoc}}
Two mutually exclusive file formats exist for '''addons'''. Either:


*config.cpp (pre binarised, RaPifiable text) '''or'''
 
*config.bin (binarised raP)
Two mutually exclusive file formats exist for '''addons''':
 
* '''config.cpp''' (pre binarised, RaPifiable text) '''or'''
* '''config.bin''' (binarised raP)


''Both'' can co-exist in a pbo without harm. (the bin is ignored)
''Both'' can co-exist in a pbo without harm. (the bin is ignored)


Note that an 'addon' is a 'pbo'. ''But'', a pbo is not necessarily an addon. Mission pbo's do '''not''' contain configs. Mission ''Addons'' do.
'''Note:'''
==Rules of Engagement==
 
An 'addon' is a 'pbo'. ''But'', a pbo is not necessarily an addon. Mission pbo's do '''not''' contain configs. Mission ''Addons'' do.
 


*'''By convention only'''
== Rules of Engagement ==
**A 'bin' extension '''indicates''' ''binarised'' content.
**A 'cpp' extension '''indicates''' ''pre-binarised'' text.


*A cpp can, as equally, contain binarised content. No harm is done, and, indeed, this is familiar territory to rvmat files where there is no distinction. An rvmat (eg) contains either format.
* '''By convention only'''
** A 'bin' extension '''indicates''' ''binarised'' content.
** A 'cpp' extension '''indicates''' ''pre-binarised'' text.


*Unconditionally, no matter what, irrespective of datestamps, irrespective of ''actual'' content, if both exist in the same folder of a pbo, the .bin is ignored.
* A cpp can, as equally, contain binarised content. No harm is done, and, indeed, this is familiar territory to rvmat files where there is no distinction. An rvmat (eg) contains either format.


==Usage==
* Unconditionally, no matter what, irrespective of datestamps, irrespective of ''actual'' content, if both exist in the same folder of a pbo, the .bin is ignored.


*''Most'' pbos contain binarised configs. (config.bin). This because it saves engine load times, '''and''', garantees the config.cpp it came from was syntactically correct (no missing semicolons, duplicate or missing classes, etc). There is almost no circumstance where a config.cpp should be released in a finished product. There are exceptions from '''very''' sophisticated, veteran, addon makers. Their ofpec_tag names say it all, not, their cpp's.
 
== Usage ==
 
*''Most'' pbos contain binarised configs. (config.bin). This because it saves engine load times '''and''' guarantees the config.cpp it came from was syntactically correct (no missing semicolons, duplicate or missing classes, etc). There is almost no circumstance where a config.cpp should be released in a finished product. There are exceptions from '''very''' sophisticated, veteran, addon makers. Their [[OFPEC tags|OFPEC tag]] names say it all, not their {{hl|cpp}}s.


*''Some'' pbos contain cpp because:
*''Some'' pbos contain cpp because:
Line 30: Line 37:
** binarisation fails.  
** binarisation fails.  


Failed binarise.exe is frustration. But, it's generally telling the truth, and it ''generally'' results in the rpt log being full of errors and warnings when the engine compiles the equivalent cpp. Some rare exceptions are in """"Use 'of' ""some strange{syntax}"""; and some #ifndef statements where binarise.exe cannot cope. 3rd party tools such as Mikero's [http://dev-heaven.net/projects/mikero-pbodll/files|Rapify.exe] and Kegety's [http://dev-heaven.net/projects/mikero-pbodll/files|Rapify.exe|Rap.exe] can help.
Failed binarise.exe is frustration. But, it is generally telling the truth, and it ''generally'' results in the rpt log being full of errors and warnings when the engine compiles the equivalent cpp. Some rare exceptions are in """"Use 'of' ""some strange{syntax}"""; and some #ifndef statements where binarise.exe cannot cope. 3rd party tools such as Mikero's {{Link|link= http://dev-heaven.net/projects/mikero-pbodll/files|text= Rapify.exe}} and Kegety's {{Link|http://www.kegetys.net/arma/|Rap.exe}} can help.


There is no binarised equivalent for exec/eval or include.
There is no binarised equivalent for exec/eval or include.


===Exec/Eval===
=== Exec/Eval ===
Although unusual, EVAL and EXEC are the only method of compiling dynamic variables '''during''' run time. They are '''exclusively''' useful in description.ext and it's derivative script dialogs. Although it can be, that specific file, is never pre-binarised. It is compiled on each mission load.
 
Although unusual, EVAL and EXEC are the only method of compiling dynamic variables '''during''' run time. They are '''exclusively''' useful in description.ext and it is derivative script dialogs. Although it can be, that specific file, is never pre-binarised. It is compiled on each mission load.


Some, very few, dialog addons also use this method in their config.cpp's, BUT, in this circumstance, they offer no additional benefit to using #defines. This because an addon is loaded and compiled, once. Bis have attempted to develop ''dynamic addons'' and stopped. Should they resurrect it '''....'''
Some, very few, dialog addons also use this method in their config.cpp's, BUT, in this circumstance, they offer no additional benefit to using #defines. This because an addon is loaded and compiled, once. Bis have attempted to develop ''dynamic addons'' and stopped. Should they resurrect it '''....'''
Line 41: Line 49:
Note that there is deeper level of sophistication here that an _EVAL used in a #include in a config.cpp, could *separately* be used in sqf/sqs script. But, there simply isn't a reason for the config.cpp to be unbinarised at this moment (see above dynamic addons).
Note that there is deeper level of sophistication here that an _EVAL used in a #include in a config.cpp, could *separately* be used in sqf/sqs script. But, there simply isn't a reason for the config.cpp to be unbinarised at this moment (see above dynamic addons).


===Includes===
See also: [[PreProcessor_Commands|PreProcessor Commands]]
 
=== Includes ===
 
Includes, while unusual, are a method of pre-configuring '''a series of pbo's''' for run time. There are many themes, but the main thrust is a common, text-based pbo, containing #defines. This is accessed from a series of dependent pbo's. In this manner, you can alter and update a common pbo and all the children don't require updating. ace_x and cba are popular architects of this scheme.  
Includes, while unusual, are a method of pre-configuring '''a series of pbo's''' for run time. There are many themes, but the main thrust is a common, text-based pbo, containing #defines. This is accessed from a series of dependent pbo's. In this manner, you can alter and update a common pbo and all the children don't require updating. ace_x and cba are popular architects of this scheme.  


For these architectures to work, they require config.cpp's since there is no equivalent in raP binary for #include or __EVAL
For these architectures to work, they require config.cpp's since there is no equivalent in raP binary for #include or __EVAL


==Many configs, same pbo==
 
== Many configs, same pbo ==


Any mission makers familiar with campaign architecture implicitly 'understand' that this is simply packaging multiple addons inside a single one.
Any mission makers familiar with campaign architecture implicitly 'understand' that this is simply packaging multiple addons inside a single one.


Any folder within the pbo containing a config.cpp/bin (and cfgpatches class) is automatically an addon in it's own right.
Any folder within the pbo containing a config.cpp/bin (and cfgpatches class) is automatically an addon in it is own right.
 


[[Category:BIS_File_Formats]]
[[Category:BIS_File_Formats]]

Latest revision as of 16:08, 28 April 2023

bi symbol white.png
Disclaimer: This page describes internal undocumented structures of Bohemia Interactive software.

This page contains unofficial information.

Some usage of this information may constitute a violation of the rights of Bohemia Interactive and is in no way endorsed or recommended by Bohemia Interactive.
Bohemia Interactive is not willing to tolerate use of such tools if it contravenes any general licenses granted to end users of this community wiki or BI products.


Two mutually exclusive file formats exist for addons:

  • config.cpp (pre binarised, RaPifiable text) or
  • config.bin (binarised raP)

Both can co-exist in a pbo without harm. (the bin is ignored)

Note:

An 'addon' is a 'pbo'. But, a pbo is not necessarily an addon. Mission pbo's do not contain configs. Mission Addons do.


Rules of Engagement

  • By convention only
    • A 'bin' extension indicates binarised content.
    • A 'cpp' extension indicates pre-binarised text.
  • A cpp can, as equally, contain binarised content. No harm is done, and, indeed, this is familiar territory to rvmat files where there is no distinction. An rvmat (eg) contains either format.
  • Unconditionally, no matter what, irrespective of datestamps, irrespective of actual content, if both exist in the same folder of a pbo, the .bin is ignored.


Usage

  • Most pbos contain binarised configs. (config.bin). This because it saves engine load times and guarantees the config.cpp it came from was syntactically correct (no missing semicolons, duplicate or missing classes, etc). There is almost no circumstance where a config.cpp should be released in a finished product. There are exceptions from very sophisticated, veteran, addon makers. Their OFPEC tag names say it all, not their cpps.
  • Some pbos contain cpp because:
    • It is a work-in-progress.
    • they rely on #includes and/or
    • they use __EVAL/__EXEC statements, or
    • the author doesn't know how to binarise or
    • binarisation fails.

Failed binarise.exe is frustration. But, it is generally telling the truth, and it generally results in the rpt log being full of errors and warnings when the engine compiles the equivalent cpp. Some rare exceptions are in """"Use 'of' ""some strange{syntax}"""; and some #ifndef statements where binarise.exe cannot cope. 3rd party tools such as Mikero's Rapify.exe (dead link) and Kegety's Rap.exe can help.

There is no binarised equivalent for exec/eval or include.

Exec/Eval

Although unusual, EVAL and EXEC are the only method of compiling dynamic variables during run time. They are exclusively useful in description.ext and it is derivative script dialogs. Although it can be, that specific file, is never pre-binarised. It is compiled on each mission load.

Some, very few, dialog addons also use this method in their config.cpp's, BUT, in this circumstance, they offer no additional benefit to using #defines. This because an addon is loaded and compiled, once. Bis have attempted to develop dynamic addons and stopped. Should they resurrect it ....

Note that there is deeper level of sophistication here that an _EVAL used in a #include in a config.cpp, could *separately* be used in sqf/sqs script. But, there simply isn't a reason for the config.cpp to be unbinarised at this moment (see above dynamic addons).

See also: PreProcessor Commands

Includes

Includes, while unusual, are a method of pre-configuring a series of pbo's for run time. There are many themes, but the main thrust is a common, text-based pbo, containing #defines. This is accessed from a series of dependent pbo's. In this manner, you can alter and update a common pbo and all the children don't require updating. ace_x and cba are popular architects of this scheme.

For these architectures to work, they require config.cpp's since there is no equivalent in raP binary for #include or __EVAL


Many configs, same pbo

Any mission makers familiar with campaign architecture implicitly 'understand' that this is simply packaging multiple addons inside a single one.

Any folder within the pbo containing a config.cpp/bin (and cfgpatches class) is automatically an addon in it is own right.

Retrieved from "https://community.bistudio.com/wiki?title=Config.cpp/bin_File_Format&oldid=339442"