Helicopter will not land and load troops in multiplayer

[fernandolvferreira 14]

Hey, guys. So I made this mission for my group. we start at an Airfield, the team is divided in two groups. After assembly each group heads for a predetermined heliport, then two UH-60s come and take us away... The set up is pretty simple, inside the heliport there's a trigger which is synched to the UH-60's waypoint (so it doesn't come too early), the next UH-60's waypoint is a LOAD waypoint, syched to a GET IN waypoint of the infantry team, then the chopper move's on to its next waypoints once the team in inside. I tested with bots and it works flawlessly.

 

 

The thing is...

 

I HOSTED the mission in multiplayer mode with a friend of mine and something isn't working... Here's what happens:

Situation 1: I am ALPHA team, my friend is BRAVO team
Development: Both choppers approach the heliports

ALPHA chopper lands, waint until ALPHA team (my team) embarks, then moves on.

BRAVO chopper approches its heliport, then does a sudden turn and moves on without landing

 

Then we traded teams (thinking the problem was BRAVO's chopper waypoints. This is what happened:

 

Situation 2: I am BRAVO team, my friend is ALPHA team
Development: Both chopper approach the heliports

ALPHA chopper (previsouly working) approaches its heliport, then does a sudden turn and moves on without landing

BRAVO chopper (previously broken) lands, waint until BRAVO team (my team) embarks, then moves on.

 

 

The problems appears to have something to do with the HOST (me) and it's not related to any problem in the waypoints, since it worked in both helicopters, except it only works when I (HOST) am in the team it is supposed to pick up. The other chopper completely ignores the other team.

 

I can't seem to think what could be causing it, can you guys help me? Thanks!

[johnnyboy 3741]

Ha!  One of the most commonly asked questions/problems.  I've found the steps in this tutorial linked here to be the most bulletproof.  I've used these techniques to have 3 choppers pick up 2 large groups of ai/players, and choppers always land, and always wait until all live units in group on board before taking off.  Even under fire.   Are your helis in the same group?   I recommend helis not in same group, each with its own waypoints.

 

Its a pain in the ass, but you can get it to work.  I doubt it was host issue.   Good luck.

[fernandolvferreira 14]

18 hours ago, johnnyboy said:

Ha!  One of the most commonly asked questions/problems.  I've found the steps in this tutorial linked here to be the most bulletproof.  I've used these techniques to have 3 choppers pick up 2 large groups of ai/players, and choppers always land, and always wait until all live units in group on board before taking off.  Even under fire.   Are your helis in the same group?   I recommend helis not in same group, each with its own waypoints.

 

Its a pain in the ass, but you can get it to work.  I doubt it was host issue.   Good luck.

 

Some guys in the other forum tried to recreate and test this mission by themselves... They got the same results:

 

SP works flawlessly, while in MP only the HOST's team gets picked up by the helo, regardless of which team the host is (If host is in ALPHA, only ALPHA helo will land. If host is in BRAVO, only BRAVO helo will land). When the mission is executed in a dedicated server, all groups got ignored by the choppers.

 

So far, it seems joined clients are not being "seen" by their choppers, apparently, since the helos are owned by the server, they wont land to allow client owned units to hop in...  We tried placing a Functions module to activate Multiplayer framework, and got the same result. I tried using "setOwner" command on the helos to make them belong to the client machine of the boarding team, and still got the same result.

 

On the weird side:  While the heli was hovering, if the leader disconnected before reaching the team's "Get In" waypoint, the heli then landed and the team boarded.  The team at that point belonged to the server, it no longer belonged to the client machine.

 

Definitely a locality issue... Still not sure how to fix it though...

[johnnyboy 3741]

Sounds like solid trouble-shooting...I have no idea how to solve your locality problem.   But to my knowledge, most pickup problems have been solved with a combination of having an invisible helipad placed at each heli's pickup location, and having this code in the Load waypoint:

_heli = vehicle this; _heli land 'GET IN';

Then you need a trigger synched to the next waypoint that has this condition to wait for all live members of group to board.

{_x in _heli} count (units _group) == {alive _x} count (units _group)

If you aren't using helipads and/or don't have a condition to wait until all aboard, then you might want to try it. 

 

Your use case is common:  Server AI controlled helis picking up player lead teams.  So its odd that this is a locality problem.  But working in SP and not in MP sure points that way...

[fernandolvferreira 14]

1 hour ago, johnnyboy said:

Sounds like solid trouble-shooting...I have no idea how to solve your locality problem.   But to my knowledge, most pickup problems have been solved with a combination of having an invisible helipad placed at each heli's pickup location, and having this code in the Load waypoint:

_heli = vehicle this; _heli land 'GET IN';

Then you need a trigger synched to the next waypoint that has this condition to wait for all live members of group to board.

{_x in _heli} count (units _group) == {alive _x} count (units _group)

If you aren't using helipads and/or don't have a condition to wait until all aboard, then you might want to try it. 

 

Your use case is common:  Server AI controlled helis picking up player lead teams.  So its odd that this is a locality problem.  But working in SP and not in MP sure points that way...

 

 

I'm not sure if the conditions will make any difference since the helos wont even land, but I'll give it a shot.

 

This is how it's currently set up

 

 

Edit: Sorry, I sent you the Arma 2 Version of the mission's screenshot... I got so curious about this problem I had to try it in Arma 2. Oddly enough, it displayed the exact same problem, so I guess it's not a bug, but some very specific detail we're overlooking...

[johnnyboy 3741]

I see choppers in separate groups with their own waypoints, and a helipad for each. So that looks good.  The trigger you displayed is for triggering heli to come land, which is good.

 

Then I see two waypoints on the helipad.  I would add this to the 2nd waypoint on the landing pad.

_heli = vehicle this; _heli land 'GET IN';

If that solves the not landing problem, great.  If landing is solved, you may get the next common problem of them just touching down and leaving immediately.  If so, add the trigger with condition to wait until all on board.

[fernandolvferreira 14]

1 hour ago, johnnyboy said:

I see choppers in separate groups with their own waypoints, and a helipad for each. So that looks good.  The trigger you displayed is for triggering heli to come land, which is good.

 

Then I see two waypoints on the helipad.  I would add this to the 2nd waypoint on the landing pad.

_heli = vehicle this; _heli land 'GET IN';

If that solves the not landing problem, great.  If landing is solved, you may get the next common problem of them just touching down and leaving immediately.  If so, add the trigger with condition to wait until all on board.

 

 I just tried... No luck... =(

 

Now, besides the helos not landing, they wont move on to the next waypoints...

 

It's so weird, because that's such a basic set up and still it wont work... It's so ridiculous that the culinary equivalent would be turning your oven on only to see water squirting out of it...

 

I managed to write scripts that allow you to respawn as a different faction in a NO RESPAWN scenario, but I can't get a damn helo to land. How ridiculous is that? lol

[fernandolvferreira 14]

Well... I guess I'll have to start from scratch... I'll delete all waypoints and control the helicopter exclusively through scripting. Hard code it to land and wait until given units to board it... It'll be a pain in the ass, but since AI helicopter operations are broken, there's not much left for me to do.

 

I'm just amazed such a simple thing isn't working and there are no other topics about it...

[johnnyboy 3741]

Here's my extract script from my Property of Mabunga mission.  Its reused by 5 different helis in the mission (3 opfor, 2 blufor).  The script assumes the following has been placed in the editor per heli:

• A marker on the pickup/exfil position (same marker can be used by more than one heli, if multiple helis picking up groups at same location)
• One helipad per heli
• Extraction switch trigger (trigger that causes helis to come, probably a group present).  I had one for opfor, and one for blufor.
• Switch Trigger per heli that waits until all live units board the particular heli
• Destination trigger placed where heli will fly to after all board (multiple helis can share this; I had one for opfor, and one for blufor)

This worked for me, and no on ever reported the problem you are having.  But no guarantees. My extract script:

// doExtract.sqf
// dummy = [eHeli1, "MRK_EAST_EXFIL", eastHelipad2, trgSwitchEastExtraction, trgEastHeliWaitSwitch_1, trgEastExfil] execVM "Scripts\doExtract.sqf";
if (! isServer) exitwith {}; 
//diag_log ["++++++++++++++++++  in doExtract",_this];

_heli   = _this select 0;     // helicopter
_marker = _this select 1;     // LZ marker
_helipad = _this select 2;    // Helipad object
_extractTrigger = _this select 3;  // Trigger that starts extract defined in editor
_takeOffTrigger = _this select 4;  // Trigger that waits until all aboard defined in editor
_destTrigger = _this select 5;  // Trigger that waits until helis present and ends mission

_group = group _heli;
{_x enableCopilot false} foreach crew _heli;
// **********************************************************************
// synch extract trigger with first wp.  First WP is a do nothing TALK WP placed in editor.
// **********************************************************************
_extractTrigger synchronizeWaypoint [[_group, 1]] ;

// **********************************************************************
// MOVE wp to move near helipad
// **********************************************************************
_wp3 = _group addWaypoint [ getpos _helipad,10];
_wp3 setWaypointType "MOVE"; 
_wp3 setWaypointSpeed "LIMITED";

// **********************************************************************
// Move wp on helipad to force landing. After it lands turning off pilot AI so he won't fly away under fire.
// **********************************************************************
_wp4 = _group addWaypoint [ getpos _helipad, 0];
_wp4 setWaypointType "MOVE"; 
_wp4 setWaypointStatements ["true", format["%1 land 'get in'; driver %1 disableai ""FSM""; driver %1 enablesimulation false;",_heli]];
// **********************************************************************
// hold wp on helipad
// **********************************************************************
_wp5 = _group addWaypoint [ getpos _helipad, 0];
_wp5 setWaypointType "HOLD"; 

// **********************************************************************
// Synch hold wp with switch trigger that waits until all onboard.  Trigger defined in editor.  It reenables pilot also.
// **********************************************************************
_takeOffTrigger synchronizeWaypoint [[_group, 5]] ;
[] spawn {
};

// **********************************************************************
// wp to move end destination
// **********************************************************************
_wp6 = _group addWaypoint [ getpos _destTrigger, 0];
_wp6 setWaypointType "MOVE"; 
_wp6 setWaypointSpeed "NORMAL";

Also the script referenced here looks helpful.

[reaper lok 82]

Here is how I achieve what I think you describe above:

 

1.  Forget the LOAD waypoint action and just use move.  In the MOVE waypoint where you would like the Chopper to land place the below text in the activation box - (assuming your Chopper is called Chopper_1 and you have named the Helipad, land_1).

 

Chopper_1 land "land_1";

 

2.  Have a second MOVE waypoint almost directly on top of the MOVE waypoint with the above text in but this time sync it to a trigger (RADIO ALPHA) or with some code such as:

 

player_1 in Chopper_1 (if your playable character is named Player_1 it will take off when you get in so...be the last one getting in)

 

*The Radio activation will have the Chopper stay on the Helipad until you activate the Radio Menu etc.

 

3.  If the Choppers waypoints are set to CARELESS it will follow these MOVE waypoints regardless of what is going on.  Repeat this for the second Chopper but name it Chopper_2 and the Helipad named land_2 etc

 

 

This is probably very simple and a complete redneck way of doing things, lol.....but, it works for me!!  

[fernandolvferreira 14]

5 hours ago, reaper lok said:

Here is how I achieve what I think you describe above:

 

1.  Forget the LOAD waypoint action and just use move.  In the MOVE waypoint where you would like the Chopper to land place the below text in the activation box - (assuming your Chopper is called Chopper_1 and you have named the Helipad, land_1).

 

Chopper_1 land "land_1";

 

2.  Have a second MOVE waypoint almost directly on top of the MOVE waypoint with the above text in but this time sync it to a trigger (RADIO ALPHA) or with some code such as:

 

player_1 in Chopper_1 (if your playable character is named Player_1 it will take off when you get in so...be the last one getting in)

 

*The Radio activation will have the Chopper stay on the Helipad until you activate the Radio Menu etc.

 

3.  If the Choppers waypoints are set to CARELESS it will follow these MOVE waypoints regardless of what is going on.  Repeat this for the second Chopper but name it Chopper_2 and the Helipad named land_2 etc

 

 

This is probably very simple and a complete redneck way of doing things, lol.....but, it works for me!!  

 

This set up works in single player only.

 

If you try to create this set up with two distinct groups and helicopters in a multiplayer scenario, only the heli supposed to pick up the group in which the host is will land properly, the other chopper supposed to pick up the clients, will just hover for some seconds then it'll move on to next waypoint without ever landing.

 

EDIT: I tried a variant of this set up and both the helicopters landed, but one of two things happened:

 

1) It would touch and go without waiting for the teams to embark

 

2) With a "DoStop" command, it would land and then turn the engines off without ever moving again. In this situation, the only way to get the chopper to move again would be to kill its pilot. The gunner then would get out and move into the pilot's position and follow the rest of the way points.

 

I tried setting a trigger to "MoveOut" the pilot as soon as it lands, then "SetDamage 1" to the Pilot, "MoveOut" to the Gunner and "MoveInDriver" to the gunner, I got it to work a few times... Now talk about a Red Neck way of doing things...

[johnnyboy 3741]

35 minutes ago, fernandolvferreira said:

EDIT: I tried a variant of this set up and both the helicopters landed, but one of two things happened:

 

1) It would touch and go without waiting for the teams to embark

 

