Messages

31

TNet 3 Support / Re: Objects Instantiate with No Owner

« on: November 06, 2017, 01:37:19 AM »

RCCs (and RFCs) must be within a class that derives from MonoBehaviour. TNet uses reflection to cache all RCCs at startup. This reflection process first gets all Type's from all Assemblies in the current AppDomain (excluding some built-in ones). Then it narrows this further by checking if the Type derives from MonoBehaviour. Then it checks if the Type has the RCC attribute, whether the return type is GameObject, and if the optional RCC ID is within 1-255.

RFCs are cached similarly, except this is done on each TNObject instance, and instead of getting all Type's from all Assemblies, it simply calls GetComponentsInChildren. You probably didn't notice this because TNObject itself is a MonoBehaviour.

It doesn't look like this is mentioned in the tutorials on google docs, but I believe I made a post about it some time ago. Intuitively, though, you wouldn't have an RCC on a non-MonoBehaviour class because you wouldn't instantiate a non-MonoBehaviour class using Unity's Instantiate function and the RCC return type must be a GameObject.

And just to avoid any future issues: your custom RCC IDs should be between 4 and 255 as TNManager uses 1-3 for default fallbacks. I don't think many people use the IDs though. Even though it's faster and results in smaller packets

32

TNet 3 Support / Re: Objects Instantiate with No Owner

« on: November 04, 2017, 03:50:06 AM »

What version of TNet? Are you connecting to the same server on both clients? Are you joining the same channel on both clients? Are you sure there isn't some piece of code calling TNManager.Disconnect (or similar) for one client but not the other? Are you switching scenes using TNManager.LoadLevel? Do your networked objects have a TNObject component attached with an ID of 0? Are you instantiating objects via TNManager.Instantiate? What is the minimum set of features you can get working and what are the steps you're taking to achieve that?

Have you tried spamming Debug.Log's everywhere in your code? Could reveal something executing that shouldn't be executing, or some strange parameters, or something else. Usually every Unity dev's last resort

If you can reproduce this in a blank Unity project I could debug it for you, just PM the link and be sure to omit TNet's source code.

33

TNet 3 Support / Re: Several questions after getting basics going

« on: November 02, 2017, 08:14:56 PM »

1. My network knowledge is slipping so quickly - you lose it if you don't use it, etc -  so I'm really fuzzy on this, too. I think most ISPs have some sort of tunneling mechanism for ipv4<->ipv6.

Your idea of using 2 server sockets is something I've thought about, too. I'm not sure if it'd be that easy, though, as I'm sure ArenMook would've done that by now you'd have to modify the client, lobby server, and game server to support this, though. The server would need to supply its ipv4 and ipv6 address and port to the lobby server. The lobby server would need to send this to the clients. The client would need to determine which address family to use and connect to. Then, like you mentioned, state synchronization on the game server might have some challenges.
Or maybe not? The server listens for connections via .NET's TcpListener. When a connection is accepted a TNet TcpPlayer (inherits from TcpProtocol) object is instantiated and handles receiving from that socket. I think TNet's TcpProtocol is IP-agnostic? At least as used by the server. So if you just set up 2 TcpListeners (ipv4 and ipv6) and accept connections from both, you should be able to keep the single list of TcpPlayer's and not have to modify anything else on the game server (except for pushing both ipv4 and ipv6 endpoints to the lobby server).

4. I'd suggest implementing it and seeing if it's an issue first. If it is actually an issue, I dunno. Is it feasible to package & distribute the assets with your game? If not, could you cache them on each client for a long period of time?
Actually, I don't think it's a concern. 100 packets are *processed* each loop. The loop is very fast, and processing is very fast. Outbound packets (responses to processed packets) are placed in a queue. This queue is read from in the OnSend socket async callback thingy, so I don't *think* it impedes the processing thread. So it should be limited by the speed of the server's connection (which is the best case scenario). To summarize: I believe it's possible that the 101st packet could be *processed* even if the response to the 0th packet hasn't been *sent* yet (though such an extreme scenario will probably never happen).

5. I should clarify: UPnP does eliminate the need for holepunching when it works, and TNet attempts to use UPnP by default.

6. Client can only connect to 1 game server.

34

TNet 3 Support / Re: Several questions after getting basics going

« on: October 30, 2017, 06:24:05 PM »

