Jump to content

Recommended Posts

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!

 

Share this post


Link to post
Share on other sites
  On 1/18/2017 at 4:24 AM, 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.

 

LDhZkyD.png

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. 

Share this post


Link to post
Share on other sites

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"?

Share this post


Link to post
Share on other sites
  On 1/18/2017 at 6:24 AM, 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"

Share this post


Link to post
Share on other sites

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 by opusfmspol
clarified "UnitReady" result, and added
  • Like 1

Share this post


Link to post
Share on other sites

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:

7t6ZLEx.jpg

 

4JjLz4u.jpg

 

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

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
  On 1/18/2017 at 7:38 AM, 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?

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites
  On 1/18/2017 at 7:41 AM, 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.

Share this post


Link to post
Share on other sites
  On 1/18/2017 at 7:54 AM, 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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
  On 1/18/2017 at 8:48 PM, 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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
  On 1/21/2017 at 3:13 AM, 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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

tyhthhtht

 

  On 1/21/2017 at 5:06 PM, 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.

 

Share this post


Link to post
Share on other sites

This seemed to work on a dedicated server.

 

Notes:

  Reveal hidden contents

 

Instructions:

  Reveal hidden contents

 

 

in init.sqf :

  Reveal hidden contents

 

 

Edited by opusfmspol
Added endnote in "notes"

Share this post


Link to post
Share on other sites

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?

 

Share this post


Link to post
Share on other sites

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 by opusfmspol
clarified part

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

×