MP/PVP - Only one side is allowed to respawn

[allnamesaretakendammit 1]

Hello,

 

I am working on a PVP scenario where only OPFOR is allowed to respawn. The synopsis of the scenario is that a team of 18 OPFOR soldiers with basic gear has to track down and kill two BLUFOR spec ops soldiers with advanced gear. Once the BLUFOR is killed, the mission is over for both sides.

 

I've managed to set up everything correctly apart from the respawns.

 

I've tested it out; BLUFOR has no respawn point, but instead just respawns on OPFOR's respawn point. How should I script it so that BLUFOR is refused to respawn? Keep in mind that both sides consist only of real players.

 

[mrcurry 470]

13 hours ago, allnamesaretakendammit said:

Hello,

 

I am working on a PVP scenario where only OPFOR is allowed to respawn. The synopsis of the scenario is that a team of 18 OPFOR soldiers with basic gear has to track down and kill two BLUFOR spec ops soldiers with advanced gear. Once the BLUFOR is killed, the mission is over for both sides.

 

I've managed to set up everything correctly apart from the respawns.

 

I've tested it out; BLUFOR has no respawn point, but instead just respawns on OPFOR's respawn point. How should I script it so that BLUFOR is refused to respawn? Keep in mind that both sides consist only of real players.

 

Cool idea, do link the mission when it's ready. I'd love to try out something like this.

 

To do what you want add a respawn eventhandler to blufor that hides them, disables their sim and activates a spectate, se below.

//In initPlayerLocal.sqf
if(playerSide isEqualTo BLUFOR) then {
	player addEventHandler [
		"Respawn", 
		{
			player hideObjectGlobal true;
			player enableSimulation false;
			[
				"Initialize", 
				[	
					player, 	
					[blufor], 	//Allowed sides
					false, 		//Allow spectate AI
					false, 		//Allow free cam, probably want this off for a PvP
					true		//Allow 3rd person cam
				]
			] call BIS_fnc_EGSpectator;
		}
	];
};

Edit: If you do this you cannot rely on !alive to check if they are still breathing. To get around that create a custom respawn point for BLUFOR somewhere out of sight, put a BLUFOR present trigger around it and simply check if all BLUFOR are in the trigger. If they are, they are dead and you can safely end the mission.

[allnamesaretakendammit 1]

Thanks for your help mrcurry, it works in terms of respawns!  

 

I can't get the mission to end however... This is my setup in the trigger:

 

Condition: [lonewolf,lonewolf2] in thisList;

 

OnAct: "end2" call BIS_fnc_endMission;

 

I am fairly certain I'm making a mistake in the condition field. Can you help me point it out? 

 

I'm new to MP scripting. I've only done simple SP missions earlier. Would it work with a "all existing BLUFOR units in trigger" kind of script in case the second BLUFOR player doesn't join?  

 

P.S. Once it's done, you can certainly test it! 

[mrcurry 470]

Condition field of trigger:

(blufor countSide allPlayers) isEqualTo (count thisList)

Just make sure no other blufor ever enter the trigger area and that should do it.
Also might wanna make it a server only trigger and execute this instead.
 

["end2"] remoteExec ["BIS_fnc_endMission"];

 

[pierremgi 4739]

you are in MP, so you should try bis_fnc_endMissionServer instead.

As far as you want to end when the 2 bluefor are dead, make it simple. initialize a global variable: counter = 0;

add in EH respawn counter = counter + 1;

There is no reason to get the same player respawning twice, so, when counter == 2, make your mission end (for 2 blufor players).

0r, in case of 1 blue JIP only: counter == blufor countSide allPlayers.

 

Alternate solution: If you don't have any civilian in game, make captive blufor on respawn (just add player setCaptive true; in the respawn code above. The respawned player will definitely not belong to west anymore. Then your trigger just have to check the number of blufor players: blufor countSide allPlayers == 0

 

Quote

I'm new to MP scripting. I've only done simple SP missions earlier. Would it work with a "all existing BLUFOR units in trigger" kind of script in case the second BLUFOR player doesn't join?

NB: triggers considerations:

- blufor units are blufor, player or not, until you kill them or capture them. On respawn process, the side of a player will be west, civilian (when dead), then west again when respawned. So, different phases for blufor countSide allPlayers, but 2 most of the time,

- thislist works in on activation only, and is not refreshed until you deactivate the trigger. So, for example, count thislist, if 2 blufor  are in a big trigger area for blufor presence, will return 2... and that's all until the 2 players are killed at the same time: No more blufor in area will deactivate the trigger, then the first respawned guy will reactivate the trigger and thislist will return 1., etc.

 