1. Not simultaneously. You can launch the server in ipv6 mode with a commandline argument, otherwise it'll launch in ipv4 mode. Dual-mode sockets are weird. Unity doesn't currently support dual-mode sockets anyway (the socket option doesn't even exist in the runtime).

2. TNet uses TCP by default, so yes. TNObject.SendQuickly uses UDP which doesn't guarantee anything. TCP doesn't retry forever, though. There's a max retry option. I think it's controlled by the OS. You'll never need this.

3. TCP guarantees this. UDP does not. Packets are always processed in the order they're received.

4. No, but the server loop goes like this: pending connections are processed, *all* UDP packets are processed, up to 100 packets from each TCP socket are processed, timed out connections are killed.
If you're getting stuck somewhere I'd look at limiting UDP processing to 100 packets each loop. In 99.99% of cases you won't need to know this loop at all.

5. Presence & game-tracking (if I'm understanding you) is built-in via lobby servers.
TNet doesn't provide NAT traversal. If you need to implement hole-punching I'd suggest modifying the lobby server.
This is only necessary when the *server* is behind NAT though. From everything you've said so far it sounds like you're planning on having your game servers running on actual servers, so this won't be the case.

35

TNet 3 Support / Re: data that all players can access?

« on: October 30, 2017, 05:42:55 PM »

TNManager.SetChannelData could work as well

36

TNet 3 Support / Re: upload image to server

« on: October 28, 2017, 06:54:33 PM »

TNet should support packets up to 16777216 bytes (16 MB).

I'd say it's more likely an issue with the Buffer class not packing the packets properly. I recall there being a bug with Buffer's length or size property back in TNet 2, don't remember if it was officially fixed.

Either way, glad you found a workaround

37

TNet 3 Support / Re: upload image to server

« on: October 22, 2017, 06:38:57 PM »

Which version of TNet? I used your exact code w/ TNet 3.0.9 and received no errors.

38

TNet 3 Support / Re: Shoter on TNET.HELP please!!!

« on: October 20, 2017, 04:05:35 AM »

Uhh, please reply properly instead of reporting the post and typing your response there.

Your response (hidden in report):
"I use Raycast,can you give alternative way how to get,store info about players hit"

Raycasting still works? TNManager.Instantiate simply creates a specified prefab on every client. As long as that prefab responds to your raycasts normally then it'll do so when instantiated via TNet, too. Again, take a few minutes to go through the tutorials and example scenes. It's not hard to get a basic networked FPS prototype up and running with TNet

39

TNet 3 Support / Re: upload image to server

« on: October 20, 2017, 03:56:42 AM »

Awesome, even easier

40

TNet 3 Support / Re: Shoter on TNET.HELP please!!!

« on: October 20, 2017, 03:56:20 AM »

To create a gameobject on each client (eg; a bullet) you'd use TNManager.Instantiate(...).

Consider going through the tutorials: http://www.tasharen.com/forum/index.php?topic=13953.0
And play around with the example scenes that come packaged with TNet. Everything you need to know is already at your fingertips, just need to apply a little effort to grasp it

41

TNet 3 Support / Re: upload image to server

« on: October 19, 2017, 08:09:17 PM »

Custom packet handler and byte array? Add handler on server to save byte array to disk. TNet has built-in serialization for Unity's Texture2D, so you don't even need byte array. It uses Texture2D.EncodeToPNG under the hood.

42

TNet 3 Support / Re: Latency Spikes / Guidance

« on: October 11, 2017, 08:56:37 PM »

Could try disabling Nagle's algorithm. Set TNManager.noDelay to true after connecting to the gameserver.

Most likely this is due to some of your code that's taking too long, though. I'd load up Unity's profiler and see if the lag spikes correspond to a spike in the profiler.
Are you using GameObject.FindXXX or loads of GetComponent<T> or a lot of Instantiate? Particularly in an RFC? Could be a million things, profiler will help narrow it down.

43

TNet 3 Support / Re: Admin folder & server file problem

« on: October 09, 2017, 06:19:16 PM »

The ServerConfig folder will be placed alongside your .exe by default. The -app switch places it in My Documents/<app>.

The admin.txt file is only created when the mAdmin list holds one or more values (same with the bans text file, or any call to SaveList, actually).

When you run the gameserver from within your game using TNServerInstance.Start, your player will automatically be granted admin. However, this does not populate the mAdmin list: it only sets the boolean flag on your player object (done in ProcessPlayerPacket in the if block for VerifyRequestID). But, with this flag set, you can call TNManager.AddAdmin(superSecretPassword) to then populate mAdmin and thus create the file.

44

TNet 3 Support / Re: Network ID Assignment Problem

« on: October 03, 2017, 06:11:39 PM »

You should use network ID of 0 on objects that are instantiated multiple times. This'll tell TNet to generate a unique ID for each instantiation.
You will run into problems with the same ID; RFCs won't know which object they're supposed to execute on.

45

TNet 3 Support / Re: Object ownership

« on: September 22, 2017, 11:07:29 PM »

Looks like 3.1.0 just solved this problem for you:
- NEW: Added the ability to change TNObject.owner at will.
http://www.tasharen.com/forum/index.php?topic=2650.msg67285#msg67285