Last active 4 hours ago

  1. last week
    Fri Oct 6 10:30:06 2017

    Real weather covers:


    Here's the wind calc

    // Calculate Wind
        _windDir = parseNumber ([GVAR(REAL_WEATHER),"wdird", random 360] call ALiVE_fnc_hashGet);
        _windSpeed = parseNumber ([GVAR(REAL_WEATHER),"wspdm", 1 + (random 5)] call ALiVE_fnc_hashGet);
        setWind [-_windSpeed * sin(_windDir), -_windSpeed * cos(_windDir), true];
  2. Fri Oct 6 10:25:23 2017
    Tupolov posted in Using Cup Factions.

    Why have you put "CUP_O_RU-" ?

    It should be "CUP_O_RU"

  3. Wed Oct 4 11:10:46 2017

    By default CIVS are considered friendly to side WEST, killing more than 2 CIVS should impact a player's rating where they are attacked by friendly AI.

    We could add something to civ pop module that shows CIV kills in a UI.

  4. 3 weeks ago
    Wed Sep 27 10:40:23 2017
    Tupolov posted in ALiVE and UCM.

    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,

  5. Tue Sep 26 11:42:38 2017
    Tupolov posted in ALiVE and UCM.

    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?

  6. Tue Sep 26 08:50:51 2017
    Tupolov posted in ALiVE and UCM.

    @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

  7. Mon Sep 25 19:04:50 2017
    Tupolov posted in ALiVE and UCM.

    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}};
  8. Mon Sep 25 08:10:06 2017
    Tupolov posted in Problems with MACC.

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

  9. Mon Sep 25 08:05:07 2017
    Tupolov posted in ALiVE and UCM.

    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!

  10. Sat Sep 23 09:13:03 2017
    Tupolov posted in Problems with MACC.

    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.
View more