JIP question

[tobmic 10]

Hi there i have a question about Join in Progess.

I have made 2 briefings in my mission folder when task1 till 5 are done i activate a trigger with

nul=[] execVM "tasks\task2.sqf";

to get new tasks assigned.

Now i wanna ask you guys is that JIP friendly if i do it that way with a trigger I placed in the editor ?

[Bon 12]

Ask yourself if the condition in the trigger will be true for someone who joins in progress. Lets assume, there is an object which activates the trigger once it is destroyed (typical example, condition somewhat like "!alive tank"). Of course it will be destroyed for a jip as well, so on a jip machine this trigger gets activated right away.

Machines on which this one trigger got activated before, and considering the trigger NOT set to "repeatedly", this trigger will not fire again on your machine when another machine joins.

The very best way of learning this / getting familiar with it, is just to try it out. It is no problem to setup a dedicated server on your own local machine, start ArmA as usual and connect to the dedicated server. Cutting your internet connection allows you to start ArmA twice or more times, and connect multiply on the server. This way you can test for MP behavior, JIP aso.

[tobmic 10]

thx Bon for your answer !

i guess when im done i upload it on the server and test it :- )

[Reimann 10]

I'd recommend the trigger changing a variable and making it public. JIPs will pick up the latest variable value if it has been broadcast with publicVariable, and have those connecting check variables to update tasks.

[tobmic 10]

Can you give me an example on how to do that Reimann ?

[Reimann 10]

A trigger, requiring isServer and whatever condition you want met, and on act.

varName = true; publicVariable "varName"

Have a script run from init.sqf that includes an addPublicVariableEventHandler to update tasks and fix markers and whatever...

[Bon 12]

From my own experience, I recommend to avoid using publicvariable whenever possible.

First of all, I had it sooooo many times, that a publicvariable won't get synced to JIP machines. Secondly, a variable being broadcasted will be broadcasted to every machine, not only on the joining one. Then using an addpublicvariableeventhandler can screw your whole work.

Third, its just unnecessary network traffic.

Keep it clean and local unless this is not possible. Trust me.

It is always better to: set a variable of a persistent object (e.g. a game logic) and then let the client get the variable itself instead of triggering code by a addpublicvariableeventhandler.

Edited March 3, 2010 by Bon

[xeno 234]

First of all, I had it sooooo many times, that a publicvariable won't get synced to JIP machines.

That's not true. variables publiced allways get transfered to JIP clients (latest publicVariabled/broadcasted state).

I often see the error that people define variables in init.sqf and later on in the game those variables get publiced. Means, a JIP player receives the correct value while connecting but when init.sqf then runs for the JIP client the variable reverts back to the default value.

Secondly, a variable being broadcasted will be broadcasted to every machine, not only on the joining one. Then using an addpublicvariableeventhandler can screw your whole work.

?

publicVariable EHs are just fine and when cleverly used you can reduce network traffic for data that doesn't need to get transfered to JIP clients to allmost zero.

It is always better to: set a variable of a persistent object (e.g. a game logic) and then let the client get the variable itself instead of triggering code by a addpublicvariableeventhandler.

addPublicVariable and using setVariable publiced are two completely different things.

You can send your whole network data through one publicVariable and react with a publicVariable EH (like allready described above).

A persistent object isn't needed at all (it's an option but nothing else).

If you don't have that many variable that are triggering events in the game you can also check if they exist allready. Means, instead of defining an initial value in init.sqf for example, do a nil check on a JIP client.

If the var is still nil, the event hasn't occured. If it is not nil, do what happens when the var gets defined during the game.

Triggers do also work with a conditioin like !isNil "myvar" instead of myvar.

Xeno

[Bon 12]

That's not true. variables publiced allways get transfered to JIP clients (latest publicVariabled/broadcasted state).

I often see the error that people define variables in init.sqf and later on in the game those variables get publiced. Means, a JIP player receives the correct value while connecting but when init.sqf then runs for the JIP client the variable reverts back to the default value.

Ye, I initialized the variables in my Init.sqf but of course checked first if they are nil or already transmitted. And I tested it sooo many times, and every time it looked to me the variable didn't get transmitted when I jip. So I put an extra "publicVariable" for each needed variable into the onplayerconnected statement, and bam, screwed all my code because the related publicvariableEventhandlers got executed on each machine when someone connected. So I had to make the pbEventhandler check whether it was a regular broadcast or related to jip, and that's what I was talking about.

Then I went another direction by storing variables in a variable space, and let the joining players get all the information to get up-to-date by themselves, checking the variable in the variable space.

So far, my experiences using this way are much better than with publicvariables and publicvariableEventhandlers.