Messages

1

TNet 3 Support / Re: What are the TNet equivilent of these UNet functions?

« on: September 14, 2017, 08:06:42 PM »

Thanks - I'll give it a shot.

2

TNet 3 Support / What are the TNet equivilent of these UNet functions?

« on: September 12, 2017, 11:51:33 PM »

I'm starting to convert some UNet code over to TNet and I'm wondering what the TNet equivilent of the following functions are.
If you don't mind, this will be a on-going thread. I'm reading the sources and the examples slowly and starting to understand the events that TNet emits, but I'm a little baffled at the following:

UNet Function - Tasharen Networking Function
OnStartClient - - maybe OnChannelJoin() ?
ClientRpc - - RFC with a client check?
Command - - maybe RCC?

Your pointers are much appreciated.

Cheers,
Matt.

3

TNet 3 Support / Migrating from UNet to TNet: What's involved?

« on: November 12, 2016, 04:14:01 AM »

Greetings,

I'm using a third party asset from Opsive called the Third Person Controller and it has networking functionality such as an authoritative server that utilizes the default UNet stack. However, the problem is that UNet has a bug in it's Network Animator that stops characters from working correctly if I start a Network Server in LAN/Dedicated Mode as I want to be able to have a server running and not have to have a "player object" taking up room on the server slots. After research and hair pulling, I put the cards on the table and remembered I had a license of TNet I could use.

From what I see in the Third Person Controller's networking side of things, it uses a fair amount of UNet RPCs such as [Command] and [ClientRpc]. Most objects that need to be sent over the network have NetworkIdentities and NetworkTransform scripts attached to them, etc.

I know I'm possibly looking at a lot of code refactoring, but if UNet is going to give me pain I'd rather have TNet handling the network side of my game. Perhaps has someone already written a wrapper for this kit? Is it worth pursuing or should I just keep using UNet since the third party asset already has it working out of the box?

4

TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans

« on: March 05, 2015, 07:16:04 PM »

Just took a look at the SyncRigidbody script and saw the Sync RFC and how it's called. There's cached values that are updated every time we broadcast the update to the network (and there's a change?). With that said, we don't broadcast if we're not the player object... Am I mistaken or is that what I'd need to do?

5

TNet 3 Support / Re: TNET on PS4?

« on: March 05, 2015, 07:11:57 PM »

I thought for some consoles you had to go through the companies' servers. I think this was the case for Nintendo WFC back in the day, you had to use Nintendo's servers or it wouldn't allow you to connect for some silly reason.

Maybe you could do a check to see if UPnP is available, and then go from there.

6

TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans

« on: March 05, 2015, 01:36:12 AM »

Alright, that's good. We're now designing our network player logic, and we've started making a NetPlayer class. The major things we need to relay over the network are 3 vectors: one for the root position, one for the movement vector and the aim point (which is for the non-player controlled objects to look at). A quaternion is also used for the rotation of the character. The rest are just for animation control, if we're crouched the animations need to be playing the crouched set, etc.

To sync this across the network, can we use a TNSyncObject script, or do we have to create our own Sync script?

Here's the code that we've prototyped to some extent:

1. // snip //     
2.         private Vector3 rootPos;
3.         private Vector3 moveVec;
4.         private Vector3 aimPos;
5.         private Quaternion rootRotation;
6.        
7. // snip //
8.  
9.         public Vector3 RootPos{
10.                 get{
11.                         return rootPos;
12.                 }
13.                 set{
14.                         rootPos = value;
15.                 }
16.         }
17.        
18.         public Vector3 MoveVec{
19.                 get{
20.                         return moveVec;
21.                 }
22.                 set{
23.                         moveVec = value;
24.                 }
25.         }
26.        
27.         public Vector3 AimPos{
28.                 get{
29.                         return aimPos;
30.                 }
31.                 set{
32.                         aimPos = value;
33.                 }
34.         }
35.        
36.         public Quaternion RootRotation{
37.                 get{
38.                         return rootRotation;
39.                 }
40.                 set{
41.                         rootRotation = value;
42.                 }
43.         }
44.  
45. }
46.  

For non-player controlled entities, each client would get the values and update things accordingly. On player controlled entities, we'd be sending updates to those values when they change.

If I recall correctly, using Unity's built-in network, there was a function called OnNetworkSync() that was exposed when you attached a object with a network view.
Could you please advise on the best approach in this situation, and if you could provide any snippets of code, that would be helpful. Thanks!

7

TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans

« on: February 25, 2015, 08:35:15 PM »

With the ping that can be accessed via TNManager.player.ping, is this the current ping or an average? If it's an average, what is the sample rate? How many times a second are we picking up the ping value? I took a look through the code and saw how it does the periodic pings to the server, but not sure how many pings per second it does.

8

TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans

« on: February 18, 2015, 02:32:05 AM »

TNObjects are scripts, they shouldn't be static. However an object you have it on can have a static reference you can access. For example in Windward I have a "GameConfig" class that has a "static GameConfig instance;" -- when I need to send something to the config's TNObject, I just do GameConfig.instance.tno.Send(...);

Ah, that sounds the way it should be done. Thanks for the tip.

9

TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans

« on: February 17, 2015, 08:08:47 PM »

Hmm... Working on a chat script for my shooter, and I need to make a static reference to the TNObject. However it seems the TNBehaviour tno object is not static:

