[UNSOLVED] Sending a message back and forth not working

[Hoppertje]

I am stuck with sending messages back and forth...

My Goal Is:
Client connects to server(No Lobby)( OnNetworkConnect returns True )
On client connection send message from client to server ( Not Working )
On message receive send back message to client ( Not Working )

The FromClient() in the server script does not get triggered

Unity Server Project:

Attached scripts to empty GameObject:
NetworkManager
TNOObject

1. using UnityEngine;
2. using System.Collections;
3. using TNet;
4.  
5. public class NetworkManager : MonoBehaviour
6.     {
7.     TNObject    tnoObject;
8.  
9.     private void Start( )
10.         {
11.         TNServerInstance.Start( xxx1, xxx2 );
12.         tnoObject = GetComponent<TNObject>( );
13.         }
14.  
15.     private void Update( )
16.         {
17.         }
18.  
19.     [RFC] void FromClient( string myString, int playerID )
20.         {
21.         Debug.Log( "From Client: " + myString );
22.  
23.         Player p = TNManager.GetPlayer( playerID );
24.         // tried p, p.id, p.data
25.         tnoObject.Send( "FromServer", p.id, "TestFromServer" );
26.         }
27.  
28.     private void OnNetworkConnect( bool success, string message )
29.         {
30.         Debug.Log( ">> OnNetworkConnect " + (     success+" <> "+ message ).ToString() );
31.         }
32.  
33.     private void OnNetworkDisconnect( )
34.         {
35.         Debug.Log( ">> OnNetworkDisconnect " );
36.         }
37.     }

Unity Client Project:

Attached scripts to empty GameObject:
NetworkManager
TNManager
TNObject

1. using UnityEngine;
2. using System.Collections;
3. using TNet;
4.  
5. public class NetworkManager : MonoBehaviour
6.     {
7.     TNObject    tnoObject;
8.  
9.     private void Start( )
10.         {
11.         TNManager.Connect( "xx.xx.xx.xx:xxx1" );
12.         tnoObject = GetComponent<TNObject>( );
13.         }
14.  
15.     private void Update( )
16.         {
17.         if( TNManager.isConnected )
18.             {
19.             tnoObject.Send( "FromClient", Target.Host, "TestFromClient", TNManager.playerID );
20.             }
21.         }
22.  
23.     private void OnNetworkConnect( bool success, string message )
24.         {
25.         Debug.Log( ">> OnNetworkConnect " + (     success+" <> "+ message ).ToString() );
26.         }
27.  
28.     [RFC] void FromServer( string myString )
29.         {
30.         Debug.Log( "From Server: " + myString );
31.         }
32.     }

[ArenMook]

When working with TNet, there is no need to have different client and server projects. The way TNet communicates is by matching TNObject IDs, then locating a MonoBehaviour with the correct function name (or ID if you used that). When you do tno.Send(...) this message gets sent to the server, where it will be relayed to the recipients.

Start by creating a single scene. In this scene, create a MonoBehaviour that has OnNetworkConnect, OnNetworkDisconnect, OnNetworkJoinChannel, OnNetworkLeaveChannel, OnNetworkPlayerLeave functions. Debug.Log the entries just so you see when they get called.

Now create the means of communication -- attach TNObject script to this game object. With TNObject present, your script can now derive from TNBehaviour instead of MonoBehaviour, thus letting you send messages back and forth.

Assuming you have something like this:

1. void OnGUI ()
2. {
3.     if (GUILayout.Button("Host")) TNServerInstance.Start(5127);
4.     if (GUILayout.Button("Connect")) TNManager.Connect("127.0.0.1");
5. }

...you now have the means of starting a server on one instance of your program, and connecting to it on another.

Now that you have a connection, you can communicate -- but you should first join a channel. Inside OnNetworkConnect() function:

1. void OnNetworkConnect (bool success, string msg)
2. {
3.     TNManager.JoinChannel(123, null); // <-- 'null' can be another scene to load if you don't want to keep the same one
4. }

Now both clients will be in the same channel as soon as the connection is established. This lets you send messages back and forth. Expand the OnGUI function like so:

1. string mText = "";
2.  
3. void OnGUI ()
4. {
5.     if (GUILayout.Button("Host")) TNServerInstance.Start(5127);
6.     if (GUILayout.Button("Connect")) TNManager.Connect("127.0.0.1");
7.     if (GUILayout.Button("SetText 1")) tno.Send("OnText", Target.All, 1);
8.     if (GUILayout.Button("SetText 2")) tno.Send("OnText", Target.All, 2);
9.     GUILayout.Label(mText);
10. }
11.  
12. [RFC] protected void OnText (int val) { mText = "Last value: " + val; }