2) With a "DoStop" command, it would land and then turn the engines off without ever moving again. In this situation, the only way to get the chopper to move again would be to kill its pilot. The gunner then would get out and move into the pilot's position and follow the rest of the way points.

That is progress.  This is what happened to me also.  Either hover or touch and go.   This waypoint statement below cured it for me.  Land 'getin' forced it to land, then I disabled simulation for the pilot.  While disabled he won't fly off.  Nobody really notices because they are busy boarding.  Once all boarded (your trigger that checks if all alive on board), you re-enable sim for pilot.

_wp4 setWaypointStatements ["true", format["%1 land 'get in'; driver %1 disableai ""FSM""; driver %1 enablesimulation false;",_heli]];

You are close now (as long as you don't give up on Arma now forever due to frustration!).  Its a frustrating time-suck, but you are almost there.

[fernandolvferreira 14]

You know... I figured what is wrong with the  trigger condition:

{_x in _heli} count (units _group) == {alive _x} count (units _group)

Whenever it was in the condition for anything, it instantly was fulfilled on mission start

The following code is in the INIT.SQF:

 

ALPHA =     createGroup west;
BRAVO =     createGroup west;

 

[A1 ,A2, A3, A4, A5, A6] join ALPHA;
[B1 ,B2, B3, B4, B5, B6] join BRAVO;

 

In the editor I placed a trigger PRESENT ANYBODY REPEATEDLY with the following on act:

 

HINT FORMAT ["%1 units in ALPHA and %2 units in BRAVO", count (units ALPHA), count (units BRAVO)];

 

The trigger was supposed to show how many units each team had

 

SINGLEPLAYER test:

 

As soon as I stepped in the trigger, it showed the following message: "6 units in ALPHA and 6 units in BRAVO".

It was working

 

MULTIPLAYER test:

 

1st TRY) I hosted the mission and asked some friends to join. We had 3 players in ALPHA and 2 in BRAVO, AI disabled, so no BOTS in the team

