Messages

31

TNet 3 Support / Re: Send list

« on: March 01, 2014, 06:49:41 AM »

I am quite sure TNet will not serialize lists or player objects. What you likely want to do is to send an array of playerIDs to the joining player.
However, I am not sure that that is even needed as I would think that TNManager.players will be kept in sync automatically and you can simply use that after successfully joining. Not 100% sure though as I am still in the coding stage myself - have not run any of the net code yet.

32

TNet 3 Support / Re: TNet.List IEnumerable

« on: March 01, 2014, 04:53:35 AM »

I may as well mention how we seemingly have managed to avoid most GC issues. In code running frequently I tend to reuse most variables. I avoid allocating in often used functions and almost never do it in loops. Maybe it is not good and clean coding practice but given the problems with GC it is a good thing to do IMHO.

33

TNet 3 Support / Re: TNet.List IEnumerable

« on: March 01, 2014, 04:33:30 AM »

@ldw-bas: TNet's List already has GetEnumerator() implemented, so it should be already usable in a foreach. I'm not sure what your changes would add.

The case I stumbled upon was the inability to initialize the list when creating it ( new List() {bla, bla} ). Not sure idw's change solves that but I did track down how to do it the other day and it seemed very simple.

@danfoo: GC is the devil in Unity. I've seen many Unity games that stutter every few frames when GC collection occurs. It's incredibly annoying and noticeable. Kerbal Space Program is a good example of that as it requires precision and finesse to begin with, and GC makes it incredibly frustrating at times.

Also... just google "unity foreach ios". http://makegamessa.com/discussion/1493/its-official-foreach-is-bad-in-unity/p1

Yes, I know. I have read a bit about the ins and outs of the different Mono versions and speculation on why Unity has not moved to the later versions with generational GC (licensing issues?). My current stance is actually that it was easier to program in C++. Sure, you had to manually allocate and deallocate, but you knew that and you were careful to avoid any leaks. With C# you get a false sense of security and a lot of wishful black-boxing. It is actually harder to keep track of when things are left to GC. Thank god for the profiler...

As for Kerbal, I have not actually tried it. I am a bit surprised though that they have not been able to work around the GC issues if they are that obvious. Have to search and see if they have written anything about it.

34

TNet 3 Support / Re: RFC payload size limit?

« on: March 01, 2014, 04:24:46 AM »

We are nowhere near those sizes so I think we should be fine then. Thanks!

35

TNet 3 Support / RFC payload size limit?

« on: February 28, 2014, 03:49:44 PM »

Did a Google search but found nothing, so here we go:

Is there a size limit or max size recommendation for arguments to RFCs? The only hits I got for the search query was someone sending a string array and getting weird errors. We will be sending a lot of byte[], int[] etc. with a fair number of entries. Will this be a cause of problems?

Edit: By a lot, I do not mean in the same call. But there will likely be a few calls each second with various arrays of varying size (sometimes small, sometimes quite populated).

36

TNet 3 Support / Re: Dynamic/complex objects

« on: February 28, 2014, 01:26:33 PM »

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.

37

TNet 3 Support / Re: TNet.List IEnumerable

« on: February 28, 2014, 01:11:54 PM »

I spent a while this morning reading up on memory related issues in Unity3d. There is a fair bit of info available, even a Gamasutra article series on the subject. (Google Gamasutra Unity memory).

Anyway, I am probably revealing my age here but strictly speaking I would not call the issues "memory leaks". In older languages (C/C++ etc) memory leak was a situation where you failed to deallocate something and that memory was then "leaked" and you could never retrieve it. If you did it enough your application would crash. Period.

The issue at hand here is that that certain practices will allocate things on the heap where they need to be garbage collected. So they will be taken care of and you will get that memory back. However, garbage collection - especially the type apparently used by the mono version Unity uses - can be slow. So if you use "leaking" practices too much your game will likely stutter when the garbage collection kicks in. Sure it can crash too if you manage to leak too much memory before the GC has a chance to fix this, but you would have to be really careless IMHO.

I knew about the garbage collection problem, but I did not know that foreach and Ienumerable could add stuff to GC. Fortunately, the only places where we iterate lots of stuff using either method is in bigger operations that happen seldom and are user initiated. And we do call GC as well as Resource.Unload-whatever-it-is-called after (and sometimes during) these operations.
When running the game proper where fps is important we iterate using regular for loops and seldom do any fancy stuff. I think we may start a few coroutines sometimes so that is something I have to look at (that apparently causes overhead too - more than expected).

