Config.cpp: Difference between revisions

From Bohemia Interactive Community
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 1: Line 1:
The '''''config.cpp''''' file is the main configuration file for Operation Flashpoint in text form. (not binarized). This file contains all of the important information for configuring a model within OFP. The OFP engine is capable of reading config.cpp files in both binary ([[Config.bin|config.bin]]) and non-binarized form.
The '''''config.cpp''''' file is the humanly readable, 'unraPified', text file equivalent of a config.bin.


Config.cpp is the classic class-and-tokenpair arrangement identical in every respect to all other similar files (rvmat, mission.sqm, bisurf, etc). As such, it is subject to rapify (binarising) BEFORE the engine uses it. This can be done during engine load time, or, preferably, in a pre-rapified config.bin.
The master config.bin is held in dta\ for all engines.
When present in an addon (and only ever present in an addon), the config.cpp or config.bin in that addon, is merged into the engine's config.bin.
The ONLY config.bin that exists in game, is one gigantic monster, consisting of dta\config.bin + all addons.
At least two exceptionally helpful, mission based, tools exist to examine the content of this monster. They are effective and incredible time savers when you are looking for what-went-bang.
*dumpConfig.utes:<shreds-of-sanity@gmx.net>
dumps the monster to a text file.
*ConfigExplorer2_Test.utes
interactive examiner
You probably shouldn't leave home without them.
-----
Conventionally, a config.cpp is the text equivalent of a config.bin. This in fact is a lie.
ALL engine's accept EITHER a config.bin, a config.cpp OR BOTH.
WHICHEVER config contains 'text' (ie unbinarised) is the master, the other file, is ignored.
IF and when the engine discovers a TEXT config, it immediately rapifies it for internal use (binarises). How it is rapifed (ofp format or arma format) is immaterial. The text is converted to Rap format appropriate to the engine.
*It is quite common during a patch or beta development process for a .bin and a .cpp to co-exist. The bin, is simply ignored.
*It is quite uncommon to have these two files co-existing in a released addon. If present, it should alert you to what is, in effect, a patch of the original.
Note that during engine load time, where it is busily assembling a single config.bin monster, the final step in that process is to localise all $STR_  variables encountered. These 'tokens' are held in either a stringtable.csv or .xml 'anywhere'. If present in the same folder, the xml takes precedence and the csv is ignored.
-----
These links may be of interest:
[[CfgVehicles|Here]] you can find a tree of CfgVehicles.
[[CfgVehicles|Here]] you can find a tree of CfgVehicles.


These links may be of interest:
*[[Models:_NoClassnames_-_A_:_J|Models without classnames, A - J]]
*[[Models:_NoClassnames_-_A_:_J|Models without classnames, A - J]]
*[[Models:_NoClassnames_-_K_:_M|Models without classnames, K - M]]
*[[Models:_NoClassnames_-_K_:_M|Models without classnames, K - M]]

Revision as of 05:02, 14 August 2010

The config.cpp file is the humanly readable, 'unraPified', text file equivalent of a config.bin.

Config.cpp is the classic class-and-tokenpair arrangement identical in every respect to all other similar files (rvmat, mission.sqm, bisurf, etc). As such, it is subject to rapify (binarising) BEFORE the engine uses it. This can be done during engine load time, or, preferably, in a pre-rapified config.bin.


The master config.bin is held in dta\ for all engines.

When present in an addon (and only ever present in an addon), the config.cpp or config.bin in that addon, is merged into the engine's config.bin.

The ONLY config.bin that exists in game, is one gigantic monster, consisting of dta\config.bin + all addons.

At least two exceptionally helpful, mission based, tools exist to examine the content of this monster. They are effective and incredible time savers when you are looking for what-went-bang.

  • dumpConfig.utes:<shreds-of-sanity@gmx.net>
dumps the monster to a text file.
  • ConfigExplorer2_Test.utes
interactive examiner

You probably shouldn't leave home without them.


Conventionally, a config.cpp is the text equivalent of a config.bin. This in fact is a lie.

ALL engine's accept EITHER a config.bin, a config.cpp OR BOTH.

WHICHEVER config contains 'text' (ie unbinarised) is the master, the other file, is ignored.

IF and when the engine discovers a TEXT config, it immediately rapifies it for internal use (binarises). How it is rapifed (ofp format or arma format) is immaterial. The text is converted to Rap format appropriate to the engine.

  • It is quite common during a patch or beta development process for a .bin and a .cpp to co-exist. The bin, is simply ignored.
  • It is quite uncommon to have these two files co-existing in a released addon. If present, it should alert you to what is, in effect, a patch of the original.

Note that during engine load time, where it is busily assembling a single config.bin monster, the final step in that process is to localise all $STR_ variables encountered. These 'tokens' are held in either a stringtable.csv or .xml 'anywhere'. If present in the same folder, the xml takes precedence and the csv is ignored.


These links may be of interest: Here you can find a tree of CfgVehicles.

A fully commented config.cpp file can be found at the Oxygen web site.