Best approach for sync'ing dynamic weather across clients?

[toreau]

How would/should one approach this? Change the server code so that it takes care of everything weather-/season-related? Or...?

This also goes for day/night cycles, of course.

[ArenMook]

I actually do this in Windward myself. I have an object in the scene (with TNObject script attached that has ID of 11 in my case). On this object I have a script that controls wind. It takes care of updating the wind's direction and strength periodically (every few seconds), and sends this to everyone via an RFC. Everyone interpolates these values exactly the same, but only the host actually does the updating / sending logic.

For day/night cycles I have another script -- but it doesn't track day/night. It simply tracks "server time", and sync's this value via an RFC periodically. Everyone takes care of advancing the time on their own, and the day/night cycle is based off of that time.

[derkoi]

This is something I'm going to need to do. I'm using the time of day asset from the asset store with my own weather calculations.

Am I right to assume that at the start of the level I'd need to:

1. Check if I'm the host of the channel.
2. Sync current game date & time when a player joins.
3. periodically sync the weather.

Thanks

[ArenMook]

Yup, exactly. You can even use TNAutoSync to sync the weather data. Set it to only sync when a new player joins, and when you want to sync it, just call its Sync() function.

[toreau]

I just want to add here, for future reference, that "only synchronize when a new player joins" means setting TNAutoSync's "Updates Per Second" property to zero, if I've understood the code correctly.

[ArenMook]

Yup, that's right.

[derkoi]

Excellent, thanks guys 

[Patterrun]

Hi Aren,

I think I'm not understanding it, for example I have,

1. using UnityEngine;
2. using System.Collections;
3. using TNet;
4.  
5. [RequireComponent(typeof(TNObject))]
6. public class TestingSync : TNBehaviour {
7.  
8.         private int someStat = 1;
9.  
10.         void FixedUpdate()
11.         {
12.                 someStat += 1;
13.         }
14.  
15.         void OnNetworkPlayerJoin(Player p)
16.         {
17.                 Debug.Log (p+"has joined");
18.                 if (TNManager.isHosting)
19.                 {
20.                         tno.Send(1, p ,this.someStat);
21.                 }
22.         }
23.  
24.         [RFC(1)]
25.         void SyncStat(int sentStat)
26.         {
27.                 this.someStat = sentStat;
28.         }
29.  
30.         void OnGUI()
31.         {
32.                 GUILayout.Label("SOMESTAT: "+someStat, myStyle);
33.         }
34. }
35.  

I chose FixedUpdate() because I know it updates fixed amount of times per second (currently other player's someStat is behind host player's someStat as I would expect). don't I have to compensate for the time the message takes to reach the other player? I understand of course for things like transform.position of a player controlled object may only be predicted (hence interpolation/extrapolation done in all games for movement variables such as that) however this can and should probably be the exact same for everyone because the output should always be deterministic. I think I need to subtract the time spent between the message received and sent and divide by the fixed delta time to get the amount of frames that has gone by the time the new player receives the message but somehow I don't think that is right either. I am probably doing something wrong already by using FixedUpdate() as a test or something else is wrong with my script.

Can I ask how you are synchronizing time for your day/night cycle (won't it be slightly off for everyone if you are sending a lot of different variables too, for example the wind variables)? Perhaps a snippet of code so I can understand better by reading it. thanks.

[ArenMook]

The sync will always be slightly off because of the delay it takes for the packet to go from point A to point B. There is no avoiding it. Best you can do is approximate it by adding ping delay to the packet, but even then it's not going to be accurate as ping can also vary.

Clients are always "behind" the host. It's to be expected.

[Patterrun]

I figured as much. I will work on it as I develop further.

Thank you, Aren.