And there you have it. One client connects to another, then you can press the SetText 1 and 2 buttons, seeing values change on both instances of your game at once.

[Hoppertje]

Firstly i like to thank you for your very extensive explanation!

And as i will have to re-read this post a couple of times to fully understand it... i do feel to mention that i choose to have client - server code separated... i do not want the client to have any server code...

Does that change things?

[ArenMook]

It's going to be a lot more challenging to do that, and far more prone to bugs. You are approaching it with a traditional understanding in mind -- same one I had in mind before adopting a more flexible approach advocated by TNet.

TNet's approach is basically like an IRC chat room. Users join the same chat room and they can send messages back and forth. One user can be designated a channel operator, with some extra perks... but the server -- the IRC server itself that forwards messages to clients -- never participates in discussions. Same with TNet. The server is a tiny 65 kb stand-alone executable that can be ran anywhere, if not directly from within your game (TNServerInstance). One of your clients will be designated as a "host" per channel, and should be the one to run such things as AI logic -- which his what I also do in Windward.

One huge advantage of this client-side approach is that all the processing is offloaded to clients -- which is massive in terms of saving you resources. Another advantage is that either client can host a game. There is no need for separate executables. Still another more important advantage is that your client code is the same whether one of the clients is the "host" or not, which makes coding your game significantly more straightforward.

Still, if you really need to do packet inspection, you can still do that on the stand-alone server. And TNet does come with a solution for it in the ZIP folder. You can add any and all logic there that will inspect incoming packets and do something extra, such as catch cheaters if you need to worry about that.

That said, I strongly advise you to spend some time and get the basics of TNet going without separating your client and server logic from the start. See how much more straightforward everything can be first -- and once you get the basics working smoothly, decide whether you still want to do the separation, or if the same can be accomplished easier via other means.

[Hoppertje]

Yes you are right, i do think my mindset is set/stuck in a traditional way... I do not have that clarity you speak off...

What you are describing here I can see this work for a small multi-player environment, where each game is hosted by a player ( 2-64max )... but my approach is that for an MMO( i should have mentioned this earlier )... I do not wish others to run a host at all... There has to be 1 dedicated authoritative server, which is controlled by me...

Sorry for running in circles here...  Should i consider the designated host here to be this dedicated authoritative server ?
Run it locally next to the Lobby(Master)Server ?

( I am not sure what you meant by doing packet inspection! - I dont think i was suggesting this? )

[ArenMook]

Packet inspection is when the server looks at what arrives from clients, not merely forwards the data to the destination.

MMO server architecture is insanely complex. You basically need to write your entire game's logic -- from AI, to world partitioning, to how things move and how it all ties together on the server. For something like that you would need to make heavy modifications to the server that comes with TNet.

Also, as a rule of thumb that's pretty common knowledge... unless you have millions of dollars in the bank, a team of a few dozen developers working for you, a couple of full-time years to spend on the project with that team, and personal 15+ professional development experience, MMO is the absolute worst choice for a game project. A typical single player game takes a small team of developers anywhere from 6 months to a year. Multi-player game -- multiply that number by ~4. MMO? Multiply by 20.

[Hoppertje]

I appreciate your warning but that is really up to me right?

All i need to find out how creative i can be with TNet's structure...

- How many rooms can you create?
- How many clients could you connect into a single room?
- Can you be sole owner to all rooms that are created?
- Can you communicate between rooms?
- Can you deny players creating rooms?

After having re-read your first reply, you give me a alternative solution which i will test further... however you did not give a answer to my initial code question, can it be done as i suggested, what am i doing wrong in that piece of code?

[ArenMook]

- How many rooms? 4.2 billion.
- How many clients in a single room? As many as you can have connected to the server.
- Can you be the sole owner... depends on what you mean by "owner". Only one person in the channel is "host" -- whoever entered it first.
- Can you communicate between rooms -- yes. Broadcasts go to everyone, and you can also send private messages given the player's name or ID.
- Can you deny players creating rooms -- Yes, if you created them first with a password.

Only the last part may need modifying the server, depending on how you want the "not allowing players to create rooms" handled. If you do it on the client via proper game code, then you don't need anything. If you are concerned about players decompiling your code and reverse-engineering what you did, then trying to hack your server... then you will need to add safeguards in the server itself.