As soon as I stepped into the trigger it showed "0 units in ALPHA and 0 units in BRAVO"

 

2nd TRY) I hosted the mission and my friends joined, we had 2 players in ALPHA and 2 in BRAVO, this time, AI was enabled, so 4 bots in each team

As soon as I stepped into the trigger it showed "4 units in ALPHA and 4 units in BRAVO"

 

CONCLUSIONS: Either the command "count (units _Group)" is only counting AI units or the players are not correctly joining their teams (ALPHA and BRAVO). One solution would be to find a command that only counts units controlled by players and not AI.

 

 

 

FURTHER TESTING:

 

In the editor I created the following trigger:

 

PRESENT ANYBODY REPEATEDLY

CONDITION: ((A1 in BH1) or (!alive A1)) && ((A2 in BH1) or (!alive A2)) && ((A3 in BH1) or (!alive A3))  && ((A4 in BH1) or (!alive A4))  && ((A5 in BH1) or (!alive A5))  && ((A6 in BH1) or (!alive A6));

ON ACT: HINT "ALPHA IS IN THE HELO OR DEAD";

 

*BH1 is the name of the helicopter

 

It was supposed to show a message if all team members were dead or inside the helo

 

MULTIPLAYER test:

 

1st TRY) Only players, no BOTS) I shot all the team dead... No message

