Multiplayer: How to create a JIP proof coop mission

[radioshack. 11]

hello,

I was wondering if there is something like the 5 basic rules to create a join in progress proof multiplayer (coop) mission.

Because many times when I create a new mission I encounter problems such as:

JIP player dont have the correct marker on the map because markers have been changend during the game or

JIP player dont see the correct state of tasks

for all changes (such as marker) I use a combination of triggers and global variables that I define in the init.sqf but this dosent seems to be enough.

So how I need to do this? Thank you!

Edited August 25, 2013 by Radioshack.

[John Kozak 14]

One advice is to build your mission logic (triggers) on public variables, not on triggers. Triggers are local (executed for each player separately), hence, for JIP players, they may not fire (because the conditions may have already changed). Public variables, on the other hands, can be synced.

Example:

Suppose I have a task "Get into boat" on the start of the mission. In singleplayer, what I'd do is just create a trigger like "{vehicle _x == myBoat} foreach [player1, player2, player3]" and sync it to the new Task module (Task Status => Completed).

This works fine in SP/non-JIP coop. But when a player joins later - all players might have already quit the boat, so the task will stay uncompleted for him.

Solution:

Create two triggers. One has the same condition as before, but instead of being synced to the task module, it has the following in Activation:

DW_Global_BoatTaskCompleted = true; publicVariable "DW_Global_BoatTaskCompleted";

And the second trigger has the variable DW_Global_BoatTaskCompleted in condition instead of "this" and is synced to the task module.

I don't remember wheether public variables are automatically broadcast to JIP players upon joining, but if they're not, it can be fixed in one simple script:

if (isServer) then {
 _null = spawn {
   while {true} do {
     {publicVariable _x} foreach ["myVar1","myVar2","myVar3",...]; 
     sleep 1;
   }
 }
}

Edited August 24, 2013 by DarkWanderer

[clydefrog 3]

publicVariables are broadcast to JIP players, by the way wouldn't publicvariable-ing all your variables every second be really bad?

[John Kozak 14]

I don't think so - there's an awful lot of traffic anyway... And it can be tweaked anyways.

publicVariables are broadcast to JIP players

Are you saying JIP players will be aware of a variable which was published before they joined? If yes, broadcasting will not even be required

[clydefrog 3]

I don't think so - there's an awful lot of traffic anyway... And it can be tweaked anyways.

Are you sure JIP players will be aware of a variable which was published before they joined?

Yeah JIP players receive pV'd variables, pretty sure.

There is this note from the BI wiki btw:

Multiplayer:

The message is sent consequently and reliably to all clients. Using publicVariable too frequently in a given period of time can cause other parts of the game to experience bandwidth problems.

[galzohar 31]

The variables will be updated, but event handlers will most likely not execute. The "right" way to deal with the tasks (or at least the simple way that works):

On clients (including host, aka if (!isDedicated) then...):

1. Create the tasks (preferably without showing any messages)

2. Wait until the variables for the tasks are defined (waitUntil {!isNil "var1"}; waitUntil {!isNil "var2"};).

3. If the task is not complete, show the task messages if applicable (repeat for multiple tasks if needed and show the correct message based on which tasks are and aren't complete).

4. Wait until 1 of the tasks is complete (wait until 1 of the variables is changed).

5. Update the task, and show message(s) if applicable.

6. Add new tasks if applicable.

7. If mission complete, show mission ending. Else go back to #4.

On the server (if (isServer) then ...):

1. Initialize task states and publicVaraible them.

2. Wait until a task is complete. Update its state and publicVariable it.

3. If all tasks are complete and variables have been updated, wait 5 seconds and end the mission.

Of course you'll have to work a bit harder if the tasks are randomized and/or don't purely depend on the previous task states, but I hope you get the idea.

For task markers it is quite similar. Just use the above logic.

For markers that mark positions of friendly units, you will just need to make sure your script works regardless of how many players are present (make sure to create enough unit markers in advance and hide the ones you don't currently need).

[radioshack. 11]

Thanks for the answers!

At DarkWanderer: I have a question about the saving of the public variables in this part,

if (isServer) then {
 _null = spawn {
   while {true} do {
     {publicVariable _x} foreach ["myVar1","myVar2","myVar3",...]; 
     sleep 1;
   }
 }
}

does this script only save the p.v. defined in this line (here myVar1 -3) or all p.v. broadcastet during the game?

[cuel 25]

PV's are sent as priority messages, there is no reason to send them every second since they are updated for JiPs upon connection.

[mantls 2]

broadcasting them continously will Most likely create an awful amount of traffic which is kinda unneccessary.

[John Kozak 14]

Thanks for the answers!

At DarkWanderer: I have a question about the saving of the public variables in this part,

if (isServer) then {
 _null = spawn {
   while {true} do {
     {publicVariable _x} foreach ["myVar1","myVar2","myVar3",...]; 
     sleep 1;
   }
 }
}

does this script only save the p.v. defined in this line (here myVar1 -3) or all p.v. broadcastet during the game?

Just ditch this part, looks like it's not needed :) Yes, it will broadcast only pre-set variables.

broadcasting them continously will Most likely create an awful amount of traffic which is kinda unneccessary.

Sending a few books each second is not much of traffic compared to the current internal one. But I agree, it's not necessary, since JIPs get the variables anyway

Sent from my HTC One S using Tapatalk 4