Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Deozaan

Pages: [1] 2 3
TNet 3 Support / Re: TNet is very troubling (furious)
« on: August 14, 2015, 01:42:56 PM »
I have to agree that the general idea behind this thread is an issue I have with TNet as well.

I bought TNet about 2.5 years ago (February or March, 2013, IIRC) when it was fairly new. It looked useful. It looked very powerful. But there was virtually no documentation for it. Yes, the source code is there for me to peruse, but it's a massive library and really overwhelming. Point is, I bought TNet so I wouldn't have to learn or understand how the networking works behind the scenes. I just needed an API to let me interface with the networking, and I needed documentation to teach me about the API.

But going by the quality of NGUI, and the large amount of tutorial videos for it, I figured TNet was just young and the documentation and tutorials would come in time.

I was wrong.

2.5 years later, this single page of documentation is still practically the only thing we have explaining how TNet works. There's also a video tutorial, but TNet has changed quite a bit over the years and the video quickly became outdated.

I've learnt that TNet is meant to be used the TNet way. When you understand how it works (which granted isn't anywhere near as well explained as the package is written!) it works very well and provides a very easy framework for network play.

As was pointed out by Shifty Geezer, to use TNet, you have to do things the TNet way. The problem is that the TNet way isn't really, thoroughly explained. That's my major (and perhaps only) complaint about TNet. I can tell that it's a really powerful and useful system. But the parts that it is made from aren't really explained, nor is the general concept behind the whole thing.