2nd TRY) 2 players, 4 bots) I Shot all the bots dead, as soon as the last BOT DIED, it displayed the message, despite two players of the team (A1 and A2) still being alive

3rd TRY) 2 players, 3 bots, one vacant slots with no AI) I shot all the bots dead and NO MESSAGE, then I shot the rest of the TEAM and still no message.

 

 

CONCLUSIONS: A very intriguing result, specially the third TRY, since I shot all the team dead and still no message. My logic points to the supposition that units that ARE NOT spawned are not considered dead, so !alive will not work on them. The other interesting thing about it, is the first and second results. The units controlled by the players seem to be automatically considered dead by the trigger and the only reason the MESSAGE didn't showed up in the first try is because the AI part of the team was not spawned, so A3, A4, A5 and A6 could not be considered !alive (dead) as seen in the 3rd try.

 

 

 

FINAL RESULTS: Either I find a command that only counts units controlled by players, or I'm fucked and this wont work...

[johnnyboy 3741]

One thing that could be screwing with your final test is Activation=Present on the trigger.   "Blufor Present" and "all units dead" can't be true at the same time, or may be unpredictable.  And I don't think you want it to be a Repeated trigger.  I'd change that to Activation=None, then only your explicit condition will activate the trigger.

 

Set Activation=None

