[Feature Request] Radios re-refactor (v3_final_final_3_release_final.rar)

[Bubbus]

Is your feature request related to a problem? Please describe.
I'm always frustrated when [...] tickets like #171 appear.

Describe the solution you'd like
Radio distribution is currently handled synchronously with gearscripting - it happens in gearscript events because the current implementation is "take gearscript array and modify it fancy style + call acre api funcs before it's applied to the player".

This isn't really working - the ACRE API isn't really set up to configure radios on an individual, targeted basis which would be ideal for this approach. This has functional impacts: for example, you can't have a 343 on blufor net and a 343 on sus traitor net with this setup. I also suspect that our integration is vulnerable to unreplicable "net/timing" issues as evidenced by in-event complaints.

Suggested refactor (players):

Decouple radio distribution from gearscripting - make it asynchronous. There will still need to be a tie-in to the gearscript system via the event handler system, but it should look like this instead (roughly...):

Assumptions (check before implementing):

• Adding radios one-at-a-time will not trigger re-initialisation of previously added radios - if false, the approach below is broken.
• The CAFE f_var_assignGear_running mutex var is set during full run of gearscripting (including PostGearscriptUnit event). If false, radio distributions can run over eachother and cause problems.

Approach:

• Upon gearscripting:
  • Empty gearscript of all radios (already does this)
  • Calculate radios that should be given to the player, along with preset + channel info (already does this)
  • Choose which garments to place the radios into, and calculate the load this adds
    • There is existing logic to add a garment to the loadout if none can take a radio - this needs to be preserved.
  • Create and store a data structure with the above two bullet points in it (perhaps in CBA extended loadout metadata).
  • Ensure that alterUnitMaxLoads EH runs after all gearscript synchronous postprocessing, and is capable of handling the extra space that the radios need (added later on, so need empty space available)
    • If alterUnitMaxLoads needs its own system to achieve this then so be it. Otherwise, maybe this can be handled via CBA extended loadout metadata?
  • In PostGearscriptUnit event, begin this loop:
    • Wait until acre_api_fnc_isInitialized is true
    • Pick a radio from the saved data structure
    • Apply preset for radio class
    • Add the base-class radio to the player
    • Return to top

Suggested refactor (vics):

We also need to re-introduce vehicle rack initialisation:

Assumptions (check before implementing):

• Rack initialisation does not currently occur in any form (before player enters vic, upon/after player enters vic)
  • Check via acre_api_fnc_areVehicleRacksInitialized
• It's generally desirable that the racks should be initialised to the faction of the first player that enters the vehicle.

Approach:

• Create an event handler for GetIn which initialises racks to the player's side preset (fn_acre_getPresetForSide)
• Ensure EH runs on vic locality only, uses a non-resetting mutex and removes itself upon first run to avoid subsequent/same-frame runs.

Why is this this best way to solve the problem?
it's what i've got pal

Additional context
🧱🤛🥲