Hosting bandwidth and server

[ArenMook]

TNManager.LoadLevel indeed should only be called on one client. Others get this automatically -- it's just like any other saved RFC.

RFC sending should be paused while loading the level. It may be possible that this occurs:

Client A sends LoadLevel
Client A receives LoadLevel
Client B sends a periodic RFC
Client B receives LoadLevel
Client A receives the RFC

In this case the RFC arrives after the level load, and the object is no longer there. This should be harmless regardless, but it's going to happen more often with frequently sent RFCs.

In regards to one-way communication, make sure to try using Send instead of SendQuickly and see if that helps. Some devices don't seem to work with UDP very well. TNet *should* disable UDP if it's not functional, but I believe there can still be a rare case when it works with initial handshake checks then stops working and I haven't had a solid case to look at where it would happen so it remains unfixed.

[xandeck]

Hello Aren,

Nice, I thought that something like this was happening.
For now, most of the problems are gone,here is what I am doing (maybe it can help other people with similar problems):
- Only host call Loadlevel
- After loading a new level scene, each player can send  "Ready" RFC. Since my gameObject with TNet and my game logic is global, everyone should receive this, it is a "saved" RFC, so, I think it does not matter it the level is loading, right? (Aren, please, correct me if I am wrong)
- All my move / animations sync is done with custom sending RFCs, so, no DDoS myself
- After changing from one level, to other, my "channel" keeps the same, there is no need to change the channel when changing the scene level, right?
- I can start and end any mission, any time, sync looks good and players does not disconnects

I got one weird problem: sometimes, a gameObject that does not have a TNObject, starts with one (it instance one) (there is a script that uses TNet movement and I think maybe thats the problem, but I am not sure how this is happening)

[ArenMook]

You don't need the "ready" flag if you just check TNManager.isJoiningChannel. It will flip to 'true' only after the loading operation has been completed. All RFC processing is suspended while the level is being loaded.

A channel is an instance of the game you are playing, so there is no need to change channels if you are simply trying to switch levels, that's correct. Some games may want this -- Windward being one of them -- where each channel is a separate zone that players travel to. In Windward's case players are independent, and they travel from one zone to another rather than telling everyone to switch.

TNObject will be added if it's needed -- there must be a TNObject in the hierarchy of a TNBehaviour-derived script or it won't work. I believe it's one other thing I altered in the upcoming version of TNet... it will wait for the Start() before adding this TNObject where before it would do it in Awake (or Enable?), which meant it wasn't possible to instantiate a child and parent it to something before the TNBehaviour script tried to add a new network object.

If this is what's happening in your case you can just request a beta version of TNet's latest code to try out by sending me your OR# via email to support [at] tasharen.com.

[xandeck]

Hello Aren
Thank you for sending the new version to me.
And yes, the new version helped me to find the problem.

I was trying to read a "tno" without having really the TNObject.
The problem was that an object that we used as prefab for instantiating only, was used as "decoration" in one of the scene, so the script was the same and TNet was creating a TNObject in real time for me... now it is solved =)