My take on the whole issue is that unless you are careless this is not much to worry about. I would advise to write nice code using the tools available (even if that is a foreach, coroutine, Linq etc.) and get it to run. Then profile and focus on the areas that truly are a problem. If you are smart and use the tools wisely you can most likely get a nice, well running game without having to do many .net workarounds if any.

Please note, that this is in no way criticism towards Aren or his implementation of TNet.List etc. I have not looked too much under the hood, but in frequent use (as I would suspect is the case in TNet) foreach, heavy list manipulation etc. *would* make a significant difference. So the custom version makes perfect sense. However, it may not make sense to rewrite your code to use it unless you will be relying on lists heavily many times / second.

Oops. Sorry for the length. Hope it may help someone.

38

TNet 3 Support / Re: TNet.List IEnumerable

« on: February 28, 2014, 02:40:18 AM »

I had no idea foreach had memory issues on iOS. How severe is it? Any idea why it has not been fixed? We have titles on the App Store which uses quite a bit of foreach (mainly to iterate through Hashtables) and while they perform well (few crash reports) no one likes memory leaks.

Regarding the other performance optimizations, the price for convenience (in this case generics compatibility) must be relatively small? Have you measured the effects and concluded they are significant enough to warrant the dropping of the features?

39

TNet 3 Support / Re: TNet.List IEnumerable

« on: February 27, 2014, 11:55:42 AM »

Yes, I am modifying mine as well just to be able to swap them if I want to.
I am adding:
- Count
- Implementing IEnumerable
- Implementing Sort using IComparable
...and we will see if something else pops up.

But, I agree with you. I would rather have this rolled into TNet proper both to ensure I am not introducing bugs and to make updating  of TNet effortless.
Aren/Michael, would you consider including these additions in the official version?

40

TNet 3 Support / Re: TNet.List IEnumerable

« on: February 27, 2014, 09:30:54 AM »

I was just about to post about this too. I ran into this while switching from the generic list to TNet.List.
TNet.List seems to replace a rather limited portion of the generic list. Another feature that is "missing" is Sort(). I have a class that implements IComparable which I would like to use with TNet.List.

While I can work around these things and possibly edit TNet.List to do what I want I really do not want to keep having it overwritten when updating.
Any chance of having these things added to TNet.List?

41

TNet 3 Support / Re: Dynamic/complex objects

« on: February 26, 2014, 05:28:11 PM »

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.

42

TNet 3 Support / Re: Dynamic/complex objects

« on: February 26, 2014, 04:24:40 AM »

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.

43

TNet 3 Support / Re: Dynamic/complex objects

« on: February 25, 2014, 03:37:10 AM »

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. ?

44

TNet 3 Support / Re: Dynamic/complex objects

« on: February 24, 2014, 03:23:34 AM »

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!

45

TNet 3 Support / Re: Dynamic/complex objects

« on: February 23, 2014, 09:17:32 AM »

I wouldn't do it like that. Reason being, nothing is preventing RFCs to arrive after the player's channel joined notification and before the host's messages arrive -- so you may be getting RFCs from objects that have not yet been created because you haven't executed your logic yet. Waiting on a host to do something is not a good idea. RFCs should already be there when the new player joins.

I am not sure we understand each other. The host is the player who has created and "owns" the scene. What needs to happen when a new player joins is that the (relatively complex) information about how to recreate the world is sent to the new player and executed before he is receiving buffered RFCs from objects in play.
Frankly, I do not quite understand how to control flows like these in TNet and I have not found any documentation that hints at it. All the examples I have seen are very simple and may apply well to simple "level based" games. There were a similar thread where someone wanted to transmit custom information about level destruction and he did not find a solution either as far as I could tell.

So, given the current state of TNet, how would you suggest we transmit information needed by the new player before buffered RFCs arrive? If that is not possible or recommended we are left with two options, neither of which are optimal:
- Block action on newly instantiated objects that rely on the world until it has been built
- Ditch Tnet and go with another solution.

Again, thank you for your help but I would certainly value some recommendations on how to proceed, especially given the very sparse documentation available.