multiplayer Multiplayer support system

[Ry4nD 84]

Simple support system for Arty, Ammo drop, CAS, Transport, dynamic with mod support, virtual, white-listing. 

Works with team-switch

GitHub Link

 

Place the required modules, 

 

Place one support requester module named SupportRequester

Then place virtual Support modules for each named;

ArtilleryProvider, CasProvider, TransportProvider, AmmoProvider, HelicasProvider using the virtual support module 

Sync each virtual module back the the main SupportRequester module.

You can also sync the main supportrequester back the a HQ module for audio announcments. 

I will include a picture to show modules. 

This is repeatable server side, can use all modules or just 1. 

[Ry4nD 84]

https://ibb.co/SRc1PXd

[Ry4nD 84]

//Support Requester By RyanD 2018
_this select 0 synchronizeObjectsAdd [SupportRequester];
SupportRequester synchronizeObjectsAdd [_this select 0];
BIS_supp_refresh = TRUE;
publicVariable "BIS_supp_refresh";
if (typeOf (_this select 0) isEqualTo "player") then {
[_this select 0, SupportRequester, ArtilleryProvider] call BIS_fnc_addSupportLink;
[_this select 0, SupportRequester, CasProvider] call BIS_fnc_addSupportLink;
[_this select 0, SupportRequester, TransportProvider] call BIS_fnc_addSupportLink;
[_this select 0, SupportRequester, AmmoProvider] call BIS_fnc_addSupportLink;
[_this select 0, SupportRequester, HelicasProvider] call BIS_fnc_addSupportLink;
};

initPlayerLocal.sqf

[Ry4nD 84]

If you want to whitelist just a team leader, you change 

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

 

to 

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

 

Then only the JTAC can use the support call;

 

The system is dynamic with mod support, so if you Have RHSUSAF loaded, not only Vanilla assets are available, also the mod assets are available. 

[GEORGE FLOROS GR 4207]

Nice addition Ry4nD , well done !

[JD Wang 352]

15 hours ago, Ry4nD said:

If you want to whitelist just a team leader, you change 

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

 

to 

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

 

Then only the JTAC can use the support call;

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.

[Ry4nD 84]

14 hours ago, GEORGE FLOROS GR said:

Nice addition Ry4nD , well done !

Thank you mate

[Ry4nD 84]

7 minutes 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.

I am not sure, I believe it must be a playable unit, worth a try though!

[mrcurry 505]

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.

 

[Moon_chilD 200]

@JD Wang without testing this should do what you want:

