Messages

1

TNet 3 Support / Object ownership

« on: September 21, 2017, 04:04:54 AM »

I have searched the forums regarding transfer of object control / ownership.
In one thread, a poster describes a method of setting mOwner to reassign ownership but is dissuaded from doing so a(by Aaron) as it might mess things top.
On the other hand, in one of the examples there is a ClaimObject method which does exactly the above.

What is the current truth and recommendation? Thanks!

PS. Still struggling with the “error: previous reply was less than 180 seconds ago”, even though that is not even true. I can wait 15 minutes and still get that error…?

2

TNet 3 Support / RFCs IDs : why/when?

« on: September 21, 2017, 03:09:30 AM »

Short question: The examples, documentation and some comments on the forum indicates that RFCs can be sent and implemented with or without a custom ID.
In one post I think Aaron wrote something along the lines of "You don't have to specify an ID, but you can do that if you want to optimise bandwidth".

So, when would you specify an ID and what effects does it have? From a coding POV, skipping IDs are certainly easier as you don't have to keep track of which you have used. So any clarification would be very helpful.
Thanks!

3

TNet 3 Support / Re: Static TNObject IDs

« on: September 20, 2017, 12:09:50 PM »

Again, thank you!
Understand the caveats and agree that this particular implementation will probably not run into problems. Will let you know if it does.

Again, thank you for your patience and help!

4

TNet 3 Support / Re: Static TNObject IDs

« on: September 20, 2017, 04:28:45 AM »

Thanks for the reply!

Regarding the RFC._Saved, we currently use it as follows:
1. first player starts server, joins channel x
2. after scene load creates procedural
3.procedural parameters sent with TNO.Send and Target.OthersSaved
4. when another players joins channel x they will receive the calls in #3 and proceed to create the same procedural content as the host

Is this the discourage (the Target.OthersSaved)? If so, what is the proper way to ensure the data is saved and available for reuse by joining players...?

TIA!

5

TNet 3 Support / Re: Static TNObject IDs

« on: September 19, 2017, 04:09:30 AM »

Also, maybe I am being ignorant, but as far as I can tell JoinChannel does not always lead to a level loading asynchronously? If it is not connected, LoadScene is called which uses LoadLevel. If it is connected, it fires off a join request which I cannot readily see what the result of. Maybe that leads to LoadLevelCoroutine being started?

6

TNet 3 Support / Re: Static TNObject IDs

« on: September 18, 2017, 09:47:39 AM »

Thanks for the replies!

Do I also understand things correctly in that I can use static objects already present in the scene at load *if* the scene is loaded via JoinChannel? I could have 2-3 managers set up in the scene before loading and these will be able to communicate assuming I use JoinChannel to load that scene?

TIA!

7

TNet 3 Support / Re: Static TNObject IDs

« on: September 15, 2017, 01:32:04 AM »

The UIManager does not need to communicate. However, the scene that loads on game start contains several managers that do need to communicate.
I am under the impression that they will not be able to do so unless instantiated after scene load? Which is contrary to the Unity UI philosophy (ie. use the inspector to set up dependencies that do not need dynamic allocation).

The one hope I have is that the following is true:
Static objects already present in a scene *will* be able to communicate *if* the level is loaded via JoinChannel with the specified level.

If the above is true we would be able to set up player connections, join channel X with the main game scene specified, do procedural stuff (using managers which can now network since we loaded via join channel) then join channel Y (additively) to instantiate game objects and run the main game.

Do I finally understand this correctly...?

8

TNet 3 Support / Re: TNet 3 - Send RFC messages

« on: September 14, 2017, 11:07:18 AM »

We currently have the gameplay scene load asynchronously via normal Unity calls. Is there a call to load levels async via Tnet.JoinChannel?
Or do we have to load the level (async, normally) first and the instantiate our manager objects? The latter would be more hassle then just calling join channel with an async option...

9

TNet 3 Support / Re: Static TNObject IDs

« on: September 14, 2017, 08:27:12 AM »

Still no clear reply?

Also, TNet is a few years old at this point. Is there still no proper documentation that explains the general recommended strategy for successfully using Tnet for more complex projects? There seems to be a lot of requirements and little tricks that one is supposed to know, but are not really explained anywhere...?

10

TNet 3 Support / Re: Static TNObject IDs

« on: September 14, 2017, 12:41:27 AM »

Every new object from point 2 onwards will be networked.