Condition= ((A1 in BH1) or (!alive A1)) && ((A2 in BH1) or (!alive A2)) && ((A3 in BH1) or (!alive A3))  && ((A4 in BH1) or (!alive A4))  && ((A5 in BH1) or (!alive A5))  && ((A6 in BH1) or (!alive A6));

 

Also, are any units within the trigger activation area at mission start?  If so, trigger might fire before units JOIN group in init.sqf

 

For detecting when units arrive at LZ, I use global vars. 

In init.sqf: 

ALPHA_AT_LZ = False; // initialize to false

 

In a Blufor Present trigger placed at LZ (once not repeatedly):

ALPHA_AT_LZ = True;

PublicVariable ALPHA_AT_LZ;  // value change broadcasted

 

And in separate Trigger detecting if all on board:

Set Activation=None

Condition= ALPHA_AT_LZ && ((A1 in BH1) or (!alive A1)) && ((A2 in BH1) or (!alive A2)) && ((A3 in BH1) or (!alive A3))  && ((A4 in BH1) or (!alive A4))  && ((A5 in BH1) or (!alive A5))  && ((A6 in BH1) or (!alive A6));

 

Trigger Locality is tricky, and I don't fully understand it.  Editor placed triggers exist on all machines, but detection and scripts run locally on each machine (I think).  Here's a good discussion on trigger locality.  For this reason, I use triggers to set public global variables.  So any AI or player can trigger the trigger, and the publicVariable broadcasts the condition I want to check to all machines (including server).  You can then have other triggers or scripts waiting for a value change in a publicVariable.

 

I don't know if any of the above helps or not.

 

