Add Dynamic AI Group Tranferring to Headless Clients

[jonpas]

When merged this module will:

• Add a module and ACE Settings to enable automatic transferring of AI groups to Headless Clients (on the fly)
• Provide fully event-based Headless Client recognition and when transferring should happen (includes global event ACE_HeadlessClientJoined as it can be beneficial for other scripts), with a minimal delay specified through module or ACE Settings to let the game sync correctly during transferring
• Provide logging enabled through the module or ACE Settings (logs when Headless Client joins or leaves and when transferring happens with number of transfers to RPT)
• Round-robin balancing when more than 1 Headless Client is present (most efficient with 3 Headless Clients, with 2 load is not equal)
• Ability to prevent a group from transferring using ace_headless_blacklist boolean variable

Can be tested with:

// HC game logic names must be "hc1", "hc2", "hc3" for this to work
localServer = 0;
localHC1 = 0;
localHC2 = 0;
localHC3 = 0;
{
    if (local _x) then {localServer = localServer + 1};
    if (!local hc1 && {owner ((units _x) select 0) == owner hc1}) then {localHC1 = localHC1 + 1};
    if (!local hc2 && {owner ((units _x) select 0) == owner hc2}) then {localHC2 = localHC2 + 1};
    if (!local hc3 && {owner ((units _x) select 0) == owner hc3}) then {localHC3 = localHC3 + 1};
} forEach allGroups;

diag_log format ["Server: %1, HC1: %2, HC2: %3, HC3: %4", localServer, localHC1, localHC2, localHC3];

Thanks to @commy2 for help with events and telling me to PR this here (original work). German translations included written by @System98 (added to AUTHORS.txt).

[nicolasbadano]

Congratulations @jonpas!

[PabstMirror]

I don't know that much about AI stuff, but I've heard that setGroupOwner can cause problems with the FSM still running on the original owner, or there can be problems not transfering FSM variables to the new owner.

Do we need to worry about the FSM not transfering with the command?
Do we need to reset any behavior when transferring?
Is it safe to transfer an AI when in a firefight or should should we wait until the area is clear?

[commy2]

I think setGroupOwner was specifically designed to be used with headless clients and the FSM, Waypoints (and even synched Triggers according to jonpas) shoud be carried over to the target machine.
I never bothered to test anything of this though.

[jonpas]

Do we need to reset any behavior when transferring?

Reset no, setGroupOwner should carry over everything, except some things noted below.

Is it safe to transfer an AI when in a firefight or should should we wait until the area is clear?

From my testing, there is only a quick animation flinch on setGroupOwner. I wouldn't worry about it, units already transferred will not get transferred again (unless an HC joins/leaves which forces full rebalance), and transferring only happens when something is spawned, and I guess the goal of every mission maker is to spawn stuff away from visible eyes. What I want to say is that an AI would never even get transferred during a firefight, unless something goes really wrong and HC disconnects (but if you are running server on the same machine it's more likely everything will crash). Either way from what I saw it's so fast it doesn't matter.

Do we need to worry about the FSM not transfering with the command?
I think setGroupOwner was specifically designed to be used with headless clients and the FSM

That is correct. Not 100% on the FSM side, but I am fairly sure it all gets transferred.

and even synched Triggers according to jonpas

I haven't tested that yet, if someone has a good idea how to test it that would be great, best I can think is some reoccurring message when the trigger is activated. I did test if synchronizedObjects gets retained just to be sure and it does.

There is also a problem with support modules, but I don't think we should worry about that at all. Not many use it in the first place and you can just blacklist the group that's using it.

Also, it's fairly easy to test stuff if anyone wants to, HCs can join player hosted servers as well, no need for a dedicated. Thought a test with dedicated would probably not be such a bad idea. 😁

[thojkooi]

Awesome stuff. My only concern is if this fits within the scope of the ACE project. I have assigned this PR to myself for this reason.

[thojkooi]

private _transfer = !(_x isEqualTo []);

Gets rid of the if statement on lines 74/76.

[MikeMatrix]

I think this can be classified as infrastructure. I'm sure it should be fine to add and possibly allow for potential future extensions based on it?
Idk it has my 👍

[jonpas]

Apparently isPlayer check always returns false at this stage on dedicated server, making it rebalance on player connect as well, not sure if there is a better way to handle that?

[jonpas]

Did a live test on today's session with logging. Apart from the above comment, there were no issues, worked like expected.

[tbeswick96]

Someone may want to test if this still works with the latest arma version as there have been many reports of Headless clients not working as they did previously.
The issue is something to do with the headless client entity becoming local to the server instead of the headless client.
BIS have said they are looking into virtual entities (as they are apparently broken as a whole) but with no time frame on when the issue will be fixed.

https://forums.bistudio.com/topic/184485-werthles-headless-module/page-3#entry2987021
https://forums.bistudio.com/topic/188200-virtual-entities-dont-seem-to-work-how-to-add-a-zeus-player/#entry2984576

[jonpas]

@tbeswick96 Yes, HC is broken in 1.56, once fixed this will work as it should, it doesn't rely on where the HC entity is local to.

[tbeswick96]

Rog looking forward to this :) Thanks

[jonpas]

Reverted as it is out of scope. Will most likely be a part of a separate project, also available in TAC Mods.

[tbeswick96]

Whaa D: Nuu!!!!