[mrcurry 470]

On 4/16/2017 at 6:02 PM, pierremgi said:

- thislist works in on activation only, and is not refreshed until you deactivate the trigger. So, for example, count thislist, if 2 blufor  are in a big trigger area for blufor presence, will return 2... and that's all until the 2 players are killed at the same time: No more blufor in area will deactivate the trigger, then the first respawned guy will reactivate the trigger and thislist will return 1., etc.

 

This is not true: triggers (and thereby thisList) updates every 0.5 seconds (or there abouts, my memory is a bit fuzzy). You can have a trigger with condition "false" (aka it will never run any code on it's own) and still use it as a

detector using list triggerName command. You are right however that a BLUFOR trigger will not detect a dead BLUFOR player as dead units belong to the civilian side.

[pierremgi 4739]

On 21/04/2017 at 11:15 PM, mrcurry said:

This is not true: triggers (and thereby thisList) updates every 0.5 seconds (or there abouts, my memory is a bit fuzzy). You can have a trigger with condition "false" (aka it will never run any code on it's own) and still use it as a

detector using list triggerName command. You are right however that a BLUFOR trigger will not detect a dead BLUFOR player as dead units belong to the civilian side.

Please, you are in a specific case you don't want to trigger anything! So, don't garble the message with your science! For 99.999 % usage of a trigger, you can hint on each frame the thisList result and see what occurs. When fired, thisList is updated within the 0.5 sec slot, the reason why you can have 2 or 3 units in this array, if very close in case of presence check. For sure, a trigger check every 0.5 sec. But, when fired, when thisList takes sense, there is no way to update it without rearming (deactivate) the repeatable trigger.

[mrcurry 470]

On 2017-04-22 at 7:15 PM, pierremgi said:

Please, you are in a specific case you don't want to trigger anything! So, don't garble the message with your science! But, when fired, when thisList takes sense, there is no way to update it without rearming (deactivate) the repeatable trigger.

 

The case was merely an example to illustrate my point. 

 

On 2017-04-16 at 6:02 PM, pierremgi said:

 

- thislist works in on activation only, and is not refreshed until you deactivate the trigger. 

 

I only posted to stop someone not as well-versed in Arma editing as you or me from misinterpreting what you wrote as an absolute truth. It's a simplified model that also only applies in specific use cases.

It's frankly irrelevant what you do with your activation or deactivation statements. Triggers will keep updating thisList even after they have executed activation or deactivation, repeatable or not.

 

Quote

For 99.999 % usage of a trigger, you can hint on each frame the thisList result and see what occurs. When fired, thisList is updated within the 0.5 sec slot, the reason why you can have 2 or 3 units in this array, if very close in case of presence check. For sure, a trigger check every 0.5 sec. But, when fired, when thisList takes sense, there is no way to update it without rearming (deactivate) the repeatable trigger.

thisList is not updated when the activation or deactivation is fired. thisList is updated at all times, the trigger's internal logic executes activation and deactivation based on the condition field' returned value, true or false.

 

thisList is initialized on mission startup (or on trigger creation incase of a spawned trigger) with a short delay (time > 0.5) and is updated by the trigger automatically. If you pass the variable into an activation code such as below thisList will at all times reflect the situation inside the trigger event. Since arrays are passed by reference you can for instance do this to show who is in an area at any given time.

//Trigger condition:
true
  
//Trigger activation:
run = true; 
0 = thisList spawn {
	while { run } do {
  		hintSilent str _this;    
    };
};

 

[pierremgi 4739]

My bad! thisList is updated. It's just the fact that a script in on act. is not a loop which leads to an instant picture of thisList.

So you can use an updated thislist in a loop (on act. only) or through a "on act./on deact." process.

 

Just a point: On my mind, there is no way to access thisList before the condition is met...

It seems evident, but that makes difference with a deactivated (after activated) trigger.The script has it's own life even after the trigger's deactivation.

[Larrow 2801]

31 minutes ago, pierremgi said:

Just a point: On my mind, there is no way to access thisList before the condition is met...

It is available in the condition. The condition is just a code block and can be used to run code, as long as it returns a boolean. The condition is evaluated (code run) roughly every ~0.5 seconds whether the trigger is activated or not.

It is also available at any time from script by using list triggerName.

 

triggerVarName: myTrigger

trigger: Blufor, Present

condition:

hint format["condition\n%1\n\nscript\n%2", thisList, list myTrigger];
this