{"name":"Config.cpp/bin File Format","title":"Config.cpp/bin File Format","type":"topic","url":"https://community.bistudio.com/wiki/Config.cpp/bin_File_Format","revid":373403,"updated":"2025-05-08T11:27:10Z","aliases":["BIN","CPP","Config.bin","Config.cpp","config.cpp"],"markdown":"> **Disclaimer: This page describes internal undocumented structures of Bohemia Interactive software.**\n>\n> This page contains unofficial information.\n>\n> 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.\n> 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.\n\nTwo mutually exclusive file formats exist for **addons**:\n\n- **config.cpp** (pre binarised, RaPifiable text) **or**\n- **config.bin** (binarised raP)\n\n> [!NOTE]\n> For a CPP file syntax, see CPP File Format - Syntax.\n\n### Rules of Engagement\n\n- **By convention only:**\n  - A 'bin' extension **indicates** *binarised* content.\n  - A 'cpp' extension **indicates** *pre-binarised* text.\n- 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 (e.g) contains either format.\n- If both file formats exist in a PBO directory (e.g `config.bin` and `config.cpp`, the `.bin` is ignored.\n\n### Usage\n\n- *Most* pbos contain binarised configs (config.bin). This is because it saves engine loading time **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.\n- *Some* pbos contain cpp because:\n  - It is a work-in-progress.\n  - they rely on #includes **and/or**\n  - they use __EVAL/__EXEC statements, **or**\n  - the author does not know how to binarise **or**\n  - binarisation fails.\n\nThere is no binarised equivalent for exec/eval or include.\n\n#### Exec/Eval\n\n> [!NOTE]\n> See PreProcessor Commands - Config Parser.\n\nAlthough unusual, __EVAL and __EXEC are the only method of compiling dynamic variables during run time.\nThey are **exclusively** useful in Description.ext and its derivative script dialogs.\nAlthough it can be, that specific file is never pre-binarised and is compiled on each mission load.\n\nSome 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.\nThis is because an addon is loaded and compiled only once.\n\n#### Includes\n\nIncludes, while unusual, are a method of pre-configuring a series of PBOs for run time.\nThere 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.\nIn 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.\n\nFor these architectures to work, they require config.cpp's since there is no equivalent in raP binary for #include or __EVAL.\n\n### Many configs, same PBO\n\nAny mission makers familiar with campaign architecture implicitly understand that this is simply packaging multiple addons inside a single one.\n\nAny folder within the pbo containing a config.cpp/bin (and cfgpatches class) is automatically an addon in it is own right.","sections":[{"heading":null,"level":1,"markdown":"> **Disclaimer: This page describes internal undocumented structures of Bohemia Interactive software.**\n>\n> This page contains unofficial information.\n>\n> 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.\n> 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.\n\nTwo mutually exclusive file formats exist for **addons**:\n\n- **config.cpp** (pre binarised, RaPifiable text) **or**\n- **config.bin** (binarised raP)\n\n> [!NOTE]\n> For a CPP file syntax, see CPP File Format - Syntax."},{"heading":"Rules of Engagement","level":3,"markdown":"- **By convention only:**\n  - A 'bin' extension **indicates** *binarised* content.\n  - A 'cpp' extension **indicates** *pre-binarised* text.\n- 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 (e.g) contains either format.\n- If both file formats exist in a PBO directory (e.g `config.bin` and `config.cpp`, the `.bin` is ignored."},{"heading":"Usage","level":3,"markdown":"- *Most* pbos contain binarised configs (config.bin). This is because it saves engine loading time **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.\n- *Some* pbos contain cpp because:\n  - It is a work-in-progress.\n  - they rely on #includes **and/or**\n  - they use __EVAL/__EXEC statements, **or**\n  - the author does not know how to binarise **or**\n  - binarisation fails.\n\nThere is no binarised equivalent for exec/eval or include."},{"heading":"Exec/Eval","level":4,"markdown":"> [!NOTE]\n> See PreProcessor Commands - Config Parser.\n\nAlthough unusual, __EVAL and __EXEC are the only method of compiling dynamic variables during run time.\nThey are **exclusively** useful in Description.ext and its derivative script dialogs.\nAlthough it can be, that specific file is never pre-binarised and is compiled on each mission load.\n\nSome 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.\nThis is because an addon is loaded and compiled only once."},{"heading":"Includes","level":4,"markdown":"Includes, while unusual, are a method of pre-configuring a series of PBOs for run time.\nThere 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.\nIn 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.\n\nFor these architectures to work, they require config.cpp's since there is no equivalent in raP binary for #include or __EVAL."},{"heading":"Many configs, same PBO","level":3,"markdown":"Any mission makers familiar with campaign architecture implicitly understand that this is simply packaging multiple addons inside a single one.\n\nAny folder within the pbo containing a config.cpp/bin (and cfgpatches class) is automatically an addon in it is own right."}],"categories":["Real Virtuality File Formats"],"groups":["Tools and File Formats"]}