Config.cpp/bin File Format - Revision history

Lou Montana: Text replacement - "\[\[Category:BIS( |_)File( |_)Formats\]\]" to "Category:Real Virtuality File Formats"

2025-05-08T11:27:10Z

Text replacement - "\[\[Category:BIS( |_)File( |_)Formats\]\]" to "Category:Real Virtuality File Formats"

← Older revision		Revision as of 13:27, 8 May 2025
Line 62:		Line 62:


	[[Category:~~BIS~~ File Formats]]		[[Category:Real Virtuality File Formats]]

Lou Montana: Add link to CPP FileFormat#syntax, Remove SQF/SQS info and some other things

2025-05-07T17:02:18Z

Add link to CPP FileFormat#syntax, Remove SQF/SQS info and some other things

← Older revision		Revision as of 19:02, 7 May 2025
Line 7:		Line 7:
	* '''config.cpp''' (pre binarised, RaPifiable text) '''or'''		* '''config.cpp''' (pre binarised, RaPifiable text) '''or'''
	* '''config.bin''' (binarised raP)		* '''config.bin''' (binarised raP)
			<!--
	~~''Both'' can co~~-~~exist in a pbo without harm. (the bin is ignored)~~		{{Feature\|informative\|An addon is a PBO, but a PBO is not necessarily an addon. Mission PBOs do '''not''' contain addon configs while mission addons do.}}
			-->
	~~'''Note:'''~~		{{Feature\|informative\|For a CPP file syntax, see {{Link\|CPP File Format#Syntax}}.}}

	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 ==		== Rules of Engagement ==

	* '''By convention only'''		* '''By convention only:'''
	** A 'bin' extension '''indicates''' ''binarised'' content.		** A 'bin' extension '''indicates''' ''binarised'' content.
	** A 'cpp' extension '''indicates''' ''pre-binarised'' text.		** A 'cpp' extension '''indicates''' ''pre-binarised'' text.
Line 26:		Line 24:
	== Usage ==		== Usage ==

	*''Most'' pbos contain binarised configs (config.bin). This is because it saves engine loading time '''and''' guarantees the {{hl\|config.cpp}} it came from was syntactically correct (no missing semicolons, duplicate or missing classes, etc). There is almost no circumstance where a {{hl\|config.cpp}} should be released in a finished product. There are exceptions from '''very''' sophisticated, veteran, addon makers~~. Their [[Scripting Tags\|OFPEC tag]] names say it all, not their {{hl\|cpp}}s~~.		*''Most'' pbos contain binarised configs (config.bin). This is because it saves engine loading time '''and''' guarantees the {{hl\|config.cpp}} it came from was syntactically correct (no missing semicolons, duplicate or missing classes, etc). There is almost no circumstance where a {{hl\|config.cpp}} should be released in a finished product. There are exceptions from '''very''' sophisticated, veteran, addon makers.
	*''Some'' pbos contain cpp because:		*''Some'' pbos contain cpp because:
	** It is a work-in-progress.		** It is a work-in-progress.
Line 39:		Line 37:
	=== 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 is derivative script dialogs. Although it can be, that specific file, is never pre-binarised. It is compiled on each mission load.		{{Feature\|informative\|See {{Link\|PreProcessor Commands#Config Parser}}.}}

	~~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)~~.		Although unusual, __EVAL and __EXEC are the only method of compiling dynamic variables during run time.
			They are '''exclusively''' useful in [[Description.ext]] and its derivative script dialogs.
			Although it can be, that specific file is never pre-binarised and is compiled on each mission load.

	~~See~~ also~~: [[PreProcessor Commands]]~~		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 is because an addon is loaded and compiled only once.

	=== Includes ===		=== Includes ===

	Includes, while unusual, are a method of pre-configuring ~~'''~~a series of ~~pbo's'''~~ for run time.		Includes, while unusual, are a method of pre-configuring a series of PBOs 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.		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.		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 is own right.		Any folder within the pbo containing a config.cpp/bin (and cfgpatches class) is automatically an addon in it is own right.

Lou Montana: Fix

2025-05-07T16:05:15Z

Fix

← Older revision		Revision as of 18:05, 7 May 2025
Line 20:		Line 20:
	** A 'bin' extension '''indicates''' ''binarised'' content.		** A 'bin' extension '''indicates''' ''binarised'' content.
	** A 'cpp' extension '''indicates''' ''pre-binarised'' text.		** 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 {{Link\|Rvmat File Format\|rvmat files}} where there is no distinction. An rvmat (e.g) contains either format.
	* 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.		* If both file formats exist in a PBO directory (e.g {{hl\|config.bin}} and {{hl\|config.cpp}}, the {{hl\|.bin}} is ignored.

	* ~~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 ==		== 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 [[Scripting Tags\|OFPEC tag]] names say it all, not their {{hl\|cpp}}s.		*''Most'' pbos contain binarised configs (config.bin). This is because it saves engine loading time '''and''' guarantees the {{hl\|config.cpp}} it came from was syntactically correct (no missing semicolons, duplicate or missing classes, etc). There is almost no circumstance where a {{hl\|config.cpp}} should be released in a finished product. There are exceptions from '''very''' sophisticated, veteran, addon makers. Their [[Scripting Tags\|OFPEC tag]] names say it all, not their {{hl\|cpp}}s.

	*''Some'' pbos contain cpp because:		*''Some'' pbos contain cpp because:
	** It is a work-in-progress.		** It is a work-in-progress.
	** they rely on #includes '''and/or'''		** they rely on #includes '''and/or'''
	** they use __EVAL/__EXEC statements, '''or'''		** they use __EVAL/__EXEC statements, '''or'''
	** the author ~~doesn't~~ know how to binarise '''or'''		** the author does not know how to binarise '''or'''
	** binarisation fails.		** 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 {{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.
Line 49:		Line 45:
	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).

	See also: [[~~PreProcessor_Commands\|~~PreProcessor Commands]]		See also: [[PreProcessor Commands]]

	=== Includes ===		=== 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
Line 65:		Line 63:


	[[Category:~~BIS_File_Formats~~]]		[[Category:BIS File Formats]]

Lou Montana: Text replacement - "[[OFPEC tags" to "[[Scripting Tags"

2024-10-02T11:01:18Z

Text replacement - "[[OFPEC tags" to "[[Scripting Tags"

← Older revision		Revision as of 13:01, 2 October 2024
Line 28:		Line 28:
	== Usage ==		== 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.		*''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 [[Scripting Tags\|OFPEC tag]] names say it all, not their {{hl\|cpp}}s.

	*''Some'' pbos contain cpp because:		*''Some'' pbos contain cpp because:

Lou Montana: Text replacement - "\[ (https?:\/\/[^ = ]+) +([^= ]+) \]" to "{{Link|$1|$2}}"

2023-04-28T14:08:52Z

Text replacement - "\[ *(https?:\/\/[^ = ]+) +([^= ]+) *\]" to "{{Link|$1|$2}}"

← Older revision		Revision as of 16:08, 28 April 2023
Line 37:		Line 37:
	** binarisation fails.		** 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 {{Link\|link= http://dev-heaven.net/projects/mikero-pbodll/files\|text= Rapify.exe}} and Kegety's [http://www.kegetys.net/arma/ 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.

Lou Montana: Text replacement - "{{ExternalLink|" to "{{Link|"

2023-01-04T15:22:36Z

Text replacement - "{{ExternalLink|" to "{{Link|"

← Older revision		Revision as of 17:22, 4 January 2023
Line 37:		Line 37:
	** binarisation fails.		** 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 {{~~ExternalLink~~\|link= http://dev-heaven.net/projects/mikero-pbodll/files\|text= Rapify.exe}} and Kegety's [http://www.kegetys.net/arma/ 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 [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.

Lou Montana: Fix typo

2022-03-05T19:16:46Z

Fix typo

← Older revision		Revision as of 21:16, 5 March 2022
Line 1:		Line 1:
			{{TOC\|side}}
	{{Feature\|UnsupportedDoc}}		{{Feature\|UnsupportedDoc}}
	~~== Intro ==~~
	~~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)
Line 11:		Line 13:

	An 'addon' is a 'pbo'. ''But'', a pbo is not necessarily an addon. Mission pbo's do '''not''' contain configs. Mission ''Addons'' do.		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 ==		== Rules of Engagement ==

	*'''By convention only'''		* '''By convention only'''
	**A 'bin' extension '''indicates''' ''binarised'' content.		** A 'bin' extension '''indicates''' ''binarised'' content.
	**A 'cpp' extension '''indicates''' ''pre-binarised'' text.		** 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.

	*~~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.

	*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 ==		== Usage ==

	*''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.		*''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 38:		Line 42:

	=== 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 is 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.

Line 47:		Line 52:

	=== Includes ===		=== 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 ==
Line 56:		Line 63:

	Any folder within the pbo containing a config.cpp/bin (and cfgpatches class) is automatically an addon in it is 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]]

Lou Montana: Text replacement - "\[(ftp|https?)\:\/\/dev-heaven\.net([^ ]+) (.+)\]" to "{{ExternalLink|link= $1://dev-heaven.net$2|text= $3}}"

2021-05-30T15:21:49Z

Text replacement - "\[(ftp|https?)\:\/\/dev-heaven\.net([^ ]+) (.+)\]" to "{{ExternalLink|link= $1://dev-heaven.net$2|text= $3}}"

← Older revision		Revision as of 17:21, 30 May 2021
Line 33:		Line 33:
	** binarisation fails.		** 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 [http://dev-heaven.net/projects/mikero-pbodll/files Rapify.exe] and Kegety's [http://www.kegetys.net/arma/ 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 {{ExternalLink\|link= http://dev-heaven.net/projects/mikero-pbodll/files\|text= Rapify.exe}} and Kegety's [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.

Lou Montana: Text replacement - "{{unsupported-doc}}" to "{{Feature|UnsupportedDoc}}"

2021-02-01T13:57:07Z

Text replacement - "{{unsupported-doc}}" to "{{Feature|UnsupportedDoc}}"

← Older revision		Revision as of 15:57, 1 February 2021
Line 1:		Line 1:
	{{~~unsupported-doc~~}}		{{Feature\|UnsupportedDoc}}
	== Intro ==		== Intro ==
	Two mutually exclusive file formats exist for '''addons'''. Either:		Two mutually exclusive file formats exist for '''addons'''. Either:

Lou Montana: Text replacement - " (={2,})([^ = ])(.)([^ = ])(={2,}) " to " $1 $2$3$4 $5 "

2021-01-31T17:49:56Z

Text replacement - " (={2,})([^ = ])(.*)([^ = ])(={2,}) * " to " $1 $2$3$4 $5 "

← Older revision		Revision as of 19:49, 31 January 2021
Line 1:		Line 1:
	{{unsupported-doc}}		{{unsupported-doc}}
	==Intro==		== Intro ==
	Two mutually exclusive file formats exist for '''addons'''. Either:		Two mutually exclusive file formats exist for '''addons'''. Either:

Line 12:		Line 12:
	An 'addon' is a 'pbo'. ''But'', a pbo is not necessarily an addon. Mission pbo's do '''not''' contain configs. Mission ''Addons'' do.		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==		== Rules of Engagement ==

	*'''By convention only'''		*'''By convention only'''
Line 22:		Line 22:
	*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.		*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==		== Usage ==

	*''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.		*''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.
Line 37:		Line 37:
	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 is 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.

Line 46:		Line 46:
	See also: [[PreProcessor_Commands\|PreProcessor Commands]]		See also: [[PreProcessor_Commands\|PreProcessor Commands]]

	===Includes===		=== 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.