And looking at the source code doesn't help a whole lot at understanding the overall theory/concept of TNet. Just look at the many threads here where people don't understand the relationship between Server, Host, and Client. Imagine all the threads that would never exist (freeing up Aren's time) if there was some documentation that explains these concepts? That's just one example! What about explaining what channels are and how they work and how they should be used? The documentation page doesn't even mention DataNode, which devomage said is the best part of TNet.

TNet is an awesome package.  the DataNode class alone is worth the license cost.

In summary: I bought TNet when it was young, because I had no doubt in Aren's ability to make a great product. And when I found there was little helpful documentation, I decided to set TNet aside for a while and give Aren some time to "finish" the documentation. As I patiently waited for this, weeks became months, then months became years, and I'm still not using TNet in any projects.

Please document TNet. Explain the general concepts. Code examples are useful, but English sentences describing the overall process and the TNet way (ideal usage of TNet) would be so much more helpful.

And just to be clear: This isn't meant to be taken as derogatory toward TNet's capabilities or functionality. I'm just trying to say that TNet is a good (great?) project held back by the lack of documentation that would make it accessible to people who want to use it, and in some (many?) cases have even paid for it. I also believe it could greatly reduce the amount of time Aren has to spend providing support, as most noob questions would be explained in the documentation.

NGUI 3 Support / Re: OutOfMemoryException: Out of Memory NGUI 3.7.1
« on: September 01, 2014, 04:07:27 PM »
The space camera only renders the Space layer (layer 20), but Main Camera was set to render the NGUI layer. Would have have caused the problem?

Here are the render depths for the cameras:

Space (-2) -> Main Camera (-1) -> NGUI Camera (0)

Changing it so that the Main Camera doesn't render the NGUI layer appears to have fixed things. Thanks!

NGUI 3 Support / Re: OutOfMemoryException: Out of Memory NGUI 3.7.1
« on: September 01, 2014, 01:31:57 PM »
Thanks. That's useful to know. But my question is: Why is NGUI making it so tiny? I designed it at 1280x720 resolution, but because of the Space Camera (or something) NGUI messes up and makes the UI 2x1 in some places. And it won't let me change the size due to anchoring.

What I'm saying is that I'm not designing it this way, and I can't fix it. NGUI keeps locking the size of my GUI elements to something really tiny (such as 2x1) or something really huge (such as 846354653x864324389), due to anchoring.

And if I try to change the size manually, it sets the offsets of the anchoring to some crazy number, and if I zero those out (because I want it the same size as the parent) it resizes to insanely large numbers. Even if I go to the parent and set the size of the parent to 1280x720. Sometimes I'll get it all configured just the way I want it and then the next time I load the scene it will change all the numbers to something crazy. I don't know what's going on with it. )c:

NGUI 3 Support / OutOfMemoryException: Out of Memory NGUI 3.7.1
« on: August 30, 2014, 12:10:04 PM »
I'm getting the following error from NGUI:

OutOfMemoryException: Out of memory
BetterList`1[UnityEngine.Vector2].AllocateMore () (at Assets/NGUI/Scripts/Internal/BetterList.cs:178)
BetterList`1[UnityEngine.Vector2].Add (Vector2 item) (at Assets/NGUI/Scripts/Internal/BetterList.cs:220)
UIBasicSprite.TiledFill (.BetterList`1 verts, .BetterList`1 uvs, .BetterList`1 cols) (at Assets/NGUI/Scripts/Internal/UIBasicSprite.cs:529)
UIBasicSprite.Fill (.BetterList`1 verts, .BetterList`1 uvs, .BetterList`1 cols, Rect outer, Rect inner) (at Assets/NGUI/Scripts/Internal/UIBasicSprite.cs:329)
UISprite.OnFill (.BetterList`1 verts, .BetterList`1 uvs, .BetterList`1 cols) (at Assets/NGUI/Scripts/UI/UISprite.cs:422)
UIWidget.UpdateGeometry (Int32 frame) (at Assets/NGUI/Scripts/Internal/UIWidget.cs:1459)
UIPanel.UpdateWidgets () (at Assets/NGUI/Scripts/UI/UIPanel.cs:1522)
UIPanel.UpdateSelf () (at Assets/NGUI/Scripts/UI/UIPanel.cs:1185)
UIPanel.LateUpdate () (at Assets/NGUI/Scripts/UI/UIPanel.cs:1144)

I saw a similar problem mentioned in this previous topic which seems to indicate that it was fixed as of 3.5.1, but I'm using 3.7.1 and am encountering this issue.

I think it may have something to do with the fact that I'm using Space for Unity which uses some pretty large meshes and another camera to things look very big and far away. The reason I suspect this is because my problems didn't start occurring until some time after I imported that into my project, and it only seems to happen in scenes where I have both NGUI and Space for Unity.

NGUI doesn't like something about it and I get lots of errors. It also slows down the editor to a crawl and has crashed it a couple of times. Please help me figure out how to resolve this!

TNet 3 Support / Re: Performance
« on: August 07, 2014, 01:30:18 PM »

Following the method you just described, would you recommend using SendQuickly for the frequent input changes and using Send for the infrequent position syncing?

Or do you think it's all important enouogh to use Send? Or perhaps it's all unimportant enough to use SendQuickly?

TNet 3 Support / Re: Target.All vs Target.Others
« on: August 03, 2014, 07:10:42 PM »
Yes, and yes.

You could answer #1 just by looking at TNObject's SendRFC() function. Target.All and Target.AllSaved get executed locally right away. Current Pro version of TNet also handles Target.Host if you're the host.

An RFC function is just that -- a function that you can call freely. The [RFC] prefix is simply there so that TNet can find it (and cache it).

OK, well, I'm confused. tno.Send() doesn't seem to do anything when I'm not connected. I added some Debug.Logs through the whole thing and it seems to make it all the way to TNUnityTools.Execute(), but the following if statement on line 163 is never true:

  1. if (ent.func.Name == funcName)
I just tested and discovered that if I call tno.Send() using the byte ID rather than the string name, it works. So I guess that's a bug in TNet when using the string name to call an RFC?

EDIT: OK, this is weird. I just updated my repository to a different version of the code where I was already using the Byte ID of the RFC and now it works either way, using Byte ID or string name.

TNet 3 Support / Target.All vs Target.Others
« on: August 02, 2014, 10:37:29 AM »

I'm curious about when to use Target.All vs using Target.Others, and what the delay is (if any) when sending an RFC to yourself.

For example, in my player input script, I don't want remote players controlling my character. So I perform the logic that converts input to movement, and use a tno.Send to tell the remote players how my character should be moving.

The question is: Is Target.All smart enough to instantly run the RFC on my local machine so there is no lag (waiting for the command to go to the server, then come back to me) before my character moves? Or do I need to just use Target.Others and then also update my movement locally?

In other words, which of the following is necessary for there to be no delay between input and movement on the local machine?

  1. void Update() {
  2.         // perform some logic determining dMov and other things first
  3.         // and then. . .
  4.         // send out the changes
  5.         tno.Send("SyncMovement", Target.All, dMov); // <-- does this get executed immediately on my own machine?
  6. }
  8. [RFC]
  9. void SyncMovement(Vector3 deltaMovement) {
  10.         _char.deltaMovement = deltaMovement;
  11. }

  1. void Update() {
  2.         // perform some logic determining dMov and other things first
  3.         // and then. . .
  4.         // send out the changes to other players
  5.         tno.Send("SyncMovement", Target.Others, dMov);
  6.         // make the changes locally
  7.         _char.deltaMovement = dMov;
  8. }
  10. [RFC]
  11. void SyncMovement(Vector3 deltaMovement) {
  12.         _char.deltaMovement = deltaMovement;
  13. }

Note that in these examples, I'm not syncing position, I'm syncing movement/input (which direction the character should be moving continuously). In case that makes any difference.

And a follow up question: Can I call an RFC without actually making an RFC? e.g., can I do something like:

  1. tno.Send(myRFC, Target.Others, arg);
  2. myRFC(arg); // <-- will this execute locally?

Is this message normal? Will it cause any problems?

TNet 3 Support / Re: 1 vs 1 matches
« on: July 29, 2014, 02:32:39 AM »
What Unity calls a "Master server" TNet calls "Lobby server". You connect to a lobby server to get a list of game servers. Once you connect to a game server, you don't need to stay connected to the lobby server. You can stay connected if you want an up-to-date list of servers, but you can safely disconnect from it if you don't.

How would you go about disconnecting from the lobby server but stay connected to the game server?

TNet 3 Support / Re: Multiple scene networking / channel question(s)
« on: July 29, 2014, 12:19:30 AM »
So I have Player 1 (P1) and Player 2 (P2). P1 creates a game and loads Scene1. P2 joins the game and also loads Scene1. This is as far as most tutorials/examples/etc go. Let me know if any of the following is incorrect:

From here we use channels to divide the network traffic - generally 1 channel per scene and another channel for things like chat. So P1 and P2 are in channel1 together in scene1. P2 wants to go ahead and goes to the "load scene2" trigger, which then makes P2 leave channel1 and join channel2 (for scene2). Now, scene2 has some things that need to be generated on load, like which enemies to spawn - which should be done on the server/host - in this case P1.

Is it possible for P1 to be in scene1 (and channel1) while feeding state information of scene2 (over channel2) to P2? Would this be done through RFC / RPC calls? What's the best way to handle a situation like this?

Let's say I [...] had one channel per scene. If P1 is hosting and P2 is in a different scene, in a separate channel, how would the host know to update the scene P2 is in?

Would P2 just have to tell P1 that it's the first/only player in the scene, so it will be taking over the reigns for that specific scene?

I'm not sure if you fully understand the difference between Server, Host, and Client as far as TNet is concerned.

Server: Software that facilitates routing packets back and forth between players over the network.
Host: The player (a client) who first joins/creates a channel. If the host leaves the channel, a new host is automatically selected from among the remaining players in the channel.
Client: Any player connected to the Server.

Note that a player can be acting as server and client/host at the same time!

In your scenario, when P1 joins Ch1, P1 will become the Host of that channel. And when P2 joins, he will be a regular client.

But once P2 joins/creates Ch2, P2 will become Host of Ch2 (assuming nobody else is already in Ch2). P1 will continue to be Host of Ch1 until he leaves that channel. Basically, each channel will have its own Host: one of the clients currently connected to that channel.

I hope that was clear. And correct. (c:

TNet 3 Support / Re: Server setup
« on: July 26, 2014, 02:34:28 PM »
Is there any way for me as a developer to know if players are connected via WiFi or 3G/data? So I can enable or disable the option to host depending on their connection type?

Or do I just need to show a warning on mobile platforms informing them that 3G/data servers/hosts can't have any incoming connections?

TNet 3 Support / Re: Server setup
« on: July 22, 2014, 08:31:51 AM »
You can run a server on a mobile device, but you won't be able to reach it via 3G. It will only be reachable via WiFi. To start a server from within your game, just call TNServerInstance.Start.

The only options you have is for its discovery. No discovery (by doing nothing), LAN discovery (using TNUdpLobbyClient), or WAN discovery by registering with a remote lobby server that's hosted somewhere accessible (basically 3rd party).

Are you saying that starting a server on mobile will not allow others on 3G/4G to access it even if they know your IP address or you have a lobby server that is hosted somewhere accessible?

TNet 3 Support / RFCs unique to what?
« on: July 21, 2014, 10:31:52 PM »
In the past I've resorted to making an enum to make it easy for me to remember which byte belongs to which RFC, since they need to be unique.

But I vaguely recall reading some time ago that RFCs bytes can in some instances be re-used. Under what circumstances to bytes for RFCs have to be unique?

Is it on a per-class level (all RFCs in a class need unique byte IDs, but different classes can use the same byte IDs)?
Or do all RFCs across the entire project need to have unique IDs?

The documentation could really use some expansion with little things like this.

And another minor complaint:

When quitting the server, it says "There server has shut down. Press ENTER to terminate the application."

This should obviously say "The server [...]"

Approx. Line 247 in ServerMain.cs

The latest version of TNet can't compile when the platform is set to "Web Player" because of the following errors:

Assets/TNet/Common/TNTools.cs(509,28): error CS0161: `TNet.Tools.WriteFile(string, byte[])': not all code paths return a value
Assets/TNet/Common/TNTools.cs(552,28): error CS0161: `TNet.Tools.DeleteFile(string)': not all code paths return a value

You need the return falses to go after the #endifs to fix these errors.

I also get some warnings about variables which are defined but never used. It would be nice if these messages didn't show up in the console.

Pages: [1] 2 3