if (backpack player == "YOURBACKPACKITEM") then {

or

if (backpack player isEqualto "YOURBACKPACKITEM") then {

 

[Larrow 2822]

16 hours ago, mrcurry said:

Maybe it's just me but isn't this line a bit nonsensical? 

Exactly what I thought. Plus this...

_this select 0 synchronizeObjectsAdd [SupportRequester];
SupportRequester synchronizeObjectsAdd [_this select 0];
BIS_supp_refresh = TRUE;
publicVariable "BIS_supp_refresh";

Is already done automatically by this...

[_this select 0, SupportRequester, ArtilleryProvider] call BIS_fnc_addSupportLink;

Which I thought sounded familiar and now realise, after a forum search, is the same answer I gave to the same code here.

 

BIS_fnc_addSupportLink

/*
	Author: Josef Zemanek

	Description:
	Adds support types during a mission.

	Parameter(s):
	_this select 0: OBJECT - Requester unit
	_this select 1: OBJECT - Requester module
	_this select 2: OBJECT - Provider module

	Returns:
	nothing
*/

_reqUnit = _this param [0, objNull, [objNull]];
_requester = _this param [1, objNull, [objNull]];
_provider = _this param [2, objNull, [objNull]];

if (!((_reqUnit in synchronizedObjects _requester) && (_requester in synchronizedObjects _reqUnit))) then {
	_requester synchronizeObjectsAdd [_reqUnit];
	_reqUnit synchronizeObjectsAdd [_requester];
};

if (!((_provider in synchronizedObjects _requester) && (_requester in synchronizedObjects _provider))) then {
	_provider synchronizeObjectsAdd [_requester];
	_requester synchronizeObjectsAdd [_provider];
};

BIS_supp_refresh = TRUE; publicVariable "BIS_supp_refresh";

TRUE;

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

[pierremgi 4889]

As you can see, bis_fnc_removeSupportLink waits for two params: requesterMod and providerMod

but bis_fnc_addSupportLink has 3 entries: caller, requesterMod, providerMod

 

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.

- Script your conditions for adding/removing support(s) in this way:

   * Adding conditions: [_player, RequesterMod, objNull ] call BIS_fnc_addSupportLink; // here there si no added value to re-link requesterMod and providerMod. You can let the providerMod, anyway.

   * 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.

 

As Larrow said, the bis functions will refresh all that system.

 

[Ry4nD 84]

23 hours ago, Larrow said:

Exactly what I thought. Plus this...

_this select 0 synchronizeObjectsAdd [SupportRequester];
SupportRequester synchronizeObjectsAdd [_this select 0];
BIS_supp_refresh = TRUE;
publicVariable "BIS_supp_refresh";

Is already done automatically by this...

[_this select 0, SupportRequester, ArtilleryProvider] call BIS_fnc_addSupportLink;

Which I thought sounded familiar and now realise, after a forum search, is the same answer I gave to the same code here.

 

BIS_fnc_addSupportLink

/*
	Author: Josef Zemanek

	Description:
	Adds support types during a mission.

	Parameter(s):
	_this select 0: OBJECT - Requester unit
	_this select 1: OBJECT - Requester module
	_this select 2: OBJECT - Provider module

	Returns:
	nothing
*/

_reqUnit = _this param [0, objNull, [objNull]];
_requester = _this param [1, objNull, [objNull]];
_provider = _this param [2, objNull, [objNull]];

if (!((_reqUnit in synchronizedObjects _requester) && (_requester in synchronizedObjects _reqUnit))) then {
	_requester synchronizeObjectsAdd [_reqUnit];
	_reqUnit synchronizeObjectsAdd [_requester];
};

if (!((_provider in synchronizedObjects _requester) && (_requester in synchronizedObjects _provider))) then {
	_provider synchronizeObjectsAdd [_requester];
	_requester synchronizeObjectsAdd [_provider];
};

BIS_supp_refresh = TRUE; publicVariable "BIS_supp_refresh";

TRUE;

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?

[Ry4nD 84]

Well blow me sideways;

 

I tried your guys suggestion and removed the following;

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

and 

_this select 0 synchronizeObjectsAdd [SupportRequester]; SupportRequester synchronizeObjectsAdd [_this select 0]; BIS_supp_refresh = TRUE; publicVariable "BIS_supp_refresh";

 

in multiplayer on a dedicated server and it works perfectly, I always thought it may be redundant but wasn't 100% sure, thank you so much. I will adjust the script to reflect the suggestions. 

[pierremgi 4889]

23 minutes ago, Ry4nD said:

Have you tried removing 

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

and 

_this select 0 synchronizeObjectsAdd [SupportRequester]; SupportRequester synchronizeObjectsAdd [_this select 0]; BIS_supp_refresh = TRUE; publicVariable "BIS_supp_refresh";

 

in multiplayer on a dedicated server will the support still work? I don't think so. 

 

Not the problem.

You can add/remove support links with commands like synchronizeObjectsAdd , AG EG btw, or use in the same way BIS_fnc_addsupportLink on server.

When you "draw" a link in editor, between two modules, you don't ask yourself if server will see it (and it does via mission.sqm everywhere).

 

The problem here is:

typeOf (_this select 0) isEqualTo "player"  has no sense. ("player" is a simple string without interest and not a kind of anything).

You can use hasInterface, if you want, for no gain.

 

[Ry4nD 84]

I added this to my mission, and works even better than before, thank you guys. 

//Support Requester By Ry4nD 2018
[_this select 0, SupportRequester, ArtilleryProvider] call BIS_fnc_addSupportLink;
[_this select 0, SupportRequester, CasProvider] call BIS_fnc_addSupportLink;
[_this select 0, SupportRequester, TransportProvider] call BIS_fnc_addSupportLink;
[_this select 0, SupportRequester, AmmoProvider] call BIS_fnc_addSupportLink;
[_this select 0, SupportRequester, HelicasProvider] call BIS_fnc_addSupportLink;
};

 

[Ry4nD 84]

Just now, pierremgi said:

 

Not the problem.

You can add/remove support links with commands like synchronizeObjectsAdd , AG EG btw, or use in the same way BIS_fnc_addsupportLink on server.

When you "draw" a link in editor, between two modules, you don't ask yourself if server will see it (and it does via mission.sqm everywhere).

 

The problem here is:

typeOf (_this select 0) isEqualTo "player"  has no sense. You can use hasInterface, if you want, for no gain.

 

Yes, now I am starting to understand. Still learning ;-)

[Ulfgaar 30]

Been trying to get vanilla support system to work on dedicated server game, and looked up what you made here - which is a great job, thank you!

However, i edited it a bit so that you can assign specific variable names to it, so you dont just assign the support to class names, but specific roles if you want to. 

In the example below think of VN1, VN2, VN3, VN4 as the variable names of specific roles in a mission, such as the HQ, platoon commander etc. etc.
 

