Jump to content

Recommended Posts

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. 

  • Like 1

Share this post


Link to post
Share on other sites
//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

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
14 hours ago, GEORGE FLOROS GR said:

Nice addition Ry4nD , well done !

Thank you mate

  • Thanks 1

Share this post


Link to post
Share on other sites
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!

  • Thanks 1

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.

 

  • Like 1

Share this post


Link to post
Share on other sites

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

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

or

if (backpack player isEqualto "YOURBACKPACKITEM") then {

 

Share this post


Link to post
Share on other sites
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.

  • Like 3

Share this post


Link to post
Share on other sites

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.

 

  • Like 1

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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. :don8:

Share this post


Link to post
Share on other sites
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. :f:

 

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.

 

  • Like 1

Share this post


Link to post
Share on other sites

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;
};

 

Share this post


Link to post
Share on other sites
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 ;-)

  • Like 1

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×