ALiVE and UCM

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.

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,

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.

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.

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.

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?

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.

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

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 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?

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

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.