1. ‹ Older
  2. 3 months ago
    Edited 3 months ago by SCAR

    I want to thank you for your work and support. I am a big ALiVE fan. It's a huge work that you have done, and thank you for making it available for the community.

    After 3 days of diving into it, I just want to say that from a modder's perspective it is not immediate to integrate with ALiVE. Please take this as constructive criticism.

    The things that I wanted to do since the beginning are:

    1. Have my custom spawned AI be attacked by ALiVE-controlled opposing forces. After 3 days my understanding is that this is not possible. I could profile them (still unclear on how to do so) but that would make them virtualized by ALiVE and it would conflict with my construction system that handles them already. Hence, if there are no players around my custom AI, they will never be attacked by the virtualized units (which is a little ironic given that players around these AI would be there in the first place with the purpose of defending them). I don't know if there's a way to programmatically spawn virtualized units once they get close to my custom AI, so that they get attacked. If there is, please let me know.

    2. Ensure that they are persisted. My understanding is that, being spawned and not placed in the editor, they will be not. Naively I thought that the persistency system of ALiVE would take care of looping allGroups / vehicles and save them and their position, but it looks like this is not how this works. Please correct me if I'm wrong, but it looks that if I want to save my custom spawned AI and objects I'll have to deal with that on my own.

    I'm missing simpler ways to integrate, even though I do understand the complexity of ALiVE and that this is nobody's daily work. :)

    For instance, maybe an oversight on my part but I haven't seen any ALiVE generated events (using CBA) a developer can attach to (for instance to have a callback when a game is saved through ALiVE).

    Some functions are inconsistent (for instance ALiVE_fnc_ProfileNameSpaceLoad returns false for a non-existant variable, while ALiVE_fnc_getData returns nil ), which makes it time consuming to go through exceptions handling. In some others, it is unclear what certain values do, for instance the priority in the "addObjective" function of ALiVE_fnc_OPCOM: is 200 a high or a low value?

    The script snippets are all great starting points, but all seem to have been added in an aftersight (many of which come from forums) rather than being a native part of ALiVE's architecture.

    Again, please take this as constructive criticism from a grateful fan of your work. I really want to make my module 100% ALiVE compliant, my understanding at this point though is that I will probably have to do most things independently and try to patch them together with ALiVE logic, hoping nothing will break in the future.

    Any comments / pointers are obviously welcome, in case you'd want to come back to me.

    All the best,

  3. Tupolov

    Sep 27 Administrator
    Edited 3 months ago by Tupolov

    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,

  4. Friznit

    Sep 27 Administrator

    Just to be clear on profiles. If a player is in range, the profiles will spawn and then act like any normal AI, shooting other AI that are manually placed etc. If a player is not nearby, then the units stay profiled and fighting only takes place in the ALiVE virtual battle space between other profiles.

    Profiling your workers would be fine. You could continue the "build" process with "invisible" AI because the player won't be there to see it. Then they spawn in and carry on their build anims when a player comes into range.

  5. Edited 3 months ago by SCAR

    Thanks to the both of you for your responses, I really appreciate it.

    Profiling your workers would be fine. You could continue the "build" process with "invisible" AI because the player won't be there to see it. Then they spawn in and carry on their build anims when a player comes into range.

    The building process heavily relies on the positioning of workers. They need to be close to the construction area AND alive for it to proceed. I get these info with getPos and alive.

    On top of this, I also have a series of event callbacks when they are killed, attached with addEventHandler. They also have actions added to them, and a series of custom variables (not sure if those would be kept once they are virtualized and then respawned?).

    Unless I'm mistaken, I cannot use any of these when they are profiled, unfortunately...

    This is why I was hoping for a mechanism to make ALiVE "consider" my workers as players, so that if they are in range, they'd spawn.

  6. Edited 3 months ago by SCAR

    I've successfully coded persistence, however it only works on local. Please help me out here to finish this up once and hopefully for all. :)

    I allow both local and cloud persistence. I read the setting from the ALiVE Data Module.

    For local, I use ALiVE_fnc_ProfileNameSpaceLoad and ALiVE_fnc_ProfileNameSpaceSave. This works, both on a local machine and on a dedicated server. For cloud storage I use ALiVE_fnc_getData and ALiVE_fnc_setData. This does not work. No errors, it's just that ALiVE_fnc_getData does not find any data.

    Code to save data can be found here , to load data here .

    Besides the way that the CBA HASH is loaded, all the rest of the code is exactly the same.

    Any ideas?

    Second question: Do ALiVE_fnc_ProfileNameSpaceSave and ALiVE_fnc_setData save the date instantly or only SET the hash on ALiVE, and this data will be persisted ONLY WHEN ALiVE saves it? In other words, do I need to save only once (when?) or keep on saving my CBA HASH at a regular interval?

    Thank you,

  7. Friznit

    Sep 27 Administrator
    Edited 3 months ago by Friznit

    ALiVE saves on exit not during runtime. Use setData then when you server save & exit it will get written to DB. So you only need to set it once.

    From the wiki:

    ["MyCustomVariable", _value] call ALiVE_fnc_setData  //will save to the Cloud on next Server Save & Exit
    _value = ["MyCustomVariable"] call ALiVE_fnc_getData  //will load on next mission start or when command is executed
  8. Yes, but since my data changes all the time and there is no event I can attach to I have to keep on saving it.

    The issue I have though is that getData does not return anything (code linked above). What may be going wrong? As per my previous post everything works with ProfileNameSpaceSave.

  9. Edited 3 months ago by SCAR

    UCM is now integrated with ALiVE, with some caveats. Here are the details of it.

    ALiVE objectives

    The Construction Area is automatically added as a Custom Objective to the hostile OPCOMs. This objective is also moved when the construction moves.

    ALiVE profiles

    The workers are not profiled by ALiVE Virtual_AI_System, and therefore they will not be attacked by profiled enemies when they are virtualized. This substantially means that at least one player needs to be next to the workers, which will cause ALiVE profiled enemies to be spawned on the map and hence attack the workers.

    ALiVE Persistence

    Whan ALiVE saves its data, it will trigger an endMission. UCM listens for that event and automatically uses its Persistent Module to save its data. Therefore, if you want UCM data to be also saved when you save ALiVE, the only thing you have to do is to drop the UCM Persistent Module in your mission.

    Note that UCM data will be saved locally, regardless of the ALiVE Data setting.

    Will be releasing after proper alpha testing. Code here .

  10. Very nice. Congrats. Would you be willing to make a demonstration mission you could share here at some point?

  11. Edited 3 months ago by SCAR

    Thank you @HeroesandvillainsOS.

    There already is a demo mission for UCM, available here .

    If you are referring to a complete UCM + ALiVE demo, that would basically be taking the UCM example and adding ALiVE to your liking :)

  12. Ah ok. Makes sense. Any chance down the road your system can work in virtual space? I usually play alone so obviously can’t just stay there watching the construction. Or well I guess I could but not sure if that’s how I’d want to spend all my time. Lol

  13. Edited 3 months ago by SCAR

    That's really not up to me to say. The only thing I can think of is if the ALiVE virtual system were to start to consider spawned units too. I can't profile those because I don't want any OPCOM to move them. Also, because all of UCM is based on knowing the positions of its units (maybe this is easy to do)?

    I'm available for a discussion though, maybe there are other ways.

  14. Ok I see. This may be a good area for @tupolov to consider if he has some time.

  15. I know this sounds a bit "gamey" but I'm pretty sure you can set triggers to be triggered by virtual units. Couldn't you just say when ever insurgents get within a certain distance of the current workspace all workers are killed?

    I mean they're unarmed and vulnerable, nothing says the insurgents wouldn't just slaughter them?

  16. Edited 3 months ago by SCAR

    This is a good idea, but what if mission makers add defense AI in the area too?

    BTW this can be added with all of the API of the UCM :)

    How would you go in setting triggers?

  17. Friznit

    Sep 30 Administrator

    Could be worth exploring. Perhaps a trigger that if no BLUFOR present then Buildy AI are destroyed. If BLUFOR profiles are still present (and therefore fighting OPFOR profiles), then the Buildy AI get to live another day

  18. @SCAR This is a good idea, but what if mission makers add defense AI in the area too?

    Basically I'd say if the bad guys win then all the workers are killed, if the good guys win then maybe a random number (including zero) of workers are killed in the firefight?

  19. Edited 3 months ago by SCAR

    I can give it a try but I'll need clear indications on which functions to use and how.

    To be specific:

    - how to ensure that virtual entities move to the area. I've already added the objective to the opcom, but i don't see anyone moving. Without this, I can't try anything.

    - how to trigger a custom code when virtual entities are in the area. In the callback I'd need to know how many they are, what kind, etc. (this one is probably the one in the code snippets)

    - how to kill some virtual entities.

    or alternatively to these three, which would be much quicker:

    - how to spawn virtual entities if they are in an area (my original question). It look I could use a custom version of fn_profileDespawner.sqf

    If I can get some support on this I can give it a try. :)

  20. Well the wiki has this to say about detecting profiled units in a trigger

    Will be true if there are virtualized AI groups of side EAST (string) within 50 mtrs of the triggers position EAST

    ((count ([getposATL thisTrigger, 50, ["EAST","entity"]] call ALIVE_fnc_getNearProfiles)) > 0);

    Will be true if there are virtualized vehicles of side EAST (string) within 500 mtrs of trigger position EAST

    ((count ([getposATL thisTrigger, 500, ["EAST","vehicle"]] call ALIVE_fnc_getNearProfiles)) > 0);

    Example: Place this line of code in the condition field of an end mission (f.e. lose) trigger, optionally with timeout. It will fire when there are virtualized groups in the selected area (for a certain amount of time). It doesnt matter if they are spawned or not.

    Now copy and pasting is where my specialty skills end so I'm not sure how you would work this into the situation, but hopefully it's a starting spot.

  21. Thank you @JD_Wang that was the one I was referring to :)


or Sign Up to reply!