[Refactor] Event/loadout driven radio refactor

[Bubbus]

I recently helped out MC with ACRE by integrating ACRE support into their framework. Up to them what they do with that from here, but I learned some pretty good stuff from the experience:

• CBA event handlers are easier to use and more flexible than I thought. Event-driven stuff in SQF is really feasible via these.
• ACRE makes it really easy to detect pre-existing radios in a loadout, and it seems to be possible to configure these radios immediately after loadouting.
• Most of the issues with our current ACRE support are self-inflicted. Scheduled code and the post-loadout radio shuffling cause more issues than they solve.

I propose something similar to what I've just done for MC:

• Take advantage of CBA events to trigger radio configuration after loadouting. Remove the gearscript -> radio component dependency.
• Use pre-loadout modifications like what we use for uniforms etc, but for radio replacement/addition. Ship this process out to the radio component by adding a pre-loadout hook.
• Can utilise the new event-based system to reset radio channels upon group swap / SL "send radio channels" action by just sending/hooking the events.

We have outstanding tickets for persisting spatialisation, volume bla bla. These might be easier to do with the refactor done.

Attaching the modified version of MCFW here, can see the integration I performed in the git commit history. MCFW-ACRE.zip

Addendum: is it possible to do vehicle radio assignment? at beginning by assigning vehicle to a group? when a group member boards as driver? is it possible to make vehicle radios broadcast on speaker?

[Bubbus]

Attaching a new version of the MCFW ACRE integration I've been doing. It contains a function, f_fnc_forceRadioChannelsForRoleInGroup.
MCFW-ACRE-2.zip

This is a big change - it allows declarative assignment of radio channels to a specific role in a group. If refined, it could be the basis for a more declaration-oriented radio net construction. Examples:

// natural language:
"all roles in group BRAVO SL speak on BSL SR NET with an ACRE_PRC343"
"role SL in group BRAVO SL speaks on BRAVO NET with an ACRE_PRC152"
"role JTAC in group BRAVO SL speaks on AIR NET with an ACRE_PRC152"

// hypothetical macro construction:
ALL_IN_GROUP("BRAVO SL") USES_RADIO("ACRE_PRC343") ON_NET("BSL SR NET");
ROLE_IN_GROUP("SL","BRAVO SL") USES_RADIO("ACRE_PRC152") ON_NET("BRAVO NET");
ROLE_IN_GROUP("JTAC","BRAVO SL") USES_RADIO("ACRE_PRC152") ON_NET("AIR NET");

// straightforward function calls:
["BRAVO SL", "ACRE_PRC343", "BSL SR NET"] call f_fnc_forceRadioAssignmentForAllGroupMembers;
["BRAVO SL", "SL", "ACRE_PRC152", "BRAVO NET"] call f_fnc_forceRadioAssignmentForSpecificGroupRole;
["BRAVO SL", "JTAC", "ACRE_PRC152", "AIR NET"] call f_fnc_forceRadioAssignmentForSpecificGroupRole;

In the examples above, it'd be implicitly creating SR and LR nets in the course of script execution and creating a relationship map between groups, roles and nets.

If we wanted to get real freaky with it we could do radio net generation. Some more thought required here as this would basically be a constraint solver system. The difference could be something like this:

all roles in BRAVO speak on an SR net ➡ auto-generation of a "BRAVO" SR net, auto-distribution of ACRE_PRC343s to all BRAVO members. SL of BRAVO reports to CO of COMMAND on an LR net ➡ auto-generation of a "COMMAND" LR net, auto-distribution of some kind of LR radio to BRAVO SL and COMMAND CO. PILOT of HELO reports to FAC of COMMAND on an LR net ➡ net name conflict due to existing "COMMAND" LR net, throw exception for immediate MM feedback. FAC of COMMAND has a backpack radio ➡ COMMAND FAC has a backpack radio with an unbound radio channel. PILOT of HELO reports to FAC of COMMAND on an LR net named AIR NET ➡ generation of an "AIR NET" LR net, auto-distribution of some kind of LR radio to HELO PILOT. COMMAND FAC has an unbound backpack radio, which is now bound to AIR NET.

This kind of system should also throw an exception if a configuration would give a unit more than one of each type of radio. It would also represent the point of diminishing returns. It's probably easier to use than the prior proposed system, but the implementation would be professional work.

[dgibso29]

this is awesome but also this might be too good for you to be doing for free???

[Bubbus]

I've basically already done example 1 for MC, so it's only right to port it back into CAFE at some point. Example 2 is probably where I'd expect payment up front?!?!

Doing this thing for MC has shown me that the ACRE configuration in CAFE is way out of date and really confusing for people who aren't us. Time for change. In a future milestone ofc.

[dgibso29]

Tentative 1.6.0 I suppose, ACRE refactor is a good major feature for it.