If you have a simple pared down mission that contains just your tests above I could take a look at it (I'd rather not look at a big mission where you have to play to a certain point before testing your particlar problem).

[Jnr4817 215]

On 1/21/2017 at 10:43 AM, johnnyboy said:

Trigger Locality is tricky, and I don't fully understand it.  Editor placed triggers exist on all machines, but detection and scripts run locally on each machine (I think).  Here's a good discussion on trigger locality.  For this reason, I use triggers to set public global variables.  So any AI or player can trigger the trigger, and the publicVariable broadcasts the condition I want to check to all machines (including server).  You can then have other triggers or scripts waiting for a value change in a publicVariable.

How are you achieving this in your scripts?

[opusfmspol 273]

 

Got the waypoints to work on dedicated server (A2/OA).  The LOAD transport needs to be local to the client issuing the GET IN command.  Both need to be local to the same machine.  It's appears to be a factor of the "unitReady" command which is not documented in the wiki.

[QuiGon 10]

On 1/23/2017 at 4:26 AM, opusfmspol said:

 

Got the waypoints to work on dedicated server (A2/OA).  The LOAD transport needs to be local to the client issuing the GET IN command.  Both need to be local to the same machine.  It's appears to be a factor of the "unitReady" command which is not documented in the wiki.

 

Sorry for the necro, but I just ran into the same issue:
I have an AI transprot helo that is local to the server and is supposed to pickup a group that is lead by a client player. The helo won't wait or even land for the group to get in. In SP it works flawless.
Is there no way to make this work in MP?

[opusfmspol 273]

Hi QuiGon,

Not known when I made that post (2017), is that a waypoint's condition only gets checked by the Group Owner machine.  The waypoint's OnAct code will get run on all machines, but only the group owner machine will check whether a waypoint's condition is completed:  (Waypoints wiki page)

 

And I believe that's what leads to the locality issue, in that my testing back then showed the synced LOAD and GETIN waypoints seem to rely on unitReady commands in their handlers to detect when the units to board have all mounted.  But unitReady only gives an accurate return when the unit being checked is local.  A machine that checks unitReady on a remote unit will always receive a return true (unit is ready) even when the unit is not ready.

 

The waypoints work in SP and for MP Host-Only because the transport group and the boarding group are all local to the server, the waypoint unitReady checks give them an accurate return.  But In multiplayer client and dedicated server it fails, because the transport and boarding groups are each local to different machines.  The transport hits the LOAD waypoint, and checks status of the remote group boarding.  Being remote, it receives unitready true from all the units to board  (even though they haven't yet boarded), so it continues on to next waypoint.  That's what I believe occurs.

 

The post from 2017 was an attempt at working around the locality issue, while not understanding that only group owner would check on waypoint condition.  It worked, but is a burdensome work-around.

 

Instead, try using waypoint conditions to check that the units have actually boarded before the waypoints can complete.  Keep in mind that for your mission, server checks waypoint condition for the transport, client checks waypoint condition for the boarding team.

[QuiGon 10]

20 hours ago, opusfmspol said:

Hi QuiGon,

Not known when I made that post (2017), is that a waypoint's condition only gets checked by the Group Owner machine.  The waypoint's OnAct code will get run on all machines, but only the group owner machine will check whether a waypoint's condition is completed:  (Waypoints wiki page)

 

And I believe that's what leads to the locality issue, in that my testing back then showed the synced LOAD and GETIN waypoints seem to rely on unitReady commands in their handlers to detect when the units to board have all mounted.  But unitReady only gives an accurate return when the unit being checked is local.  A machine that checks unitReady on a remote unit will always receive a return true (unit is ready) even when the unit is not ready.

 

The waypoints work in SP and for MP Host-Only because the transport group and the boarding group are all local to the server, the waypoint unitReady checks give them an accurate return.  But In multiplayer client and dedicated server it fails, because the transport and boarding groups are each local to different machines.  The transport hits the LOAD waypoint, and checks status of the remote group boarding.  Being remote, it receives unitready true from all the units to board  (even though they haven't yet boarded), so it continues on to next waypoint.  That's what I believe occurs.

 

The post from 2017 was an attempt at working around the locality issue, while not understanding that only group owner would check on waypoint condition.  It worked, but is a burdensome work-around.

 

Instead, try using waypoint conditions to check that the units have actually boarded before the waypoints can complete.  Keep in mind that for your mission, server checks waypoint condition for the transport, client checks waypoint condition for the boarding team.

Thanks man, that explains it and helps me to work around it! 👍