1. 11 months ago
    Edited 11 months ago by SCAR

    Hi all,
    First of all - thank you for ALiVE and all the great work.

    I am a big fan of milsim, and obviously ALiVE greatly contributes to the overall feeling of being deployed and not just taking part to a single mission. Having a lot of small tasks such as the ones that ALiVE gives you it's really great.

    However I do miss a purpose for staying in specific maps, especially for persistent servers. Why are we, as military, here in this area of the world? Hence I've just released tonight the [UCM] Utilities Construction Mod . With it, having (for instance) a pipeline to build qualifies the presence and gives specific time limits for a faction to be in an area, thus (at least to me) greatly contributing to milsim.

    Now I would like to integrate it 100% with ALiVE, hence why I'm writing in this forum to gather some help; hopefully some kind soul can point me in the right direction.

    1. Objectives. A construction is always in progress, hence it moves constantly. I'd like to make ALiVE attack the construction area, and for that I think I should do 2 things:

    - The workers are spawned units, so I need to ensure that they are profiled. To this effect, I was thinking of using [] call ALiVE_fnc_createProfilesFromUnitsRuntime; however I keep seeing random errors and am not sure what I'm doing wrong. If this were to be the correct approach, I can report back with more details.

    - Add the construction area as a custom objective, with [_opcom, "addObjective", _objectiveParams] call ALiVE_fnc_OPCOM;. When the construction area moves, I would remove it and add another one in the new position (UCM already has the event to do this, called UCM_ConstructionAreaMoved - more details on github ). However, this does not seem to sort any kind of effects and am unsure on how to proceed.

    2. Persistency. I've spent a great deal of time ensuring that all of the progress variables are stored in a logic module. Once the module is initialized, it takes these variables to compute everything related to the construction. Is this enough to be working with ALiVE persistency?

    3. Initialization. Do I need to have the server wait for ALiVE initialization, or is this done by ALiVE already?

    Thank you for reading all of this.


  2. Wow dude that looks amazing, the idea of having to protect workers/deliver supplies as they build a pipeline in Takistan sounds really cool. I'm definitely checking your mod out.

  3. Edited 11 months ago by SCAR

    Pipelines in Takistan, Rail tracks in Tanoa, Electrical lines in Altis... it's all up to developers' imagination.

    Thank you JD :)

  4. Edited 11 months ago by HeroesandvillainsOS

    @SCAR Ah yeah. I was hoping you'd pop up here. :) Your mod plus ALiVE? Yes please! (*drools*)

    First things first though, ALiVE cannot require ACE. Not if you want formal integration (which I hope you might as this develops). How difficult would it be to remove the ACE dependency?

  5. Edited 11 months ago by SCAR

    @HeroesandvillainsOS I could adapt the mod to use ACE if present, and fallback to vanilla interactions if not. It would require some work as ACE interactions are more flexible than vanilla ones. Plus, there's no such thing as loading a cargo on a vehicle so I'd have to code that too (doesn't sound too big of a task but I'd still have to do it). I'd still need CBA_A3 for events though, which is an ALiVE dependency anyways so I guess that wouldn't be an issue. I am not sure on what you mean with "formal integration"... Probably something I am not aware of :) Would you mind expanding?

  6. Edited 11 months ago by HeroesandvillainsOS

    @SCAR sorry that was probably a poor choice of words. I was referring to this quote:

    Now I would like to integrate it 100% with ALiVE

    I read that as you asking for at some point formal integration of your mod into the ALiVE mod, and not making your mod 100% compatible with ALiVE. :) I think you meant the second one.

    Either way, this is truly exciting and I'm hopeful either option could be a possibility between you and the team. Again, thanks for doing the mod and hopefully some of the ALiVE Devs will be around to help you along your journey.

    This is an wonderful idea of a mod indeed and would make a great fit with ALiVE IMO.

  7. Oh ok. Will see if I get some pointers (hopefully on ACE too) and then will proceed.

  8. Tupolov

    25 Sep 2017 Administrator
    Edited 11 months ago by Tupolov

    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

    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!

  9. Edited 11 months ago by SCAR

    Thank you @Tupolov!

    To clarify, I'd like to keep this module separate because I've had some requests coming in from non-ALiVE mission makers, and from EXILE users. It is good to know though that you'd consider this option ^^_ Thank you.

    My current idea is to create a seamless integration with ALiVE, so that if ALiVE modules are placed in the editor, UCM will know what to do. Does this sound good to you? I am very interested in making this module 100% ALiVE compliant, it has actually been my first objective since day 1 (we are building persistent missions with ALiVE with our clan, 2RGT ).

    Regarding 1.a. maybe I did not explain myself well. I am already dynamically spawning units, see here .

    What I'd like to know is what do I need to do to ensure that the spawned units are taken into account by ALiVE so that they get targeted. Is this what the code here above can be used for? I don't see where I can pass in my spawned _unit, maybe that's what is confusing me.

    1.b: Yes that's the code that I've previously used and didn't seem to sort any effect, but maybe I didn't give it enough time or there were issues with 1.a? see next post.

    2. Yes I basically need to store a general module state. I've attached all of the important variables to the logic module (with setVariable ) because that allows me to have multiple construction areas in a single mission (multiple logic modules). So not only a pipeline, but a railways construction, and such :)

    Hence do you mean that I need to loop all of the variables saved on a module, create a CBA HASH and then save the hash to ALiVE with ALiVE_fnc_setData?

    All the variable names are already unique, though they are namespaced to the module and that allows me to have multiple construction areas on a map. I'll need to see how to make them unique globally in this case.

    3. I just want to ensure that, if ALiVE is used (in this case, if the UCM ALiVE module has been sync'ed), then the server will wait for ALiVE to be properly initialized before proceeding and telling clients to go. I guess this will come out of the box once 2. is done.

    Thank you in advance for your help.

  10. Edited 11 months ago by SCAR

    FYI I've started to work on the ALiVE integration in a dedicated branch. This is the main integration right now, responsible to add a custom objective when the construction area is moved:

    Good news is that I can now see the added objective in the map. I don't see any movement towards it though, is this ok?

  11. Tupolov

    25 Sep 2017 Administrator
    Edited 11 months ago by Tupolov

    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}};
  12. Just had a chance to watch the tutorial video and..... WOW

    I didn't know I needed this so badly, it's amazing!
    Can I ask if there was a specific reason behind the materials being parachuted in rather than the chopper landing and unloading, or even slingloading them in?

    I have a number of other questions but I don't want to clutter up your thread I'd rather you get your answers so we can have this persistent and OPFOR aware of it.

  13. Tupolov

    26 Sep 2017 Administrator
    Edited 11 months ago by Tupolov

    @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

  14. Edited 11 months ago by SCAR

    @JD_Wang thank you for your support ^^_ To answer your questions: I just preferred the parachute to differentiate from workers being delivered. Also, I could not use the slingload because that only works on specific objects, and I wanted the developers to be free to choose any material they'd like. To avoid cluttering an ALiVE forum, what about using the UCM thread on BI instead? I'd be happy to answer your questions.

    @Tupolov thank you for your help. I'd be happy to use your "internal" way, I just don't know what that is. :)
    Right now I'm thinking to just use CBA_fnc_serializeNamespace and the related CBA_fnc_deserializeNamespace and save that with ALiVE_fnc_setData, seems pretty straightforward.

    Only one question on profiles. I only spawn the workers, and those must not be controlled by ALiVE. What I want to ensure is that they are SEEN by ALiVE, so that they are targeted by opposing forces. To my understanding I DO NOT need to profile them, is this correct?

  15. Tupolov

    26 Sep 2017 Administrator
    Edited 11 months ago by Tupolov

    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?

  16. Edited 11 months ago by SCAR

    Ok, setData it is.

    Workers are enemy forces, I want them to be attacked by OPCOM. Work will stop if workers are all dead.

    Right now I'm only adding the construction area as an objective to OPCOM. Is there something else that I need to do? I don't want ALiVE to "virtualize" the workers, but I'd like the workers to be seen also by profiled enemy forces. Can I do that with ALiVE_fnc_createProfilesFromUnitsRuntime?

  17. Friznit

    26 Sep 2017 Administrator

    Only virtual "profiled" AI can attack other virtual AI. Only spawned AI can attack other spawned AI.

    Regular spawned or unprofiled units will be ignored by virtual units until they are spawned in themselves (e.g. when a player is in range), at which point regular BIS AI routines take over.

    If you want the virtual battles to take place between virtual AI and your workers, then the workers will need to be profiled by ALiVE and be a hostile faction.

    All profiled units will be taken over by the AI Commander (OPCOM) on the next Command Cycle. This can be prevented by using [_profileHash,"busy", true] call ALiVE_fnc_hashSet; on a group of units, in which case OPCOM will ignore that group.

    ALiVE Virtual Profiles support Move and Cycle waypoints only. The profiled groups retain their equipment state and an estimate of casualties taken during virtual combat (e.g. a group of 12 that has taken 50% damage will respawn with only 6 unit).

    Profiles do not retain any custom scripts such as animations or gear loadouts. There is a workaround for this on our wiki here:

  18. Edited 11 months ago by SCAR

    Thank you @Friznit.

    Hopefully last questions.

    When is a good time to save the state of my module? Is there a callback for when ALiVE saves the state of the mission, so that I can hook to that? (not talking about player statistics)

    Don't store data as game objects, needs to be either STRING, BOOL, NUMBER, ARRAY, CBA HASH

    How can I persist AI that I SPAWN? Do I need to manually save their loadouts/position/etc and respawn them on mission init? Can't I use ALiVE for this? I'd assume it's a solved problem already.

  19. Friznit

    26 Sep 2017 Administrator

    Definitely one for @Tupolov He loves persistence and all the code to do with it.

  20. Edited 11 months ago by SCAR

    Ok thank you. I'll wait for him then.

  21. Newer ›

or Sign Up to reply!