Share this post

Link to post

Share on other sites

Maybe it's just me but isn't this line a bit nonsensical? Or are we just talking pseudocode here?

if(typeOf (_this select 0) isEqualTo "player") then {

(_this select 0) returns the player object, typeOf always returns the config name of the unit's class, such as but not limited to "B_recon_JTAC_F". Therefore the typeOf (_this select 0) will never be equal to "player" and the if will never execute.

9 hours ago, JD Wang said:

Would it be possible to adapt the script to whitelist items rather than classname?
Eg only the player with the long range radio pack can call in supports.

This pseudocode should get the ball rolling:

On mission start
Add link between requester and supportprovider(s), can be done using sync in eden.
On mission start and player gear updated
Check : Player has valid radio?
If yes : add requesters using BIS_fnc_addSupportLink. Which provider you pass to it doesnt matter, in theory you only need to establish a link between the player and the requester.
If no : remove the link between player and requester using BIS_fnc_removeSupportLink

The tricky part is checking for gear updates. Put and Take eventhandlers should be fine for a non-arsenal missions but for a mission with Arsenal access you need to hook into the arsenal closing, take a look at Larrow's post here for a reference on how to do that.

I tested that several times and didn't find any difficulty so far, so i suggest you to test at your turn this process, if you have time:

- Place all modules and links as usual, except the link between caller(s) (playable units) and the requester module. That seems to me logical in MP. You want to distribute or not the support(s) for each player.

* Removing conditions: [_player, RequesterMod] call BIS_fnc_removeSupportLink; // That works and it's MP friendly. You don't remove a link between requesterMod and providerMod but between player(s) of your choice and requestedMod.

requesting unit, requestor and provider are all synced together, then the comm menu is refreshed(BIS_supp_refresh) and PVed.

Yes, thank you, the issues we had previously was making it repeatable in multiplayer, having the requester and provider was required, otherwise it would execute once then not function after that. So far this way I can use it any amount of times in a multiplayer campaign. I will test your therory, to see if _this select 0 synchronizeObjectsAdd [SupportRequester]; is redundant, but I don't think this will work without it, or am I missing something?