ALiVE Mod Structure
addons - All ALiVE module folders exist here and are compiled into individual pbo files.
demo - All demo missions that are unbinarised are placed here for users to access for reference
images - Any images used for logos, icons, source files for UI assets and other logos
optional - Optional ALiVE module folders exist here and are compiled into individual pbo files.
releasenotes - Copies of the release notes for the Bohemia Interactive Forums
utils - a set of script and tools used to validate, build or assist with ALiVE development. The map_p_drive.cmd is just a batch file because tools like Eliteness, need the \x\alive\addons directory at the root of a drive, and P: is the standard BIS drive letter.
alive_object_blacklist.txt - This file keeps a list of object classes that should be ignored when indexing maps.
ALiVEClient.DLL - This extension provides map indexing functionality and more (futures - posting intel pictures to War Room from in-game).
mod.cpp - This is what displays the icons on the opening page. We're using localised strings from stringtable.xml and the logo. The "action" entry is used when you view Expansions under Options.
Ok, Alive\Addons\main - main is where all the common files live. Other directories will reference a lot of files in this directory to prevent duplication of config data and one source of truth. Thats why there is a lot of crap in the directory cause it should never be copied anywhere else. Things like common functions, CBA macros, common configurations for addons, etc.
For
At the top of the hierarchy is config.cpp. This is the file that is read by ARMA when it opens up a PBO as an addon. You'll see all I do here is include a bunch of other files which I'll cover below.
This is the info about the PBO/addon - you can see it has required versions, as well as what other PBOs/addons its dependent on.
requiredAddons[] = {"A3_Modules_F"};
which is the A3 editor modules base. You'll see me reference the A3 Editor Module base class when we created our own, hence why I need it. Its default for us, because all our ALIVE code will be based on Editor Modules.
versionAct = "['MAIN',_this] execVM '\x\alive\addons\main\about.sqf';";
this is a CBA thing that shows the credits when you hit ESC in game.
This provides info about the mod - can't remember where it shows up, but I am including the mod.cpp from the top level directory for all its info - again one source of truth.
Inside this file, you'll see a few stanzas CfgFactionClasses define the drop down categories in the Editor Modules screen. I've setup ALIVE System, ALIVE Support, etc in preparation. CfgVehicles creates a fairly pointless editor module called Requires ALIVE, which just places the requirement for the addon in the mission.sqm, so that if you join without it, it would give an error. In CfgVehicles, you can see I declare Logic, then Module_f which is the BI Module baseclass. ModuleAliveSystemBase is the base class for all modules that will show under the ALIVE Systems category in the editor. This is why ALIVE_require module, uses ModuleAliveSystemBase as its parent to place it in the right category.
scope = 1; //means its hidden scope = 2; //is to publish it isGlobal = 1; // not sure - maybe to create it on all localities?
and the rest is just names and pictures.
This is the same format as we used before, the only difference is the use of PREFIX and COMPONENT macros, which I will describe in a sec. The function name for this function would be ALIVE_fnc_baseClass.
This is part of the CBA addon framework. You'll recall we touched on the PREFIX and ADDON macros before which are also part of this frame work.
For the main ALIVE PBO, the following applies: PREFIX = ALIVE COMPONENT = main ADDON = PREFIX + _ + COMPONENT = ALIVE_main
Other modules would have different COMPONENT values, which you'll see later on. To expand on that, each module will contain a custom version of script_component.hpp (that simply defines COMPONENT for each module), which will refer back to ALIVE\main includes and ALIVE\cba includes.
The final line in script_component.hpp is the include back to CBA script_macros, for all CBA macros. Again, one location, everything refers back to it.
There should only be one copy of this file and it should remain in ALIVE\main. All modules should refer back to it. It defines PREFIX ALIVE and ALIVE versioning. It also has a section for enabling debug of modules.
These two subdirectories hold the common ALIVE functions and unit tests for the main module.
ALIVE Systems Admin Actions is the first module to demonstrate the new structure for modules. This is an editor placed module that has the parameters customised within the module in the editor.
config.cpp refers to custom config files and a reference back to CfgMods.hpp in main module.
- script_component.hpp defines the component name
- CfgPatches.hpp defines the requirements such as PBO dependencies of the module
- CfgVehicles.hpp is the crux of the module definition. In AdminActions, you can see it defines the modules based on ModuleAliveSystemBase (which places it into the ALIVE Systems module category). You can then see each of the parameters defined, with default values, tooltips, etc. These parameters are converted to getVariables on the game logic upon initialisation.
function = "ALIVE_fnc_adminActionsInit";
This is the function that is called when the module is initiated during gameplay. It follows a template which references the module game logic and synchronised units. This in turn, calls the main class function.
- CfgFunctions.hpp simply defines the functions including the module initiation function (ALIVE_fnc_adminActionsInit) and the main class (ALIVE_fnc_adminActions) containing the Model/View/Controller code.