1. An object reference is required for the non-static field, method, or property 'TNBehaviour.tno.get'
2.  

To counter this, I make a static TNObject to in the class, but does TNBehaviour have no static TNObject reference?

10

TNet 3 Support / Re: OnNetworkJoinChannel is broadcasted after a JoinRandomChannel?

« on: February 17, 2015, 08:05:11 PM »

1) OnNetworkJoinChannel is announced anytime when a client joins a channel, including yourself (ie. the server instance joins a channel).
2) Not sure. Try it and see! 

11

TNet 3 Support / Re: Is TNet for me...

« on: February 17, 2015, 08:00:04 PM »

I would say, judging from the developer, Windward is one of the flagship games that he promotes TNet with. I'd say that he's is possibly one of the friendliest developers out there, helpful even if I ask dumb questions that he could just do a one-liner "RTFM" (trust me, been there done that).

TNet possibly would suit the bill for MMOs, because you can use it to be Peer to Peer. For example, I'm using TNet in my shooter project for clients to be saying "Hey, I'm here, here and here" which the server is just going "Okay, passing the packet to the others" rather than have the server do a simulation and have the client be a dumb terminal (as in, it feeds the server's player entity the values and "shows" the end result). For attacking and other things like explosions, on the server I'm planning to keep a X number of timestamps where everyone was, so when the player shoots, it goes "Hey server, I'm timestamp blah, I think I hit someone, can you check". Server then rolls back the clock and says "Yep, hit confirmed" or "Nope, missed". Ultimately, the server is a client, but it's running the combat logic.

There's other third party solutions out there, like Photon and SmartFox, but they are expensive subscription based or user based and have limits on how many messages (packets?) can be passed through at any given second. TNet is just a base model - the internals of a car - and it's up to you to mold your system on top of it.

To lock down TNet, just change the protocol ID in the code to something else. That way people can't just pull up Unity and a copy of TNet, guess your master server IP and go from there. TNet will stop connections with an error if protocol IDs mismatch (the TNServer will throw a "X has failed the verification step" message in console). You may also consider adding your own code (maybe magic packet that you must send to say you're X game client?) to detect people trying to spoil the party and break things.

12

TNet 3 Support / Re: TNet can't work on unity 4.6.2p2

« on: February 15, 2015, 11:51:54 PM »

IL2CPP seems to be beta-quality and only for iOS targets, so you can disable it if you're not going to use it. Alternatively, you can roll back to 4.6.1f1 (that's what I'm using) and have no issues.

13

TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans

« on: February 15, 2015, 04:39:40 PM »

There is no particular reason for it... just how I chose to do it early on. It's basically a "list of other players", since you always know that you are present.

playerDataNode is a DataNode, which is much more than a dictionary. It's a tree-like structure. Think of it as an XML tree. Each node can have children. Each of those children can have children of their own, etc.

player.playerDataNode should only be read-only. Only the player who owns it should be able to change its contents. Otherwise you get into hairy situations where one client changes something, then another client does a similar operation at the same time, and then one overwrites the other. Like a thread race condition, only online.

Alright, so I can use it to store loadout data and other stuff related to the player. Great as this saves me having to compress the load out data into a string and then parse it.

14

TNet 3 Support / Re: TNet: Lag Emulation, Kicks and Bans

« on: February 15, 2015, 02:56:22 AM »

Player limits are handled by the server. All players in the channel count toward this value, host included. So if your limit is 16 and a host joins, you have 15 slots remaining. When checking a list of players on the client side, the list excludes you.

Right. Is there any particular reason why the list excludes the player? (I'll just have to add them into the scoreboard at the bottom of the window).

Lobby server will show 1.

Okay, to counter this I could just take the number and subtract one, so servers are "empty" when it's just the server in there so to speak.

I suggest handling custom versioning yourself if you need it. For example in Windward I check what mods the player has active and match it against the mods that the previous player set. If an updated version is detected, the list of mods gets updated (Each mod has its own version number). If the previous player sent that mod-setting RFC with a newer version of the mod, the player gets disconnected with an error message.

Ah, ok. Understandable.

I have a question about playerData and playerDataNode. From what I can see in the code, it's a string I can set. Is playerDataNode like a dictionary of sorts that I could use to store the players weapon loadout? For example: player.playerDataNode['weapSlot1'] = "m4a1", player.playerDataNode['weapSlot2'] = "pistol", etc. This is only on the client side, and can't be edited on the server gathering from what I have read from other topics?

15

TNet 3 Support / Re: Movement Question

« on: February 12, 2015, 07:29:23 PM »

As i stated my character dosent currently have a rigidbody but a character controller, Does this mean you have to have a rigidbody for this to work? If not how would it be done without one?

If you're using a character controller with a rigidbody sync script, then it will fail, because it cannot reference the rigidbody to sync over the network.
CharacterControllers are easier to sync.

What you might want to do is look at the rigidbody "lag" script that ships with TNet. That should give you an understanding with smooth(er) movement, but ultimately you'll need to decide what you want to do. In my shooter project, we use a character controller for players. We'll work out a smooth movement system once it all works, one idea is to get the player's ping and smoothly lerp the offset the renderer (graphics) part of the gameobject forward/behind the actual position of the character controller, thus if jitter does happen, the lerp will "smooth" it out so to speak.