[Solved] Run SQF when role is not taken in server

[NunesSergio 17]

Hello there!

 

I'm struggling to find the solution to my problem. Already googled a lot to no use.

My friends and I have a dedicated server running a mission which has a HALO Jump SQF script. This script is tied to a whiteboard object.

Basically we want the HALO Jump to be available only when there are no pilot roles taken.

 

I can only think it must be something along the lines of filling an array with "typeOf allPlayers" and run "typeOf" through it to know if there's "B_Helipilot_F" in there, but I really can't wrap my mind around the syntaxes.

Can anyone help?

 

Thanks in advance!

[M1ke_SK 230]

waitUntil { allPlayers findIf { typeOf _x in ["B_Helipilot_F"] } == -1 };

 

[pierremgi 4737]

As M1ke_SK says, in a loop (spawned, in initServer.sqf):

You need the simple variable (global) let's say: yourVariable

 

[] spawn {

  while {true} do {

    waitUntil {uiSleep 1;  allPlayers findIf { typeOf _x in ["B_Helipilot_F"] } == -1 };
   < yourVariable = TRUE;    and also placed a condition field of your addAction >;

    waitUntil {uiSleep 1; allPlayers findIf { typeOf _x in ["B_Helipilot_F"] } > -1 };

 <yourvariable = FALSE;   and also placed a condition field of your addAction >;

  };

};

 

Before your addAction code:

yourVariable = FALSE;   // this define your variable and set it to false. Make sure this occurs before the loop above... or set it to true.

then:

whiteBoard addAction ["blabla jump", {code },arguments, priority, showWindow, hideOnUse, shortcut, "your condition && yourVariable ", radius];

 

Here your condition (is the string existing if you added some condition)       && yourVariable  will return false or true along with the result of the loop.

 

Note: pilot role taken doesn't mean pilot onboard an helo. Be sure it's your goal.

 

[Harzach 2505]

It might be more performative to run your check in the HALO script itself, so that interacting with the whiteboard gives one of two outcomes - "HALO unavailable" or the HALO dialogue.

[NunesSergio 17]

Thank you all, Harzach, pierremgi and M1k3_SK! It worked like a charm.

I followed Hazarch's advice and, instead of actively scanning for pilots all the time, I put it in the code param of a holdAddAction and that's just what I needed.

 

Thank you, boys!

[NunesSergio 17]

In case my necessity is anyone else's, I put this in the Init field of the whiteboard:

 

[    
 this,    
 "HALO Jump",    
 "\a3\ui_f\data\gui\cfg\CommunicationMenu\supplydrop_ca.paa",    
 "\a3\ui_f\data\gui\cfg\CommunicationMenu\supplydrop_ca.paa",    
 "player distance HJ < 4",		// 'HJ' being the variable name of the whiteboard
 "true",    
 {},    
 {},    
 { 
  []execVM "myHALOJump.sqf" 
 },    
 {},    
 [],    
 1,    
 6,    
 false,    
 false,    
 true    
] call BIS_fnc_holdActionAdd

Then the first lines inside "myHALOJump.sqf" are using an almost identical code M1ke_SK taught me, and it goes like this:

 

if (allPlayers findIf { typeOf _x in ["B_Helipilot_F"] } > -1) exitWith
	{
		titleText ["<t size='2.0'>HALO Jump is disabled while there is a <t color='#006bb3'>pilot</t> logged in", "PLAIN DOWN", 1, false, true];
		breakOut "main";
	};

If there are any BLUFOR NATO Helicopter Pilots (B_Helipilot_F) roles taken by any player then the script prints the titleText message and stops right there.

[JD Wang 351]

Isn't one of the holdAction parameters a show condition?

is it actually better performance wise to include the check in the HALO script or in the holdAction parameters?

[Harzach 2505]

9 minutes ago, JD Wang said:

Isn't one of the holdAction parameters a show condition?

is it actually better performance wise to include the check in the HALO script or in the holdAction parameters?

 

Good call.
 

Quote

conditionProgress: String - Condition for the action to progress; if false is returned action progress is paused.
Special arguments passed to the code: _target, _caller, _id, _arguments

 

You could put the "HALO not available" message here instead. Not sure if one is more performative over the other, but either one has to be better than conditionShow or addAction's condition.

[ZaellixA 383]

Yep, there is one conditionShow parameter and it is actually used by NunesSergio in his code... It is the player distance HJ < 4  part and this is actually where an MP problem (some may call it bug) arises... Who is player in an MP game???

 

Correct me if I am wrong but player is local to the machine, and this means that this condition most probably will not have any effect. You may be able to see the action if you test it in the editor MP, but the rest of the players (and most probably you too) won't have much luck when the script will be used on a server. If I understood correctly this script is placed in an object's init box, and most probably the object will never leave the locality of the server. This being said, you will most probably be unable to see the action (or in the best case scenario you'll get an error, but I believe you won't).

 

The solution to this is to actually utilise the passed arguments. This would "transform" this part of the script to

_target distance _this < 4

