hidden markers and jip

[sharkattack]

me again 

more problems

i have several hidden markers  throught a mission  which are revealed  as each objective is complete.
however ive noticed when a player jip  the markers which have been revealed to the in game players are not seen by the jip .   is there a way to fix this  ...

many thanx  in adance  and sorry for being a pest   

[Mandoble]

In your init.sqs add a checking section for objetives completed, and unhide these markers accordingly.

[sharkattack]

how do i creating a checking section for objectives 

do you have a short example   


many thanx mate

[Loyalguard]

The easiest I way I have found to do this is something like this:

In the On Act. line of the trigger that completes the objective add a boolean variable to "mirror" the status of the objective:

On Act:

Code: [Select]

"0" objStatus "DONE"; obj0_done = true; publicVariable "obj0_done";
Then in your init.sqf add a check for that variable here:

Code: [Select]

onPlayerConnected "publicVariable ""obj0_done""";
if (obj0_done) then {"0" objStatus "DONE"};
If you have several variables you want to update or other code to run, instead of pV'ing the variable directly in the code string, execute a seperate script that does the updating:

Code: [Select]

onPlayerConnected "[] execVM ""onPlayerConnected.sqf""";
All public variables should be automatically synced when a JIP client connects. EDIT: In dispute

[Mandoble]

All public variables should be automatically synced when a JIP client connects.

Which sadly is not the case, so when a player connects and his init.sqf is executed, it should send a flag to the server so the server publishes again any global variables that might be needed by the new client connecting.

[Loyalguard]

I'm glad you addressed this Mandoble because that was my understanding originally as well.  That's why I have always used a JIP sequence triggered by onPlayerConnected in all my multiplayer scripts.  However, I have also specifically been told that they are synced at JIP, but if changes to the variables have been made and not broadcasted, only the last know broadcasted variable is given.

Regardless, I have edited the code in the post above to make sure the variables are updated.

[Mandoble]

And this leads us to the next question: the server receives onPlayerConnected signal even before the player client has started the execution of the corresponding init.sqf script. In you publish the variables at this time, and the common init.sqf initializes them, there will be an overwrite situation where the client might overwrite what the server broadcasts.

This is a simple example of workaroud for these situations:

Code: [Select]

// init.sqf

// Initialization of any local and global variables here


player_connecting = objNull;
if (isServer) then
{
   []spawn
   {
      while {true} do
      {
         waitUntil {!isNull player_connecting};
         player_connecting = objNull;

         // Publication of any global variables needed by the new client.
      };
   };
}
else
{
   waitUntil {alive player};
   player_connecting = player;
   publicVariable "player_connecting";
};


[Sick]

Which sadly is not the case, so when a player connects and his init.sqf is executed, it should send a flag to the server so the server publishes again any global variables that might be needed by the new client connecting.

Which actually IS the case (at least to my findings). Every variable that has been publicVariabled, will be synced to JIP players. But only the value of the variable as it was at the moment it was publicVariabled. So basicly if you always use publicVariable after you update the value, the right value will always end up at JIP players, even without onPlayerConnected. This has been tested in Multiplayer ServerClient and Dedicated Server, v1.08 and v1.09beta. Coop missions, respawn as seagull.
Just because im reading for the 2nd time that others claim otherwise, I will test it yet again, but I think that's the 5th time im trying to be sure
update I just told someone to enter: test5 = 1; publicVariable "test5";  in a console, after I joined and tested the varialbe "test5", it's value was 1. Again confirming my earlier claim

And this leads us to the next question: the server receives onPlayerConnected signal even before the player client has started the execution of the corresponding init.sqf script. In you publish the variables at this time, and the common init.sqf initializes them, there will be an overwrite situation where the client might overwrite what the server broadcasts.

IMHO unnecessary, imo the proper solution would be to use: if (isNil "variableName") then { variableName = (default value) };  in the common.sqf

[Mr.Peanut]

What would really be useful to know is the order of events when a player JIPs. When does the server start sending data relative to the init.sqf and processInitCommands? Or does all this happen in parallel?

If BIS has PV'd variables sent at JIP, why the hell didn't they do the same with time and weather? It may be more flexible (maybe you want a fog punishment script for TKers) but this usage would be mostly desirable. Night time as a team handicap?

A big pitfall of JIP, IMO, is that the state of non-repeatinging triggers has to be carefully managed. The last thing you want is to have all these triggers that have fired already to fire all at once when someone JIPs into the mission.

[Sick]

Agreed. But time is synced and weather is synced in a sense that it should be the same as the rest of the players due to the time-mission-is-already-running and the weather/fog settings bar in the editor.

However, they do not sync artificially induced modifications to either time or weather. And in this I agree that they should've, maybe in ArmA2 they add these things On the other hand, in case of artificially induced modifications, maybe it's better that the result for JIPpers etc is completely in your hands

Syncing markers is another one on my list. So simple, yet not implemented

About triggers I can barely speak with you, I usually only use triggers for the list of objects they produce, all the rest is either event or script based