Dynamic/complex objects

[ArenMook]

1. First player joins the level.
2. First player sees that he's alone, figures out all he needs to generate the level. Instead of generating it, he sends an RFC call with am "AllSaved" target.
3. The player gets the RFC sent in step 2, sets TNManager.isActive to 'false' and proceeds to generate the level.
4. Once the level has been generated, TNManager.isActive = true, and continue processing messages as normal.


1. Second player joins the level.
2. Second player sees that he's not alone and does nothing for step 2.
3. The player gets the RFC sent in step 2, sets TNManager.isActive to 'false' and proceeds to generate the level.
4. Once the level has been generated, TNManager.isActive = true, and continue processing messages as normal.


Note how steps 3 and 4 are the same, and that the level creation RFC was sent first? It means it will be received first. If you then need to make corrections to the level, send them via a separate RFC call with a different function name and/or ID.

[danfoo]

Thanks! I had that figured out. However, your approach hinges on the requirement that the info needed to create the world can be passed in one RFC (since only the last one is saved). Also, it assumes the RFCs will always arrive in the original order. Is that a safe assumption to make?

Anyway, I had been hoping we would be able to split the info into several RFCs as otherwise we would have to serialize the info to efficiently pass it. The more I look into it the more it seems as if this is the way we have to go if we are to use Tnet.

Thanks for your help!

[ArenMook]

Ideally you'd pass everything you need in a single RFC, but you can use multiple ones as well if you like. And yes, the order you send them in is the guaranteed order in which they will arrive. If you want to use multiple RFCs, you can -- you'll just do step 2 several times. The key is to send some RFC first that says "ok, generating level, pause everything!"

[danfoo]

I wrote most of the scene communication part yesterday and opted for a single call. Basically, I serialize the custom (and complex) data structure and will send it as a byte array.
I am still curious about the multiple RFC part though; I thought only the last sent RFC was saved? In this case we would have had multiple identical steps so multiple identical RFCs, which I thought did not work?
Merely theoretical at this point, but is still of interest to me and possibly others.

Thanks!

Edit: Two requests:
- Would it be possible for you to change the name of TNet.List ? It conflicts with the List in generics. Trivial to work around with TNet.RFC etc, but still.
- Do you have any plans to add online class documentation etc. ?

[ArenMook]

Online class documentation can be found here: http://www.tasharen.com/tnet/docs/

TNet.List is inside a namespace, so it doesn't conflict with anything unless you attempt to "use namespace" both the generic one and TNet. Just pick one.

[danfoo]

Online class documentation can be found here: http://www.tasharen.com/tnet/docs/

Thanks. Could not find that link on your documentation page.

TNet.List is inside a namespace, so it doesn't conflict with anything unless you attempt to "use namespace" both the generic one and TNet. Just pick one.

I do understand how namespaces work, thank you very much.
My question was merely regarding the wisdom of choosing the same name as it is quite likely that people might be wanting to "use" both TNet and generic. Unless your List improves on the standard one, in which case that would be information worth sharing.

Oh, and by the way you missed (or ignored) this question:

I am still curious about the multiple RFC part though; I thought only the last sent RFC was saved? In this case we would have had multiple identical steps so multiple identical RFCs, which I thought did not work?
Merely theoretical at this point, but is still of interest to me and possibly others.

[ArenMook]

Missed it, yes. Sorry.

When sending via Target.AllSaved or Target.OthersSaved, only the last time you call that specific RFC actually gets saved. The goal is to send the "latest" information, whatever it may be. So in a game with variable number of factions, whenever one faction would change, you would send the entire list of factions via an RFC marked as saved.

TNet's List indeed improves on the generic list. TNet's List and NGUI's BetterList are the same thing. The goal of TNet's List is to replace the usage of the generic list, as generic list does way too much GC allocation to be used safely. Generic list allocates memory every time you modify it. GC is very expensive in Unity.

[danfoo]

Thanks!

The TNet list makes perfect sense as I have observed Lists being expensive if used unwisely, and I understand your reason for using the same name as it allows for a swap without modifying code. Makes perfect sense.

This far it all does, which is why I kindly would like to encourage you to improve the written documentation a bit. I would happily have paid quite a bit more for a package with more documentation in place that makes it easier to figure out how to use TNet to our specific situation.

Also, sorry if I my last reply was a bit terse.

[danfoo]

TNManager.isActive = false; will effectively pause processing of RFCs, letting you do whatever you want.

So if you want, you can do it like so:

1. First RFC that says "create my scene" arrives -- you set TNManager.isActive to false, do your thing.
2. Once you're done, TNManager.isActive = true, continue processing.

You have to forgive me if I am missing something obvious. However, as far as I can tell TNManager does not have a property called isActive?
Edit: Apparently it does in a new version on the Asset Store. Did not notice this in the change notes in this forum though, only a bugfix. Oh well, it compiles now.