where according to the documentation, _target is the object that the action is attached to and _this is the calling unit (the one that will, or will not see the action).

 

One thing to keep in mind is that this is not tested. From the information on the doc page and my understanding, this should work in all cases, but once again..... it is NOT tested. Please do some testing if you can and hopefully, it will work as intended.

 

Regarding efficiency... Not sure how often this condition is evaluated. If it is evaluated in the same way the condition for the addAction command does, then it may be beneficial to place the test in the called script. This is because of the addAction condition being evaluated every frame when the unit is closer than the specified distance and looks at the object. Since there is no way to specify a distance here and there's nothing on how often the conditionShow is evaluated, you could assume that in the worse case scenario, if you place the test in the script, the test will be evaluated as often as the conditionShow would be or less (the worst case is if the conditionShow is evaluated once a player looks at the object and every time a player looks at the object wants to run the script, in any other case the test in the script will be evaluated less often than the conditionShow).

 

So, from an efficiency point of view, I believe that the check should be left in the script. Alternatively, like Harzach mentions, you could place it in the conditionProgress or codeStart, which to be honest I believe is the best thing to do. This way it will be evaluated only if someone decides to use the action (like if you had to run the HALO script), but you won't have to actually call more scripts (which I believe adds some calling overhead) for nothing.

 

One final note, if you want to use this on a server MP game session it would be wise to remoteExec the titleText command to only the person you tried to use the action. This could look like (inside the conditionProgress parameter)

 

if (allPlayers findIf { typeOf _x in ["B_Helipilot_F"] } > -1) exitWith
	{
		["<t size='2.0'>HALO Jump is disabled while there is a <t color='#006bb3'>pilot</t> logged in", "PLAIN DOWN", 1, false, true] remoteExec["titleText", owner _caller, false];
		breakOut "main";
	};

Finally, I want to remind you that......... these are NOT tested, so please make sure to test them before you use them and if possible, do so on a server.

[NunesSergio 17]

1 hour ago, ZaellixA said:

Yep, there is one conditionShow parameter and it is actually used by NunesSergio in his code... It is the player distance HJ < 4  part and this is actually where an MP problem (some may call it bug) arises... Who is player in an MP game???

 

Correct me if I am wrong but player is local to the machine, and this means that this condition most probably will not have any effect. You may be able to see the action if you test it in the editor MP, but the rest of the players (and most probably you too) won't have much luck when the script will be used on a server. If I understood correctly this script is placed in an object's init box, and most probably the object will never leave the locality of the server. This being said, you will most probably be unable to see the action (or in the best case scenario you'll get an error, but I believe you won't).

 

The solution to this is to actually utilise the passed arguments. This would "transform" this part of the script to

_target distance _this < 4

where according to the documentation, _target is the object that the action is attached to and _this is the calling unit (the one that will, or will not see the action).

 

One thing to keep in mind is that this is not tested. From the information on the doc page and my understanding, this should work in all cases, but once again..... it is NOT tested. Please do some testing if you can and hopefully, it will work as intended.

 

Regarding efficiency... Not sure how often this condition is evaluated. If it is evaluated in the same way the condition for the addAction command does, then it may be beneficial to place the test in the called script. This is because of the addAction condition being evaluated every frame when the unit is closer than the specified distance and looks at the object. Since there is no way to specify a distance here and there's nothing on how often the conditionShow is evaluated, you could assume that in the worse case scenario, if you place the test in the script, the test will be evaluated as often as the conditionShow would be or less (the worst case is if the conditionShow is evaluated once a player looks at the object and every time a player looks at the object wants to run the script, in any other case the test in the script will be evaluated less often than the conditionShow).

 

So, from an efficiency point of view, I believe that the check should be left in the script. Alternatively, like Harzach mentions, you could place it in the conditionProgress or codeStart, which to be honest I believe is the best thing to do. This way it will be evaluated only if someone decides to use the action (like if you had to run the HALO script), but you won't have to actually call more scripts (which I believe adds some calling overhead) for nothing.

 

One final note, if you want to use this on a server MP game session it would be wise to remoteExec the titleText command to only the person you tried to use the action. This could look like (inside the conditionProgress parameter)

 

if (allPlayers findIf { typeOf _x in ["B_Helipilot_F"] } > -1) exitWith
	{
		["<t size='2.0'>HALO Jump is disabled while there is a <t color='#006bb3'>pilot</t> logged in", "PLAIN DOWN", 1, false, true] remoteExec["titleText", owner _caller, false];
		breakOut "main";
	};

Finally, I want to remind you that......... these are NOT tested, so please make sure to test them before you use them and if possible, do so on a server.

Thanks for the thorough explanation and examples. I did see the documentation mentioning about "player" not existing in an dedicated MP scenario but... it works! The code, as I posted above, works on a dedicated MP session for every player. Probably not a best practice and maybe a low-performance solution but got the job done for now.

As I am still learning and me and my friends sessions are not that performance-testing intensive, we'll probably continue using this untill I have time to test and implement your late suggestions.

 

Thank you for the tips!