if (str(player)in ['VN1','VN2','VN3','VN4']) then {
[_this select 0, SupportRequester, ArtilleryProvider] call BIS_fnc_addSupportLink;
[_this select 0, SupportRequester, TransportProvider] call BIS_fnc_addSupportLink;
[_this select 0, SupportRequester, AmmoProvider] call BIS_fnc_addSupportLink;
};

This is ofc put into the Initplayerlocal.sqf file just as you said.

Seem to be working when im testing it on my dedicated server.

The only thing thats pondering me now, is that when i as an example call in a supplydrop, the chopper that delivers it does not despawn afterwards for some reason. Anyone have any idea on why thats happening?

 

[orb1975 11]

I wrote this.  If you are not a officer... you dont have the access to support.

 

if (typeOf (_this select 0) == "B_officer_F") then {

	_this select 0 synchronizeObjectsAdd [SupportRequester];
	SupportRequester synchronizeObjectsAdd [_this select 0];
	
	BIS_supp_refresh = TRUE; publicVariable "BIS_supp_refresh";
	[_this select 0, NEXO_DE_APOYO, Arty] call BIS_fnc_addSupportLink;
	[_this select 0, NEXO_DE_APOYO, HeliCas] call BIS_fnc_addSupportLink;
	[_this select 0, NEXO_DE_APOYO, PlaneCas] call BIS_fnc_addSupportLink;
	[_this select 0, NEXO_DE_APOYO, HeliTransport] call BIS_fnc_addSupportLink;
	[_this select 0, NEXO_DE_APOYO, AmmunitionSupport] call BIS_fnc_addSupportLink;
};

 

[pierremgi 4889]

On 5/3/2020 at 5:02 AM, Ulfgaar said:

 

if (str(player)in ['VN1','VN2','VN3','VN4']) then {
[_this select 0, SupportRequester, ArtilleryProvider] call BIS_fnc_addSupportLink;
[_this select 0, SupportRequester, TransportProvider] call BIS_fnc_addSupportLink;
[_this select 0, SupportRequester, AmmoProvider] call BIS_fnc_addSupportLink;
};

This is ofc put into the Initplayerlocal.sqf file just as you said.
Seem to be working when im testing it on my dedicated server.

 

 

in initPlayerLocal.sqf, it's OK

if (player in [VN1,VN2,VN3,VN4]) then {
  [player, SupportRequester, ArtilleryProvider] call BIS_fnc_addSupportLink;
  [player, SupportRequester, TransportProvider] call BIS_fnc_addSupportLink;
  [player, SupportRequester, AmmoProvider] call BIS_fnc_addSupportLink;
};

is enough. No need to add extra lines. The refresh is included in the BI function.

 

On 5/3/2020 at 5:02 AM, Ulfgaar said:

The only thing thats pondering me now, is that when i as an example call in a supplydrop, the chopper that delivers it does not despawn afterwards for some reason. Anyone have any idea on why thats happening?

 

 

The supply drop is a scheduled code waiting for phases (helo creation, move waypoint, crate creation and drop, waypoint back, timer..)

This code runs fine if your module (where the helo spawns) is not too close/far from the drop point (make tests). Another issue can be the difficulty to cope with a busy scheduler (too many things to run in the 3ms slot, heavy scripts), so some codes never achieves. No error but no end.

 

[avibird 1 155]

Sorry to bring this old post up but this has been on my to do list for a while. I can't seem to get a work around to allow for two playable units on the same side to use the vanilla support modules.

I attempted all three ways that are stated above non work. has anyone got this to work. I would greatly appreciate it.

[pierremgi 4889]

Not sure to understand the problem. You can link (editor or script) several units on requester module.

Do you get an issue during some phases of the game, like team switching? Do you have a specific opening like player changing side, or script/mod for JIP?

[avibird 1 155]

I am using team switch in my mission I have a 20 playable/switchable units  in a platoon divided up into two different squad of 10. I would like each squad to have one unit to have access to the vanilla modules. But only one unit will have access to the modules. Whichever unit I switch into first gets the access and the other one does not. This is my issues. Can you have two playable switchable units that have access during the mission ?

[pierremgi 4889]

Yes.

You should say 2 played units,btw. You are in MP and you need 2 or more players able to use the support(s) module(s). So, they must be linked to the requester module. playable units are edited, so the requester module, then, there is no reason to script anything else for your aim (except if you miss some extra behavior above).

You can check a simple mission MP hosted or dedicated, with BI modules and some playable units. That works. So, the problem is not on BI side, but on what you're scripting (or linking).

[Larrow 2822]

1 hour ago, avibird 1 said:

Whichever unit I switch into first gets the access and the other one does not.

I think this is just down to when you apply the links.

From memory I'm 80% certain the support system does not support AI. So linking a unit that is not currently controlled by a player will be ignored.

So you need to apply the links when a unit is actually controlled by a player.

Ignore the thread title, we actually also covered resyncing supports for switching and when a specific unit died to another specific unit/type.