JIP : how does it really work?

[Cali 10]

Yesterday I had a very hard time making a JIP script, and hard time to test it... I searched the wiki, the forum, and found only very few answers... So I have some questions, and I hope the scripting "pros" will help ;)

1. JIP : what path?

While JIP, what's going on? Is the init.sqf loaded and read? Is there any change in this behaviour?

2. JIP : publicvariable

What happens to publicvariables which are already in game? Is the JIP client knows them?

3. Detecting JIP

I tried some methods, maybe it's me, but none really seems to work. I tested it with a friend on a dedicated server... By the way...

4. Testing JIP

Is it possible to test JIP when you're alone? It seems that my dedicated server launched the mission each time I was quiting and coming back, as I was the last (and only player). Is there a specific way to do it properly?

:o

That's all ^^

[sbsmac 0]

1. Yes, init.sqf is read and executed for each client that joins.

2. No, publicvariables are not automatically broadcast to JIP clients. However, there is a simple trick you can use to ensure all state is transferred. Just create an object and use "setvariable ... true" to store shareable state. The object (along with the variables it contains) is automatically synchronised on JIP.

3. Not sure what case you want to detect ?

4. Yes - you can just run a dedicated server instance and 2 client instances. Ignore the resulting 'fade' message - it's harmless !

[Cali 10]

Thank you for your very complete answer.

2. Concerning this point, could you give me an example? I think it would be very usefull for the people who are looking for JIP solutions :)

3. I just want to detect JIP, to avoid some problems and to synchronize time, weather, etc, without impacting other players. I tried "IsNull Player" but I'm really not sure it's working...

[Muzzleflash 111]

You will find pretty much tested and detailed here: http://community.bistudio.com/wiki/6thSense.eu:EG#Join_in_Progress.

2. Pretty sure publicVariable are sent to JIP's

3. You can detect JIP, look in link

4. Insert respawn and set the server to persistent. Then you can JIP on your own.

[Cali 10]

Thx Muzzleflash :) I will have a deeper look to this on the evening. Thanks again.

[snkman 351]

4. Insert respawn and set the server to persistent. Then you can JIP on your own.

Damn nice! Didn't notice this command so far...

Many thanks ;)

[icebreakr 3101]

Nice trick, tnx.

[Nephris1 10]

3. I just want to detect JIP, to avoid some problems and to synchronize time, weather, etc, without impacting other players. I tried "IsNull Player" but I'm really not sure it's working...

Cali is taking a good point here.

Is it possible at all to synchronize the weather at all?

I always expierience that my fellows get rain or fog asynchron from me.

Is there a way to synch the weather liable and continuing?

Otherwise the use of dynamic weather is almost senseless on dedicated.

[Grimm 10]

Nephris1 = > If you don't want to get involved in the "JIP business" and still want to sync weather and time, you must do an infinite loop, regularly synchronizing clients with server.

Edited October 25, 2010 by Grimm

[Kolmain 6]

How would you continuously check?

[Grimm 10]

You're synchronizing from the server's datas, right? So you just have to use the 'date', 'fog' functions ... (etc) to get the server datas, then send them through network with publicvariables, then activate a trigger on the client side in order to regularly update the whole thing.

But once again, detecting JIP then sync with server is more elegant, and less heavy.

[shuko 59]

4. Yes - you can just run a dedicated server instance and 2 client instances. Ignore the resulting 'fade' message - it's harmless !

When running dedi + 2 clients on same comp, I get "CD Key in use" and get kicked even with "kickduplicate=0;". :(

[CarlGustaffa 4]

Is it possible at all to synchronize the weather at all?

I always expierience that my fellows get rain or fog asynchron from me.

Is there a way to synch the weather liable and continuing?

Otherwise the use of dynamic weather is almost senseless on dedicated.

I do it slightly differently, but it works:

Server weather loop that does:

1. Sets and publishes overcast variable. Change happens over 8-9 minutes.

2. Sets and publishes wind variable. Change happens over 1 minute (just a delay)

3. Sets and publishes fog variable. Change happens over 8-9 minutes.

4. Sets and publishes wind variable. Change happens over 1 minute (just a delay).

5. This script restarts every 20 minutes or so.

It's important to note the split of overcast and fog. You could change and publish everything per update, but wind and overcast changes would have to be done in steps (also for client). Starting a gradual change of both at the same time just won't work.

Client weather loop the does the exact same things, based on the published values.

Server rain loop that does:

1. Check the current overcast and determine a chance and amount. Higher overcast means higher chance of rain and higher intensities.

2. If chance kicks in, publish the amount, otherwise publish zero rain.

3. In a separate loop, keeps setting the rain level, but doesn't have to be as frequent as the client.

4. This script restarts every 30 seconds or so.

Client rain loop that is a bit different:

1. Reads the published amount.

2. Rate of change will depend on difference in amount, but typically quite speedy to disallow the engine to kick in with it's (unsynchronized) intensities.

3. If rate is small or no change is detected, a VERY dense loop keeps setting rain. Loop delay of 0.2 seconds is sufficient, but also required. 0.5 tend to produce a pulsating effect, fighting what the engine tries to do. BIS: I want a delay on engine rain! :p

For a JIP player, he gets all the published variables, and his weather is set without delay or gradual change. Since everything happen only over 20 minutes, the current gradual change for other clients will be over in maximum five minutes. Typically the JIP weather and normal players weather will not be different by a lot, and certainly not for a significant amount of time. I tend to spend more time than that getting equipped, checking mission status, and getting out to the AO.

I like to use distributed randomness rather than full randomness. I.e. there is a tendency to randomly select overcast values around 0.3-0.4, but naturally a full thunderstorm can occur at 0.9, it will just be a lot less frequent than usual. Where I live, we don't experience thunderstorms 10% of the time. Sadly we don't experience clear weather either 10% of the time :D So I feel it acts a bit more natural than (random 1), which most tend to use. I also have dust storms (just rainless wind blowing up dust), snow, and some ppeffects thrown in, and the dust storms can cause a greater problem to visibilities than the rain. I'm avoiding too much fog though.

For me, this system is about as perfect as I think I can ever get it. JIP is handled pretty well, variations take place over time, wind is a separate factor (as it should be), and rain is fully synchronized between clients and better allow for steady low intensities. I have ideas for improvements though.

Now, if I could only get those damned waves to react on wind rather than overcast, I would be very happy.

[alef 0]

When running dedi + 2 clients on same comp, I get "CD Key in use" and get kicked even with "kickduplicate=0;". :(

Try reportingIP="<>" too.

[Grimm 10]

CarlGustaffa => Your system sounds really clever and develops the 'loop' approach I was talking of. But I think something much more simple could be done when JIP :

1. Local : detecting JIP player, and activating global trigger

2. Global (via trigger) : server searches the right values for weather/date, and send them through network, then activates a 'synch trigger' on clients

3. Local : synch trigger activated. Clients update.