ALiVE wasn't really designed with 3rd party integration in mind :( So yes integration isn't the easiest. The mod assumes ALiVE as a base to mission making and 3rd parties can build ALiVE modules using our framework and examples. Not ideal, but that's how its grown up. We've been keen to ensure we work well with mods such as ACE, ACRE etc. No doubt we'll take a different approach for A4!

1. Spawned AI will be attacked by ALiVE controlled forces, but only if ALiVE forces are spawned. Virtualize your workers if you want them integrated into the virtual battle system. This means if your integrated with ALIVE your system needs to work regardless of whether AI are spawned or not. From a performance perspective, regardless of using ALiVE, this would help scale your worker system to be map wide etc. anyway. We've provided options on how to virtualize your workers.

2. The persistence system is utilized by each module and you can manage persistence on a per module basis. Persistence is used by most modules - for example profiled AI and vehicles can be saved - but we don't persist spawned AI. Objects and vehicles are persisted if they are moved by players, you can most likely add variables or call functions to store objects/vehicles moved by AI.

3. Events system, agreed would be good for us to plug into say CBA. Something on our to do list. If you use setData, getData, then you don't need to hook into the persistence/save events. Not sure why you need to use profileNameSpaceLoad. Anything using setData will get saved automatically by ALiVE.

4. Objectives - priority is probably more important that size. 30 priority means its a medium priority and 200 means its a medium size. See mil_placement modules CfgVehicles settings for this.

Appreciate the feedback, ALiVE is by no means perfect, we all know that but it meets most of the needs of the current player base.

Keeps us posted on how it goes and we'll try to answer questions as they come up,

Use setData for now :)

Profiling is really about saving performance so Workers are not spawned if players are not around - I suspect this would mess with your module though. You can avoid ALiVE from controlling profiles, but I think in your case its simpler to just not profile them - as long as you don't have 10's of workers running around.

OPCOM sees objectives, profiled OPCOM forces will only see profiled enemy forces. Of course spawned OPCOM forces will see Workers. You could have a situation where profiled OPCOM forces capture a construction area without regard for spawned workers...

Do you really want OPCOM attacking workers? Or do you want work to stop if OPCOM controls the area?

@SCAR yes you could use setData and then you would not need to use CBA_HASH and our "internal" way of saving module data.

Just make sure that whatever you save using setData doesn't exceed 10kb, meets the type requirements and each variable is unique.

Profiles... two ways of doing this:

1. If ALiVE profiles module is available, create units using the profile system. You could use ALIVE_fnc_createProfileEntity or if there exists a worker group configured use the ALiVE_fnc_createProfilesFromGroupConfig function.
2. Alternatively, you can create profiles from units already spawned using the [false,[_group],[]] call ALIVE_fnc_createProfilesFromUnitsRuntime; where params are debug, array of groups, array of vehicles.

Hope that helps

Absolutely understand the desire for modularity and reduce dependencies :)

Initialization Example (mil_logistics)

           // DEBUG -------------------------------------------------------------------------------------
            if(_debug) then {
                ["----------------------------------------------------------------------------------------"] call ALIVE_fnc_dump;
                ["ALIVE module - Startup"] call ALIVE_fnc_dump;
            };
            // DEBUG -------------------------------------------------------------------------------------

            // check modules are available
            if !(["ALiVE_sys_profile","ALiVE_mil_opcom"] call ALiVE_fnc_isModuleAvailable) exitwith {
                ["Military Logistics reports that Virtual AI module or OPCOM module not placed! Exiting..."] call ALiVE_fnc_DumpR;
            };
            waituntil {!(isnil "ALiVE_ProfileHandler") && {[ALiVE_ProfileSystem,"startupComplete",false] call ALIVE_fnc_hashGet}};

CAP/DCA requires planes with AAM.
Recon requires something with a camera/laser.
CAS/Strike/OCA requires guns/rockets/missiles.

This is awesome.

1. a. Creating units as profiles is reasonably straightforward.

if !(ALIVE_loadProfilesPersistent) then {
    _group = ["Infantry",_faction] call ALIVE_fnc_configGetRandomGroup;
    _profiles = [_group, position _hqBuilding, random 360, true, _faction] call ALIVE_fnc_createProfilesFromGroupConfig;

    {
        if (([_x,"type"] call ALiVE_fnc_HashGet) == "entity") then {
        [_x, "setActiveCommand", ["ALIVE_fnc_garrison","spawn",[50,"false",[0,0,0]]]] call ALIVE_fnc_profileEntity;
        };
     } foreach _profiles;
 };

1. b. To add an objective to OPCOM. See here http://alivemod.com/wiki/index.php/Script_Snippets#Add_a_Custom_OPCOM_Objective

2. Persistency - We recommend you store the necessary data in a CBA HASH. We can then store and restore that reasonably easily. There's some requirements:

• Keys are unique to ALiVE, use something like GVAR(my_var)
• If you need to store general module state, then use a CBA HASH for that where each key represents a module variable.
• If you need to store lots of records of data (i.e. data for each construction) then use a separate CBA HASH for that with each key mapping to a construction (or whatever you are storing).
• Don't store data as game objects, needs to be either STRING, BOOL, NUMBER, ARRAY, CBA HASH

We can help with the persistence side of things.

3. Initialization - depends on how much integration/dependency you want with ALiVE. If you are using profiles then I'm assuming the mod requires ALiVE? If so, then the ALiVE module code gives examples on how to handle init. You should wait for any modules that you rely on and we have functions that allow you to check them.

If you want to look at moving the module into ALiVE, it would be very welcome!

Put the module into debug mode, run the mission and take a look at the RPT. Post a link to it here.

Could be a couple of things:

1. RHS aircraft are not being picked up as Fighter/Bomber etc.
2. RHS aircraft faction are not being managed by OPCOM/MACC
3. CAS mission is not getting legitimate targets.

To clarify, we no longer support local instances of CouchDB.

Instead, we offer a local database based on Arma 3 capabilities (i.e. saving to the server profile variables). Simply select Local in the database dropdown in the Data module.

Nothing, the suicide vest is hidden under their clothes (there's no model on the character for the vest). You can only find the vest if you search the character.

If the suicide vest doesn't appear in the inventory, let us know.

Weird we have other missions with whitespace... Thanks for the report anyway, will do some investigation.