It's really not a limitation. It's basically just this: if you're not connected to a network, don't expect networking to work. Furthermore, if you connect to a network you'll need to re-initialize existing objects for them to be networked.

But it is a limitation. If I have a master game control object for example., that exists upon launch. There are situations where it would be fully feasible for that object to want to communicate to other clients, without it being poor design.
Requiring that object to be deleted/instantiated or using a workaround suggests limitations in how TNet is implemented. It seems to have a very rigid design philosophy which is contrary to what we would like in a networking solution.

Again, I'd urge you to re-think your design. ArenMook's dealing with a lot of procedural content in his new game and we'd be getting any changes he makes to TNet. There haven't been many, so TNet definitely supports what you want to do.

I would then be very interested in how he does things in his new game. Or if you could point to an example or documentation that describes how to allow persistent manager objects to always be aware of the networking (if available).

Why is it a good feature having "old" objects not being able too hook into a new channel? I cannot see the point of the restriction.
Please not that I am not being argumentative for argument's sake. I am merely offering constructive criticism and trying to find a solution for us that does not require a switch of networking solution.

Thanks in advance.

11

TNet 3 Support / Re: Static TNObject IDs

« on: September 13, 2017, 10:36:33 AM »

And just to clarify:
The managers only need to communicate via RFCs or some other remote function execution mechanic. They do not need automatic syncing etc.
I understand why instantiated objects and other run-time game components might need to have these requirements (being instantiated or loaded via TNet), but I do not really understand why higher level components cannot use networking if scenes are loaded the traditional way....?

12

TNet 3 Support / Re: Static TNObject IDs

« on: September 13, 2017, 09:17:47 AM »

Thanks.

But this really makes networking of higher functions in managers a pain in the proverbial a**...!?
Ideally, I do want the game manager and other entities to be able to communicate even though they are persistent (singletons using dontdestroy). The same goes for the in-game managers. The loading flow would be:
1. player joins channel 1.
2. loads game scene
3. procedural stuff is generated, if host data is sent to joining players (terrain info etc.)
4. player joins channel 2.
5. stuff is instantiated.

From point 2 onwards I want to utilise the in-game managers for a lot of things using RFCs primarily. And they cannot be destroyed at any point until the player leaves the game session.

How would we accomplish this without running into problems? It has to be achievable I suppose, since if not I do not see TNet as a viable solution.. :-/

13

TNet 3 Support / Re: Static TNObject IDs

« on: September 13, 2017, 08:26:20 AM »

Thank you!
Maybe I misunderstand then. A game session for us flows like this:
1. Enters menu screen. The menu screen contains global managers (central game management, UI management, etc.).
2. Player either hosts a game (starts server instance) or joins.
3. Loads main game scene (not using TNet, normal async load).
4. Main game scene contains game runtime managers (environment, terrain, etc.) that need to communicate with other clients.

These managers in step 4 only reside in the game scene and inherit from TNbehaviour. I interpreted that thread as Aron stating that game objects that inherit from TNBehaviour (or simply have TNOs attached) MUST either pop into existence via:
- residing in a scene loaded via TNet (remember, ours isn't)
- being instantiated via TNet (our already exist in the scene).

So, our case would run afoul of the requirements in TNet3. Did I understand this correctly or totally miss the point?

Thanks!

14

TNet 3 Support / Re: Static TNObject IDs

« on: September 13, 2017, 07:24:14 AM »

My deepest apologies. I replied in the wrong thread.
My reply was meant as a reply to this thread:
http://www.tasharen.com/forum/index.php?topic=14171.0

Can you move my reply or should I post in that thread as well...? Again, sorry and thanks in advance for any assistance.

PS. The forum security settings appear to be overly harsh. I could not post this reply for quite some time due to repeated notices that “my previous reply was less than 180 seconds ago”. And it seems each attempt pushed that timer along. We host forums ourselves and I would advise you to fight spam with another mechanic.

15

TNet 3 Support / Static TNObject IDs

« on: September 13, 2017, 06:55:03 AM »

Must admit this is a bit confusing.
In our project (which used to use TNet2) we have managers set up inheriting from TNBehaviour. These have RFCs etc. implemented and will respond to network events. These managers are not instantiated at load time and the level is not loaded using TNet.
Does this mean that we now (having upgraded to TNet3) have to handle these managers in a different way? Perhaps they do not even have to inherit from TNBehaviour to respond to network calls? Is there a better way?