{"name":"Arma 3: Creating an Addon","title":"Arma 3: Creating an Addon","type":"topic","url":"https://community.bistudio.com/wiki/Arma_3:_Creating_an_Addon","revid":378926,"updated":"2026-08-19T09:56:34Z","aliases":[],"markdown":"This page explains the steps required to create an addon (PBO file).\n\n### Prerequisites\n\n- An addon making tool such as:\n- Arma 3 Tools\n- [Mikero's Tools](https://mikero.bytex.digital/)\n- [HEMTT](https://hemtt.dev/) ([GitHub](https://github.com/BrettMayson/HEMTT))\n- A text editor, such as Notepad++ or Visual Studio Code.\n\n### Preparing the Addon\n\nPlace all required files (scripts, textures, fonts, models, etc.) in an empty folder, which hereafter will be referred to as the **Addon folder**.\nIt is recommended to organise the files into subfolders to avoid clutter.\n\nIn order to make this addon fully functional, at least two additional steps are required, which are explained in further detail in the subsequent sections:\n\n- A file named config.cpp should be created in the root of the Addon Folder for the game to be able to recognise the addon contents.\n- Paths to all files in the addon, such as script paths, model paths, etc. should be adjusted with respect to the Addon Prefix.\n\n### Addon Prefix\n\nIn simple terms, Addon Prefix is a virtual (in-game) path to the root folder of an addon. The game uses the addon prefix to find the files in the addon. This virtual path should preferably be unique to prevent collision with other addon files.\nThe addon prefix is added to the PBO properties by the packing tool.\n\nThe addon prefix is typically a single word:\n\n```\nAddon_Name\n```\n\nIt is also possible to use a directory-like prefix (where each pseudo-directory is separated by `\\`).\nThis prefix format is typically used by mods that contain several addons:\n\n```\nMod_Name\\Addon_Name\\Category\\...\n```\n\nFor example:\n\n```\nMy_Faction_Mod\\Faction_Name\\Vehicles\n```\n\nIt is also possible to use the same Addon Prefix in multiple addons (for example, to split an addon into smaller ones)\nHowever, note that their class names in CfgPatches must be different.\n\nOnce the addon prefix is set, the path to addon files will be as follows:\n\n```\nAddon_Prefix\\Folder\\File.format\n```\n\nFor example, assume a file called **car.p3d** exists in the Addon Folder as follows:\n\n```\nAddon_Folder    // Addon folder\n|__models        // A folder in Addon Folder called \"models\"\n   |__car.p3d    // A p3d (3D model) file\n```\n\nLet's assume we've set the addon prefix to \"My_Awesome_Car_Mod\". In **config.cpp**, the model path should be:\n\n```\nmodel = \"My_Awesome_Car_Mod\\models\\car.p3d\";\n```\n\nIn other words, instead of using `Addon_Folder`, every path should now start from the Addon Prefix.\n\n> [!IMPORTANT]\n> The addon prefix can only contain **English letters**, **numbers**, **underscore (`_`)** and backslash (`\\`). Note that **spaces are not allowed**!\n\n#### Setting the Addon prefix\n\nThere are several ways to set the addon prefix, depending on the packing tool used. The instructions for two commonly used tools, namely Addon Builder, Mikero's Tools, and HEMTT, are explained.\n\n##### Using Addon Builder\n\nTo set the addon prefix using Addon Builder, simply navigate to \"Options\" and modify the \"Addon prefix\" edit box.\n\n##### Using Mikero's pboProject\n\nTo set the addon prefix using Mikero's pboProject, create a text file called `$PBOPREFIX$.txt` in the root of the addon folder, and type the addon prefix in the file.\n\n##### Using HEMTT\n\nTo set the addon prefix using HEMTT, create a text file called `$PBOPREFIX$` in the root of the addon folder, and type the addon prefix in the file.\nFor more information on using HEMTT, see the [\"HEMTT Book\"](https://hemtt.dev/).\n\n### Config.cpp\n\nWhen the game loads an addon, it looks for a file called **config.cpp** to determine how to process the addon contents. Without this file, the addon will be ignored by the game.\nIn other words, **config.cpp** is the hub through which **all of the addon contents** (such as vehicles, weapons, sounds, functions, etc.) will be processed and applied to the game.\n\nThis file should be created in the root of the Addon Folder. It is also possible to place additional **config.cpp** files in the subfolders of the addon, in which case the subfolders will be treated as separate addons by the game.\n\nAt the bare minimum, the **config.cpp** file requires a CfgPatches class.\nThis will allow the game to determine what external addons are required by this addon, what objects/weapons are being added, as well as miscellaneous information about the addon such as the author, version, etc.\n\nAll added/patched classes should be added to this file in order to be recognised and configured by the game.\n\n#### Config Modifications\n\nTo add new content or modify existing ones, you typically need to create a sub-class into designated classes for that type of content.\n\nFor example, to add a new vehicle or modify an existing one, a new sub-class is created under `CfgVehicles`:\n\n```cpp\n// CfgVehicles is a special class that contains all object classes that are meant for AI/player interaction, such as Vehicles, Buildings, etc.\nclass CfgVehicles\n{\n    // Forward-declaration of class Car\n    // This tells the game that this class is an existing class in CfgVehicles and we're just importing it to use it in our own config\n    class Car;\n\n    // Inherit the class Car\n    // Note that if MyNewVehicle already exists, instead of creating a new one, we just end up modifying (i.e. patching) it\n    class MyNewVehicle : Car\n    {\n        // All properties of MyNewVehicle will be identical to Car, except for the model property which we just modified\n        model = \"...\";\n    };\n};\n```\n\nThe above config is just an example for demonstration purposes. For more details on how to create vehicles, weapons, etc. please refer to the existing documentations and the Arma 3 Samples (available on Steam).\n\n> [!NOTE]\n> Visit this page to learn more about config classes.\n\nAll added/modified config classes, such as CfgVehicles (objects, backpacks), CfgWeapons (weapons, weapon attachments, uniforms, vests, etc.), CfgMagazines (magazines, grenades, mines, etc.), CfgAmmo (projectiles, submunition, etc.), CfgFunctions (registered scripts), CfgCloudlets (particles), GUI elements, etc. need to be added to this file.\nIf the `config.cpp` file gets too big (which happens a lot with large mods), it is recommended to split it into separate files (e.g. `CfgFunctions.hpp` for CfgFunctions, etc.), and #include them in the **config.cpp** file:\n\n```cpp\n// All addons must have this class\nclass CfgPatches\n{\n    // ...\n};\n// These files are sitting next to config.cpp in the current folder\n#include \"cfgFunctions.hpp\"\n#include \"cfgVehicles.hpp\"\n#include \"some_other_file.hpp\"\n// This file is in the folder \"ui\"\n#include \"ui\\gui.hpp\"\n// etc.\n```\n\n#### Scripts\n\n> [!NOTE]\n> It is recommended to register your scripts as functions in the CfgFunctions class, especially if they are expected to be executed many times during the mission.\n\nScripts can be executed through appropriate classes in **config.cpp**. There are several ways to execute scripts, depending on when the execution take place.\n\nFor example, scripts that need to be executed upon the start of the mission can be added to the CfgFunctions class with an init flag, such as `preInit = 1`.\n\nScripts that need to be executed when a certain event takes place (e.g. object creation, death, bullet impact, damage, etc.) can use Event Handlers, if applicable. Vehicles, weapons, projectiles, etc. can use configs to add event handlers once the object is created. It is also possible to add event handlers using scripts at a later point in the game.\n\nIn the case of scenarios (i.e. missions), scripts can be executed using Event Scripts (e.g. `init.sqf`), using object init fields in 3DEN, triggers and waypoint statements, or `CfgFunctions` similar to addons (except instead of `config.cpp`, the classes are placed in Description.ext)\n\nSome community modifications, such as **Community Base Addons 3 (CBA)**, add more ways to execute scripts, such as executing a script every time a unit is created (object init event handlers)\n\n### Signing the Addon (optional)\n\nSigning an addon allows it to be used in multiplayer servers that check for addon signatures. A private key is required for signing the addon.\n\n#### Keys and Signatures\n\nThere are two types of keys involved in signing addon: **Private** keys and **Public** keys.\n\n##### Private Key\n\nA private key is a file in `.biprivatekey` format. It is used by the mod publisher to sign their addons.\n\n> [!IMPORTANT]\n> The private keys, as the name suggests, should never be given to the public!\n\n##### Public Key\n\nA public key is a file in `.bikey` format. It is used by the server to check the addon signatures.\nIt is safe to give these files to the public (typically published with the mod itself; see Mod Folder Structure).\n\n##### Signature\n\nA signature is a file placed next to the PBO file, to verify its contents.\nThey are named as `addon_name.pbo.key_name.bisign`\n\n#### Creating the Keys\n\nTo create the private and public keys, use the DSUtils program in Arma 3 Tools.\n\n> [!NOTE]\n> There is no need to create a new key with every version of an addon. That would require all servers using the addon to update the key after every update, which can be inconvenient.\n\n### Building the Addon\n\n#### Addon Builder\n\n**Main interface**\n\nFolder Setup in Addon Builder\n\n- **Addon source directory:** Should be the path to the Addon folder\n- **Destination directory or filename:** The output folder which will contain the PBO file, as well as the signature (if \"Sign output PBO\" is checked)\n- **Sign Output PBO:** See Signing the Addon\n- **Binarize:** Binarised configs are loaded faster by the game. They will also be checked for syntax errors during the packing process.\n\n**Options**\n\n- **List of files to copy directly:** By default, only **.cpp** files are included in the addon. If other files need to be copied to the addon (e.g. scripts, models, etc.), add them to the list, separated by `;` or `,`. It is also possible to use the wildcard character `*` instead of the file names/formats. For example:\n\n```\n*.p3d;*.paa;*.sqf;*.fxy;*.xml;*.bisurf;*.rvmat;*.h\n```\n\nAll files will be copied in their original folder structure with respect to the Addon Folder.\n\n> [!NOTE]\n> When the \"Binarize\" option is checked, all #included **.hpp** files in **config.cpp** will be added to **config.bin** file. Therefore there is no need to add ***.hpp** to the list of files to add (unless they're used elsewhere in the mod, such as scripts)\n\n- **Addon Prefix:** See Addon Prefix\n- **Path to private key file:** Set this path to the private key file (if \"Sign output PBO\" is checked)\n\nOther options can be left at their default values.\n\nFinally, click on \"Pack\" to start the packing process.\n\n#### Mikero's pboProject\n\nSimply set the paths and click on Crunch. If the Addon Prefix is not defined, it will be set the same as the input folder name by default\nNote that pboProject requires all files referenced in the config to be physically present in the P drive, even if they come from other mods. (for example, if you use a vanilla asset in your addon, such as `A3\\Data_F\\Something.format`, you must copy that file to P drive: `P:\\A3\\Data_F\\Something.format`)\n\n#### HEMTT\n\n[HEMTT](https://github.com/BrettMayson/HEMTT) is a build system for addons.\nIt has the great advantage of handling multiple addons at once as well as being able to be used in CLI environments like [GitHub Actions](https://github.com/arma-actions/hemtt).\nThe Arma 3 Tools have to be installed for it to binarise files. After installing hemtt you can get information about the usage with `hemtt help`. For a basic setup follow these steps:\n\nIn the command line enter the following command:\n\n```\nhemtt init\n```\n\nIf you get an error that hemtt was not found make sure that the executable is in the project folder or the hemtt directory is part of your %PATH% variable. Fill out the prompts.\nThen create a folder called \"addons\". Inside of this folder create another folder called \"main\". Then create the following files:\n\n- $PBOPREFIX$\n\n```\n\\z\\prefix\\addons\\main\n```\n\n- config.cpp\n\n```cpp\n#include \"script_component.hpp\"\n\nclass CfgPatches\n{\n    class ADDON\n    {\n        name = CSTRING(component);\n        units[] = {};\n        weapons[] = {};\n        requiredVersion = REQUIRED_VERSION;\n        requiredAddons[] = { \"CBA_main\" };\n        author = \"You\";\n        url = \"https://community.bistudio.com/wiki\";\n        VERSION_CONFIG;\n    };\n};\n```\n\n- script_component.hpp\n\n```cpp\n#define COMPONENT main\n#include \"script_mod.hpp\"\n\n#ifdef DEBUG_ENABLED_MAIN\n    #define DEBUG_MODE_FULL\n#endif\n\n#ifdef DEBUG_SETTINGS_MAIN\n    #define DEBUG_SETTINGS DEBUG_SETTINGS_MAIN\n#endif\n\n#include \"script_macros.hpp\"\n```\n\n- script_mod.hpp\n\nThe MAINPREFIX defaults to \"z\", the PREFIX is the one you entered during setup.\n\n```cpp\n#define MAINPREFIX z\n#define PREFIX prefix\n\n#include \"script_version.hpp\"\n\n#define VERSION MAJOR.MINOR.PATCH\n#define VERSION_AR MAJOR,MINOR,PATCH\n\n#define REQUIRED_VERSION 1.88\n```\n\n- script_macros.hpp\n\nThis will add CBA as a dependency.\n\n```cpp\n#include \"\\x\\cba\\addons\\main\\script_macros_common.hpp\"\n```\n\n- script_version.hpp\n\nKeep track of your mod's version in this file. Follows [semantic versioning](https://semver.org/lang/de/).\n\n```cpp\n#define MAJOR 0\n#define MINOR 0\n#define PATCH 0\n```\n\nNow you should be able to run\n\n```\nhemtt build\n```\n\nThe pbos are placed in the \"addons\" folder.\n\nFor more advanced setups and more examples check [CBA's git repository](https://github.com/CBATeam/CBA_A3) as well as [hemtt's GitHub](https://github.com/BrettMayson/HEMTT) page for documentation.\n\n1. Numbered list item\n\n### Mod Folder Structure\n\nThe mod folder contents should be in a certain structure to be correctly recognised by the game, as well as when uploaded to the Steam Workshop using the Publisher tool.\nThe following tree list shows the general folder structure. Notice that some of these files/folders are optional, such as .bikey and .bisign files.\nIt is possible to ship other contents in the mod folder as well, such as documentation and changelog files.\n\n```\n@My_Mod                                    // Mod folder. The @ sign is not required, but it helps distinguish mods from official content.\n|__Addons                                // Addons folder, containing all addons and their signatures (if signed)\n|  |__addon_name.pbo\n|  |__addon_name.pbo.key_name.bisign\n|  |__other_addon.pbo\n|  |__other_addon.pbo.key_name.bisign\n|\n|__Keys                                    // Keys folder (if the mod is signed)\n|  |__key_name.bikey\n|\n|__mod.cpp                                // (Optional) mod.cpp contains the mod description, icon, hover icon, etc.\n|__mod.paa                                // (Optional) mod icon\n|__my_extension.dll                        // (Optional) extension that was created as part of the mod, if any\n|__my_mod_readme.pdf                    // (optional) Documentation file (not loaded by the game)\n```","sections":[{"heading":null,"level":1,"markdown":"This page explains the steps required to create an addon (PBO file)."},{"heading":"Prerequisites","level":3,"markdown":"- An addon making tool such as:\n- Arma 3 Tools\n- [Mikero's Tools](https://mikero.bytex.digital/)\n- [HEMTT](https://hemtt.dev/) ([GitHub](https://github.com/BrettMayson/HEMTT))\n- A text editor, such as Notepad++ or Visual Studio Code."},{"heading":"Preparing the Addon","level":3,"markdown":"Place all required files (scripts, textures, fonts, models, etc.) in an empty folder, which hereafter will be referred to as the **Addon folder**.\nIt is recommended to organise the files into subfolders to avoid clutter.\n\nIn order to make this addon fully functional, at least two additional steps are required, which are explained in further detail in the subsequent sections:\n\n- A file named config.cpp should be created in the root of the Addon Folder for the game to be able to recognise the addon contents.\n- Paths to all files in the addon, such as script paths, model paths, etc. should be adjusted with respect to the Addon Prefix."},{"heading":"Addon Prefix","level":3,"markdown":"In simple terms, Addon Prefix is a virtual (in-game) path to the root folder of an addon. The game uses the addon prefix to find the files in the addon. This virtual path should preferably be unique to prevent collision with other addon files.\nThe addon prefix is added to the PBO properties by the packing tool.\n\nThe addon prefix is typically a single word:\n\n```\nAddon_Name\n```\n\nIt is also possible to use a directory-like prefix (where each pseudo-directory is separated by `\\`).\nThis prefix format is typically used by mods that contain several addons:\n\n```\nMod_Name\\Addon_Name\\Category\\...\n```\n\nFor example:\n\n```\nMy_Faction_Mod\\Faction_Name\\Vehicles\n```\n\nIt is also possible to use the same Addon Prefix in multiple addons (for example, to split an addon into smaller ones)\nHowever, note that their class names in CfgPatches must be different.\n\nOnce the addon prefix is set, the path to addon files will be as follows:\n\n```\nAddon_Prefix\\Folder\\File.format\n```\n\nFor example, assume a file called **car.p3d** exists in the Addon Folder as follows:\n\n```\nAddon_Folder    // Addon folder\n|__models        // A folder in Addon Folder called \"models\"\n   |__car.p3d    // A p3d (3D model) file\n```\n\nLet's assume we've set the addon prefix to \"My_Awesome_Car_Mod\". In **config.cpp**, the model path should be:\n\n```\nmodel = \"My_Awesome_Car_Mod\\models\\car.p3d\";\n```\n\nIn other words, instead of using `Addon_Folder`, every path should now start from the Addon Prefix.\n\n> [!IMPORTANT]\n> The addon prefix can only contain **English letters**, **numbers**, **underscore (`_`)** and backslash (`\\`). Note that **spaces are not allowed**!"},{"heading":"Setting the Addon prefix","level":4,"markdown":"There are several ways to set the addon prefix, depending on the packing tool used. The instructions for two commonly used tools, namely Addon Builder, Mikero's Tools, and HEMTT, are explained."},{"heading":"Using Addon Builder","level":5,"markdown":"To set the addon prefix using Addon Builder, simply navigate to \"Options\" and modify the \"Addon prefix\" edit box."},{"heading":"Using Mikero's pboProject","level":5,"markdown":"To set the addon prefix using Mikero's pboProject, create a text file called `$PBOPREFIX$.txt` in the root of the addon folder, and type the addon prefix in the file."},{"heading":"Using HEMTT","level":5,"markdown":"To set the addon prefix using HEMTT, create a text file called `$PBOPREFIX$` in the root of the addon folder, and type the addon prefix in the file.\nFor more information on using HEMTT, see the [\"HEMTT Book\"](https://hemtt.dev/)."},{"heading":"Config.cpp","level":3,"markdown":"When the game loads an addon, it looks for a file called **config.cpp** to determine how to process the addon contents. Without this file, the addon will be ignored by the game.\nIn other words, **config.cpp** is the hub through which **all of the addon contents** (such as vehicles, weapons, sounds, functions, etc.) will be processed and applied to the game.\n\nThis file should be created in the root of the Addon Folder. It is also possible to place additional **config.cpp** files in the subfolders of the addon, in which case the subfolders will be treated as separate addons by the game.\n\nAt the bare minimum, the **config.cpp** file requires a CfgPatches class.\nThis will allow the game to determine what external addons are required by this addon, what objects/weapons are being added, as well as miscellaneous information about the addon such as the author, version, etc.\n\nAll added/patched classes should be added to this file in order to be recognised and configured by the game."},{"heading":"Config Modifications","level":4,"markdown":"To add new content or modify existing ones, you typically need to create a sub-class into designated classes for that type of content.\n\nFor example, to add a new vehicle or modify an existing one, a new sub-class is created under `CfgVehicles`:\n\n```cpp\n// CfgVehicles is a special class that contains all object classes that are meant for AI/player interaction, such as Vehicles, Buildings, etc.\nclass CfgVehicles\n{\n    // Forward-declaration of class Car\n    // This tells the game that this class is an existing class in CfgVehicles and we're just importing it to use it in our own config\n    class Car;\n\n    // Inherit the class Car\n    // Note that if MyNewVehicle already exists, instead of creating a new one, we just end up modifying (i.e. patching) it\n    class MyNewVehicle : Car\n    {\n        // All properties of MyNewVehicle will be identical to Car, except for the model property which we just modified\n        model = \"...\";\n    };\n};\n```\n\nThe above config is just an example for demonstration purposes. For more details on how to create vehicles, weapons, etc. please refer to the existing documentations and the Arma 3 Samples (available on Steam).\n\n> [!NOTE]\n> Visit this page to learn more about config classes.\n\nAll added/modified config classes, such as CfgVehicles (objects, backpacks), CfgWeapons (weapons, weapon attachments, uniforms, vests, etc.), CfgMagazines (magazines, grenades, mines, etc.), CfgAmmo (projectiles, submunition, etc.), CfgFunctions (registered scripts), CfgCloudlets (particles), GUI elements, etc. need to be added to this file.\nIf the `config.cpp` file gets too big (which happens a lot with large mods), it is recommended to split it into separate files (e.g. `CfgFunctions.hpp` for CfgFunctions, etc.), and #include them in the **config.cpp** file:\n\n```cpp\n// All addons must have this class\nclass CfgPatches\n{\n    // ...\n};\n// These files are sitting next to config.cpp in the current folder\n#include \"cfgFunctions.hpp\"\n#include \"cfgVehicles.hpp\"\n#include \"some_other_file.hpp\"\n// This file is in the folder \"ui\"\n#include \"ui\\gui.hpp\"\n// etc.\n```"},{"heading":"Scripts","level":4,"markdown":"> [!NOTE]\n> It is recommended to register your scripts as functions in the CfgFunctions class, especially if they are expected to be executed many times during the mission.\n\nScripts can be executed through appropriate classes in **config.cpp**. There are several ways to execute scripts, depending on when the execution take place.\n\nFor example, scripts that need to be executed upon the start of the mission can be added to the CfgFunctions class with an init flag, such as `preInit = 1`.\n\nScripts that need to be executed when a certain event takes place (e.g. object creation, death, bullet impact, damage, etc.) can use Event Handlers, if applicable. Vehicles, weapons, projectiles, etc. can use configs to add event handlers once the object is created. It is also possible to add event handlers using scripts at a later point in the game.\n\nIn the case of scenarios (i.e. missions), scripts can be executed using Event Scripts (e.g. `init.sqf`), using object init fields in 3DEN, triggers and waypoint statements, or `CfgFunctions` similar to addons (except instead of `config.cpp`, the classes are placed in Description.ext)\n\nSome community modifications, such as **Community Base Addons 3 (CBA)**, add more ways to execute scripts, such as executing a script every time a unit is created (object init event handlers)"},{"heading":"Signing the Addon (optional)","level":3,"markdown":"Signing an addon allows it to be used in multiplayer servers that check for addon signatures. A private key is required for signing the addon."},{"heading":"Keys and Signatures","level":4,"markdown":"There are two types of keys involved in signing addon: **Private** keys and **Public** keys."},{"heading":"Private Key","level":5,"markdown":"A private key is a file in `.biprivatekey` format. It is used by the mod publisher to sign their addons.\n\n> [!IMPORTANT]\n> The private keys, as the name suggests, should never be given to the public!"},{"heading":"Public Key","level":5,"markdown":"A public key is a file in `.bikey` format. It is used by the server to check the addon signatures.\nIt is safe to give these files to the public (typically published with the mod itself; see Mod Folder Structure)."},{"heading":"Signature","level":5,"markdown":"A signature is a file placed next to the PBO file, to verify its contents.\nThey are named as `addon_name.pbo.key_name.bisign`"},{"heading":"Creating the Keys","level":4,"markdown":"To create the private and public keys, use the DSUtils program in Arma 3 Tools.\n\n> [!NOTE]\n> There is no need to create a new key with every version of an addon. That would require all servers using the addon to update the key after every update, which can be inconvenient."},{"heading":"Building the Addon","level":3,"markdown":""},{"heading":"Addon Builder","level":4,"markdown":"**Main interface**\n\nFolder Setup in Addon Builder\n\n- **Addon source directory:** Should be the path to the Addon folder\n- **Destination directory or filename:** The output folder which will contain the PBO file, as well as the signature (if \"Sign output PBO\" is checked)\n- **Sign Output PBO:** See Signing the Addon\n- **Binarize:** Binarised configs are loaded faster by the game. They will also be checked for syntax errors during the packing process.\n\n**Options**\n\n- **List of files to copy directly:** By default, only **.cpp** files are included in the addon. If other files need to be copied to the addon (e.g. scripts, models, etc.), add them to the list, separated by `;` or `,`. It is also possible to use the wildcard character `*` instead of the file names/formats. For example:\n\n```\n*.p3d;*.paa;*.sqf;*.fxy;*.xml;*.bisurf;*.rvmat;*.h\n```\n\nAll files will be copied in their original folder structure with respect to the Addon Folder.\n\n> [!NOTE]\n> When the \"Binarize\" option is checked, all #included **.hpp** files in **config.cpp** will be added to **config.bin** file. Therefore there is no need to add ***.hpp** to the list of files to add (unless they're used elsewhere in the mod, such as scripts)\n\n- **Addon Prefix:** See Addon Prefix\n- **Path to private key file:** Set this path to the private key file (if \"Sign output PBO\" is checked)\n\nOther options can be left at their default values.\n\nFinally, click on \"Pack\" to start the packing process."},{"heading":"Mikero's pboProject","level":4,"markdown":"Simply set the paths and click on Crunch. If the Addon Prefix is not defined, it will be set the same as the input folder name by default\nNote that pboProject requires all files referenced in the config to be physically present in the P drive, even if they come from other mods. (for example, if you use a vanilla asset in your addon, such as `A3\\Data_F\\Something.format`, you must copy that file to P drive: `P:\\A3\\Data_F\\Something.format`)"},{"heading":"HEMTT","level":4,"markdown":"[HEMTT](https://github.com/BrettMayson/HEMTT) is a build system for addons.\nIt has the great advantage of handling multiple addons at once as well as being able to be used in CLI environments like [GitHub Actions](https://github.com/arma-actions/hemtt).\nThe Arma 3 Tools have to be installed for it to binarise files. After installing hemtt you can get information about the usage with `hemtt help`. For a basic setup follow these steps:\n\nIn the command line enter the following command:\n\n```\nhemtt init\n```\n\nIf you get an error that hemtt was not found make sure that the executable is in the project folder or the hemtt directory is part of your %PATH% variable. Fill out the prompts.\nThen create a folder called \"addons\". Inside of this folder create another folder called \"main\". Then create the following files:\n\n- $PBOPREFIX$\n\n```\n\\z\\prefix\\addons\\main\n```\n\n- config.cpp\n\n```cpp\n#include \"script_component.hpp\"\n\nclass CfgPatches\n{\n    class ADDON\n    {\n        name = CSTRING(component);\n        units[] = {};\n        weapons[] = {};\n        requiredVersion = REQUIRED_VERSION;\n        requiredAddons[] = { \"CBA_main\" };\n        author = \"You\";\n        url = \"https://community.bistudio.com/wiki\";\n        VERSION_CONFIG;\n    };\n};\n```\n\n- script_component.hpp\n\n```cpp\n#define COMPONENT main\n#include \"script_mod.hpp\"\n\n#ifdef DEBUG_ENABLED_MAIN\n    #define DEBUG_MODE_FULL\n#endif\n\n#ifdef DEBUG_SETTINGS_MAIN\n    #define DEBUG_SETTINGS DEBUG_SETTINGS_MAIN\n#endif\n\n#include \"script_macros.hpp\"\n```\n\n- script_mod.hpp\n\nThe MAINPREFIX defaults to \"z\", the PREFIX is the one you entered during setup.\n\n```cpp\n#define MAINPREFIX z\n#define PREFIX prefix\n\n#include \"script_version.hpp\"\n\n#define VERSION MAJOR.MINOR.PATCH\n#define VERSION_AR MAJOR,MINOR,PATCH\n\n#define REQUIRED_VERSION 1.88\n```\n\n- script_macros.hpp\n\nThis will add CBA as a dependency.\n\n```cpp\n#include \"\\x\\cba\\addons\\main\\script_macros_common.hpp\"\n```\n\n- script_version.hpp\n\nKeep track of your mod's version in this file. Follows [semantic versioning](https://semver.org/lang/de/).\n\n```cpp\n#define MAJOR 0\n#define MINOR 0\n#define PATCH 0\n```\n\nNow you should be able to run\n\n```\nhemtt build\n```\n\nThe pbos are placed in the \"addons\" folder.\n\nFor more advanced setups and more examples check [CBA's git repository](https://github.com/CBATeam/CBA_A3) as well as [hemtt's GitHub](https://github.com/BrettMayson/HEMTT) page for documentation.\n\n1. Numbered list item"},{"heading":"Mod Folder Structure","level":3,"markdown":"The mod folder contents should be in a certain structure to be correctly recognised by the game, as well as when uploaded to the Steam Workshop using the Publisher tool.\nThe following tree list shows the general folder structure. Notice that some of these files/folders are optional, such as .bikey and .bisign files.\nIt is possible to ship other contents in the mod folder as well, such as documentation and changelog files.\n\n```\n@My_Mod                                    // Mod folder. The @ sign is not required, but it helps distinguish mods from official content.\n|__Addons                                // Addons folder, containing all addons and their signatures (if signed)\n|  |__addon_name.pbo\n|  |__addon_name.pbo.key_name.bisign\n|  |__other_addon.pbo\n|  |__other_addon.pbo.key_name.bisign\n|\n|__Keys                                    // Keys folder (if the mod is signed)\n|  |__key_name.bikey\n|\n|__mod.cpp                                // (Optional) mod.cpp contains the mod description, icon, hover icon, etc.\n|__mod.paa                                // (Optional) mod icon\n|__my_extension.dll                        // (Optional) extension that was created as part of the mod, if any\n|__my_mod_readme.pdf                    // (optional) Documentation file (not loaded by the game)\n```"}],"categories":["Arma 3: Tutorials","Stubs"],"groups":["Modding"]}