[Multiplayer] Insertion Helicopter will not land

[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 embarks, then moves on.

BRAVO chopper approches its heliport, then do 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

BRAVO chopper lands, waint until BRAVO team embarks, then moves on.

ALPHA chopper approches its heliport, then do a sudden turn and moves on without landing

 

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 the 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!

 

[opusfmspol 273]

Are the helos grouped, but the teams are separate groups (two groups)?

[fernandolvferreira 14]

2 hours ago, opusfmspol said:

Are the helos grouped, but the teams are separate groups (two groups)?

No... The infantry teams are divided in two distinct groups; ALPHA and BRAVO. The two choppers are also divided in two distinct groups; HELI1 and HELI2 (both units created directly from [BLUFOR -> US ARMY -> AIR -> UH-60]. Each helicopter and infantry team has its own waypoints configured in the following fashion.

 

HELI1 has waypoints to pickup ALPHA team

HELI2 has waypoints to pickup BRAVO team

 

Whenever I test the mission in the editor SP preview, both helicopters land, pick up the troops and move on.

But when I host the mission in MP, the team I am in is the only one picked up by the chopper (whether I am ALPHA (HELI1) or BRAVO (HELI2), while the other team gets ignored by their respective helicopters. 

[opusfmspol 273]

I'm thinking the triggers might be the issue.  What kind of triggers?  Radio or presence detection?  If detection, what kind?  If radio, are both on the same channel?  Do they have custom conditions other than "this"?

[fernandolvferreira 14]

1 hour ago, opusfmspol said:

I'm thinking the triggers might be the issue.  What kind of triggers?  Radio or presence detection?  If detection, what kind?  If radio, are both on the same channel?  Do they have custom conditions other than "this"?

BLUFOR PRESENT. No other conditions other than "this"

[opusfmspol 273]

Are the triggers or waypoints using "On Act." code with "UnitReady" command?  or is the "Player" variable involved?

 

The choppers being AI, they belong to the server.  "UnitReady" command only gives an accurate return if run on the machine the unit belongs to.  Run on a machine the unit does not belong to, it will always return "true", even when the unit is not ready.  So if a joined client's waypoints rely on a "unitReady" command run on an AI (belonging to the server) it will always return true.

 

And inevitably, using "Player" command works in SP but causes headaches in MP.

 

--edit:  Maybe try "this && isServer" in the triggers.  Maybe it has to do with the triggers firing on all machines rather than just the server.

 

Edited January 18, 2017 by opusfmspol
clarified "UnitReady" result, and added

[fernandolvferreira 14]

Q: Are the triggers or waypoints using "On Act." code with "UnitReady" command?  or is the "Player" variable involved?

A: There's nothing in the "On Act" Field of the triggers. I just used them to hold the choppers on their first WP so they don't head to the assembly area prematurely. I don't think there's any variable involved since there's no scripting in this transport, only simple waypoints.

 

My logic: I was not sure about the triggers being the problem, since both triggers worked (or so I thought), otherwise the choppers wouldn't come to the heliports at all. Am I thinking logically about it?

 

This is how the trigger is set:

 

 

Would the " this && isServer " work in a Dedicated server?

[opusfmspol 273]

Yes.  "this && isServer" will fire only on the server machine, including a dedicated server, but not on the joined client machines.  Otherwise the trigger is firing on all machines.  "Player" wouldn't work because Player is objNull on a dedicated server.

 

Are you sure the two helos aren't grouped?  It looks like a group line leading down from it.

[fernandolvferreira 14]

1 hour ago, opusfmspol said:

Yes.  "this && isServer" will fire only on the server machine, including a dedicated server, but not on the joined client machines.  Otherwise the trigger is firing on all machines.  "Player" wouldn't work because Player is objNull on a dedicated server.

 

Are you sure the two helos aren't grouped?  It looks like a group line leading down from it.

 

Yep. I'm sure... The helo on the left is grouped with another trigger that plays music... Could that be the issue?

[fernandolvferreira 14]

I'm not really sure if I'm making myself clear, so I'll explain again (sorry, I'm not a native english speaker).

 

When I test SP, everything works flawlessly

When I test MP, things get weird:

If I (host) am in the ALPHA team, my helo (HELI1) will work fine, but BRAVO team gets ignored by theirs (HELI2), but if I am in the BRAVO team, my helo  (HELI2) will work flawlessly, while ALPHA team gets ignored by theirs (HELI1). The thing will hover above their heads for something like 20 seconds, then it'll go away about its own business, it looks like it is waiting for something, then it gives up and move on, or maybe it gets a false confirmation that the team embarked (even though it never landed to allow them to)...

 

 

[opusfmspol 273]

12 minutes ago, fernandolvferreira said:

 

Yep. I'm sure... The helo on the left is grouped with another trigger that plays music... Could that be the issue?

 

Don't know, I've never run music grouped to a unit.  But might try ungrouping to see if has any effect.  The setup does appear correct.

[fernandolvferreira 14]

1 hour ago, opusfmspol said:

 

Don't know, I've never run music grouped to a unit.  But might try ungrouping to see if has any effect.  The setup does appear correct.

I just did... Same result...

[opusfmspol 273]

It seems to be a multiplayer locality issue with the waypoints, but I can't figure it out.

 

I created a mission of my own using yours as a template, and experienced the same thing you did.  It worked in SP, and on hosted server it worked for host, but not for joined client.  Then I used a dedicated server so both leaders were joined clients.  Both helis approached and hovered until their teams reached their waypoint, then both helis moved on to the "Transport Unload" waypoints without ever landing.  BUT, 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.

 

- I placed a Functions module to activate Multiplayer framework, and got the same result.
- I used "setOwner" command on the helis to make them belong to the client machine of the boarding team, and still got the same result.
At this point I too am at a loss to understand it.

[fernandolvferreira 14]

1 hour ago, opusfmspol said:

It seems to be a multiplayer locality issue with the waypoints, but I can't figure it out.

 

I created a mission of my own using yours as a template, and experienced the same thing you did.  It worked in SP, and on hosted server it worked for host, but not for joined client.  Then I used a dedicated server so both leaders were joined clients.  Both helis approached and hovered until their teams reached their waypoint, then both helis moved on to the "Transport Unload" waypoints without ever landing.  BUT, 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.

 

- I placed a Functions module to activate Multiplayer framework, and got the same result.
- I used "setOwner" command on the helis to make them belong to the client machine of the boarding team, and still got the same result.
At this point I too am at a loss to understand it.

 

While I can't say I'm enjoying your frustration, I'm happy to see I'm not being a complete idiot for not understanding what is happening.

[fernandolvferreira 14]

I was thinking... WHAT IF instead of having two UH60s placed in the editor, each Team leader spawn their own UH-60? Would that make the helo local to the team leader?

[opusfmspol 273]

An intriguing thought.  One would tend to say no;  the pilots and their group still being AI, would belong to the server:

https://community.bistudio.com/wiki/6thSense.eu:EG#Locality

 

But the locality bug in the transport.fsm (in Functions) which caused the Transport and Supply Drop supports (in SOM) to fail for joined clients was resolved by having the clients create the vehicle and run the FSM (which runs a few "unitReady" commands on the aircraft).  The issue was that the aircraft were created by the server.  The "unitReady" command was always returning true to a joined client since the aircraft was created by the server.  The issue resolved once the client also created the aircraft.  Yet the aircraft and its group, being AI not under player control, one would say they belong to the server?  Yet it worked....  So could AI aircraft created by a client but not part of the player's group actually belong to the client?

 

It makes me wonder if the event handler for an editor 'GET IN' or 'LOAD' waypoint uses the "unitReady" command.  It would explain the behavior.  Perhaps "unitReady" command has to be run on an object created by the local machine, or the waypoints (a group function) need to be created on the local machine?  The wiki doesn't indicate the command's locality use.

 

Short answer: I don't know.  I'll do some testing with this thought over the weekend and post results back.

[fernandolvferreira 14]

12 hours ago, opusfmspol said:

An intriguing thought.  One would tend to say no;  the pilots and their group still being AI, would belong to the server:

https://community.bistudio.com/wiki/6thSense.eu:EG#Locality

 

But the locality bug in the transport.fsm (in Functions) which caused the Transport and Supply Drop supports (in SOM) to fail for joined clients was resolved by having the clients create the vehicle and run the FSM (which runs a few "unitReady" commands on the aircraft).  The issue was that the aircraft were created by the server.  The "unitReady" command was always returning true to a joined client since the aircraft was created by the server.  The issue resolved once the client also created the aircraft.  Yet the aircraft and its group, being AI not under player control, one would say they belong to the server?  Yet it worked....  So could AI aircraft created by a client but not part of the player's group actually belong to the client?

 

It makes me wonder if the event handler for an editor 'GET IN' or 'LOAD' waypoint uses the "unitReady" command.  It would explain the behavior.  Perhaps "unitReady" command has to be run on an object created by the local machine, or the waypoints (a group function) need to be created on the local machine?  The wiki doesn't indicate the command's locality use.

 

Short answer: I don't know.  I'll do some testing with this thought over the weekend and post results back.

 

 

So... I did some testing with early versions. Found some very intriguing results...

 

This was in the trigger/waypoint's condition for the helo to move on after all units go on board:

{_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 

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, riiiiiight?

 

Actually, no...

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

[opusfmspol 273]

Part of the bahavior can be expected.  Init.sqf gets run on every machine, and the commands "createGroup" and "Join" are global commands.  So not only the server, but everyone joining ended up running the commands.  And the variables aren't made public, so each machine has a different reference to a different group.  Your reference ALPHA is not the same group as the joined client's reference ALPHA.  The units joined the last groups created by the last client to join.

 

Try using a condition in the init.sqf to limit the commands to a specific machine (the server in this example):

if (isServer) then 
{
	ALPHA = createGroup west;
	BRAVO = createGroup west;

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

 

My own testing so far, I feel pretty sure the "unitReady" command is being used with synchronized "GET IN" and "LOAD" waypoints.  In SP, as the heli approached I used "selectLeader" to have a subordinate take command of the group.  I became subordinate to the AI.  When the heli came to a hover the leader gave command for all to mount and the mount icon appeared on the heli.  My suspicion is that the "unitReady" commands is used to check who finished boarding.

 

Still testing some thoughts about this.

[fernandolvferreira 14]

tyhthhtht

 

1 hour ago, opusfmspol said:

Part of the bahavior can be expected.  Init.sqf gets run on every machine, and the commands "createGroup" and "Join" are global commands.  So not only the server, but everyone joining ended up running the commands.  And the variables aren't made public, so each machine has a different reference to a different group.  Your reference ALPHA is not the same group as the joined client's reference ALPHA.  The units joined the last groups created by the last client to join.

 

Try using a condition in the init.sqf to limit the commands to a specific machine (the server in this example):

if (isServer) then 
{
	ALPHA = createGroup west;
	BRAVO = createGroup west;

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

 

My own testing so far, I feel pretty sure the "unitReady" command is being used with synchronized "GET IN" and "LOAD" waypoints.  In SP, as the heli approached I used "selectLeader" to have a subordinate take command of the group.  I became subordinate to the AI.  When the heli came to a hover the leader gave command for all to mount and the mount icon appeared on the heli.  My suspicion is that the "unitReady" commands is used to check who finished boarding.

 

Still testing some thoughts about this.

 

[opusfmspol 273]

This seemed to work on a dedicated server.

 

Notes:

Spoiler

- Running "currentCommand" checks on AI showed that synchronized "LOAD" and "GET IN" waypoints run some commands and condition checks between the transport and units boarding.  When leader is a player, not all commands occur automatically.  The player issues them.

 

- "MOVE" and "GET IN" commands occurred.  "WAIT" indicated there was a condition check involved.  Empty ("") indicated a unit had reached its ready status.  The sequence it provided indicated "unitReady" was part of the condition checking.

 

- Conditions failed for a joined client.

 

- When "unitReady" is a condition, the transport has to be created by the client that will be ordering troops to "GET IN".  Both must be local to the same machine. *

 

- Scripting and synchronizing "LOAD" and "GET IN" waypoints didn't work.  Apparently synchronization for them concludes at mission start.  The waypoints and synchronization must exist in editor.

 

- The solution was to have the client create the transport using a group (unit) from editor, which already had its waypoints laid out.

 

- The editor unit can be placed hidden away anywhere, it's unimportant to the player mission and needs to be deleted after the aircraft is created.  It's waypoints are what's important.

 

 

* Instance of Arma would probably be more accurate, since dedicated server and joined client can be run using the same machine.  In that case, failure occurs because dedicated server and joined client are two instances of Arma running, with the transport belonging to the server instance and the team belonging to the client instance.  Both need to be local to the client instance of Arma running.  In hosted environment failure doesn't occur for host because client and server are the same instance of Arma running.  These are my unconfirmed opinion based on observation.

 

Instructions:

Spoiler

1.  Change each heli into a unit which will be deleted after the actual transport is created.

 

2.  Keep the waypoints, the transport needs them.  These (pathfinder) units lay a path for the transports.

 

3.  Each pathfinder needs a name in editor.  The init script below uses "H1path" and "H2path".

 

3.  Stop the pathfinders from running to their waypoints.  In their editor init field put: this disableAI "MOVE"

 

4.  Place markers at the location where each transport will be created.  The init script below creates transports on the ground, using markers named "marker1" and "marker2".

 

5.  The script needs a condition telling both server and clients when it's time for transports to be created.  Decide what yours will be.  The init script below uses the leader of both Teams (when both are players, the transports get created.  Both team leaders need a name in editor, the script uses "SL_1" and "SL_2").

 

 

in init.sqf :

Spoiler

// Wait for players to lead both groups.
waitUntil {isPlayer SL_1 && isPlayer SL_2};

Sleep 5;

// Only clients run this part.
if (!isDedicated) then 
{
	if (Player == SL_1) then 
	{
		// "H1path" is the unit having synched waypoints for heli group
		_grp_H1 = group H1path;

		// Create the aircraft.
		_heli1 = createVehicle ["MH60S", getMarkerPos "marker1", [], 0, "NONE"];
		_pilot1 = _grp_H1 createUnit ["USMC_Soldier_Pilot", getMarkerPos "marker1", [], 0, "FORM"];

		// Pathfinder goes to a new group.
		[H1path] joinSilent grpNull;

		// Assign the aircraft roles
		_grp_H1 addVehicle _heli1;
		_grp_H1 selectLeader _pilot1;
		_pilot1 assignAsDriver _heli1;
		_pilot1 moveInDriver _heli1;

		// Broadcast to all
		heli1 = _heli1;
		publicVariable "heli1";

		// Assign the Team as cargo for the aircraft.
		{_x assignAsCargo heli1} forEach (Units Group Player);
	};

	// Client for Team 2 creates the second heli as their transport.
	if (player == SL_2) then 
	{
		// Do the same for this Team.
		_grp_H2 = group H2path;

		_heli2 = createVehicle ["MH60S", getMarkerPos "marker2", [], 0, "NONE"];
		_pilot2 = _grp_H2 createUnit ["USMC_Soldier_Pilot", getMarkerPos "marker2", [], 0, "FORM"];

		[H2path] joinSilent grpNull;

		_grp_H2 addVehicle _heli2;
		_grp_H2 selectLeader _pilot2;
		_pilot2 assignAsDriver _heli2;
		_pilot2 moveInDriver _heli2;

		heli2 = _heli2;
		publicVariable "heli2";

		{_x assignAsCargo heli2} forEach (Units Group Player);
	};
};

// Server waits for clients to broadcast the helis.
waitUntil {sleep 2; (!isNil "heli1" && !isNil "heli2")};

if (isServer) then 
{
	deleteVehicle H1path;
	deleteVehicle H2path;
};

// Delete this after testing.  It's a message informing Init is done.
if (!isDedicated) then {Player sidechat "Init complete."};

 

 

 

Edited January 24, 2017 by opusfmspol
Added endnote in "notes"

[fernandolvferreira 14]

So basically, I must create a simplified version of a headless client?

 

Editor placed unit's group has the working waypoints...

Alpha team's leader must spawn the Alpha helo

Alpha team's leader forces the Helo to join the Editor placed unit's group

 

Is that it?

 

[opusfmspol 273]

Mostly yes.  There's no adding a client involved.  All it's doing is having the client (player) create the vehicle so it's local to them rather than the server creating the vehicle and having it local to the server.

 

The helo's created (added) as part of the editor unit's group.  Then the original unit (local to the server) is removed, leaving only the helo (local to the client).  Since waypoints are a group function, the helo retains the waypoints.

 

Its similar, but not exactly, to something BIS did in the campaign missions.  In many places, they placed a unit not involved with the campaign, which had waypoints laid out.  And when a condition was satisfied in the campaign, their waypoints got copied over, leading to new paths in the mission without having to script them.  I tried it, but copying didn't work because synchronization failed.  But what did work was creating the heli as part of the group, then removing the original unit from the group.

 

Edited January 24, 2017 by opusfmspol
clarified part