Messages

211

TNet 3 Support / Re: Drop-in coop party setup screen/waiting area

« on: July 27, 2016, 03:31:12 PM »

Isn't that what you want?

Move (or point) the camera (and other objects from channel 1) waaaay off-world to hide the objects from channel 2.

212

TNet 3 Support / Re: Best way to set Transform ref

« on: July 27, 2016, 03:21:18 PM »

Maybe I'm missing something in your explanation, but wouldn't it be easier to sync the rotation of the board? You could even optimize it a lot because you said it rotates at fixed angles, meaning there's finite possibilities (if it's under 255 possibilities that's 1 byte per rotate instead of 4 or 12).

If what you want is to sync the movement of the cursor as well, then treat that just as you would the board. Don't try sending the logic over the network, just send the outcome (position and rotation).

I don't know how familiar you are with TNet, so I'll go more in-depth (you can ignore this if you're already familiar):
1. Create a board prefab
2. Create a cursor prefab
3. On both prefabs, add the TNAutoSync component and click the "Add a new synchronized property" button twice. This should add its transform twice, with a box to the right containing <None>. Click that box and select position for the first one and rotation for the second one.

Now whenever you instantiate those prefabs (using TNManager), their positions and rotations will be synced across the network. You can take a look at how the TNAutoSync script works and build your own syncing script.

213

TNet 3 Support / Re: Testing IPv6 on iOS

« on: July 27, 2016, 03:01:37 PM »

161.202.144.242 is not an IPv6 address.

Make sure the client socket is IPv6.

214

TNet 3 Support / Re: Host is the authority?

« on: July 26, 2016, 07:59:01 PM »

That's one way of doing it, sure. I'd probably just run the hit detection on the host, though.

At some point, due to the way TNet works, you're going to have to give up security. Unless you rewrite the server to be a headless (-batchmode) Unity player, which is what I did, you're not going to have a 100% secure game.

With that in mind, the best advice to give is "do what feels natural and is easiest to work with". Aren always tells people to worry about cheaters when they come, and while I certainly wouldn't recommend doing that, it is worth knowing that other security options exist.

You can modify mono.dll to only load your files, you can obfuscate your code, encrypt your assemblies (modify mono to decrypt upon load), and pack mono.dll. Calculate checksums on all your files and verify that they match. With these changes in place you (almost) prevent 1. injecting assemblies into mono environment at runtime 2. modification of your assemblies. This would deter the vast majority of cheaters as most cheats for Unity games rely on mono injection or reflexIL (or mono.cecil, same effect).
At that point I'd probably start attacking the network communication, so it'd be worth encrypting all your packets and preferring TCP over UDP (hard to spoof those seq#).
Absolutely do not use that terrible "anti-cheat" asset for Unity that everyone uses. IT DOES NOTHING. It does less than nothing! Even if you obfuscate it, I'm going to be able to find it and disable it completely with minimal effort.

You can have the player send their ping to Target.All every X seconds (TNet3 might have this built in?). As for changing host, maybe only do that if the current host's ping is above a static limit? I guess, technically, the best choice for host would always be the client with the lowest ping to the server, since all packets must travel through the server anyway.

215

TNet 3 Support / Re: Does host own all objects in scene?

« on: July 20, 2016, 08:23:49 AM »

Yes, see step 6 in the joining process (TcpPlayer::FinishJoiningChannel()). If an object's owner isn't present, the object's owner is set to the host. If no players are present when you join the channel then you are the host (step 3). Additionally, when a persistent object is created by a player and that player leaves, ownership of the object is transferred to the host.

216

TNet 3 Support / Re: how to make a login system ?

« on: July 19, 2016, 07:16:02 AM »

Well, it's important that you're doing the encryption (and hashing!) serverside as well, and keeping it serverside. TNManager doesn't exist on the server so I'm a little concerned.

Anyway, you could add a string emailAddress to the TNPlayer.cs file (on the server). Then in TNGameServer.cs where you should be handling the registration / login you could just set that property on the player. Now wherever you want to check if an email is in use, you can just iterate over mPlayers and compare the emailAddress property. If you find a match then that email address is logged in elsewhere. If not, then you're good to go. mPlayers contains every player connected to the server, including those in other channels.

Again, this all exists strictly on the server. I wouldn't be storing encrypted passwords, either, btw. Hash the password clientside, encrypt the payload, send to server. Server decrypts the payload, then generates a random salt, hashes the hash with the salt, stores the hashed hash w/ the random salt. Use a secure encryption method (AES), and a secure hashing method (md5, sha256). Generating the salt should be using a random seed as well, and the hash should be hashed multiple times serverside before being stored (just in case).

217

TNet 3 Support / Re: DataNode DateTime

« on: July 19, 2016, 06:59:02 AM »

Are you sure it's not being parsed properly? Strange that you'd see System.DateTime if it weren't being parsed. Maybe it's sending the typename as a string.

Anyway, you could store / send it as a long instead: DateTime.UtcNow.Ticks. To reconstruct, use DateTime dt = new DateTime(value, DateTimeKind.Utc).
You could add this to TNSerializer.cs to automate the process. Might also need to add it to the DataNode class, not sure.

218

TNet 3 Support / Re: how to make a login system ?

« on: July 18, 2016, 08:02:04 AM »

I wouldn't make players email addresses visible to other players. There could be some privacy / security concerns in doing that.

I think what you're looking for is session management. TCP already does this, so why not identify players by their socket? But, if you really want to keep track of which email addresses are currently logged in, why not keep a server-side List<string> that's added to when a user logs in (and removed from when they log out)? Very, very important that it's server-side only. I'd suggest a full security audit before releasing your game, just in case. Users like to use the same email and password on multiple services, so you've got to handle sensitive information like that with great care, even if it is just a video game

219

TNet 3 Support / Re: Tutorial suggestion : working with servers and channels

« on: July 15, 2016, 04:08:34 AM »

You have the source code to TNet. You are compiling it yourself, so it works. You have Unity which comes with: exception handling and reporting (when an exception occurs it will be printed to the output window, and usually won't crash the game), profiler, and debugger. You can literally step through every CIL instruction as your game executes. You've spent two weeks fighting TNet? I don't believe you're trying hard enough, then. If you had bothered to look through the source code you could solve your problems in no time at all. Sure, Aren could noob-ify the entire TNet library and practically spoonfeed all his customers, but then people like me that use TNet as a tool instead of a full-fledged solution become inconveniced by how much unnecessary code we'd have to dig through. Perhaps that's something Aren does want to do, and I certainly can't blame him, as there seems to be a lot more noob coders than real programmers in the Unity ecosystem.

Now, I don't have TNet3 yet, so I won't be able to provide the spoon you so desire, but I'll help with what I can:
127.0.0.1 is localhost, if you send a packet to 127.0.0.1 it will never leave your motherboard. Stays within the OS. If you're hosting a server on your PC you should always connect to localhost. This isn't specific to TNet. This is networking in general.

The server writes to a few files: server.dat (or world.dat, whatever you name it), server.config (or world.config) Config/ban.txt, and Config/admin.txt. You can see this in TNGameServer::SaveTo(string fileName). I can't see an instance where the *.dat file would be written if NONE of your channels are persistent. In fact, it should be deleted. So, check that NONE of your channels are persistent, and then read the error message and stack trace if it's still failing.

You're going to need to provide more information about your RFC issue. Error messages, stack traces, code snippets. The presence (or lack) of *.dat shouldn't effect RFCs.

I'm not sure I understand what you're saying about your password test. I think you're saying you can host and connect on Android devices, but if you host on Unity editor you can't connect on Android devices. I would test the connection. Are you forwarding the ports? I would recommend not running the server within the Unity editor. Instead you should build and run, or run the standalone server. I believe you'd have to allow Unity editor through your firewall if you wish to connect to it from other devices.

A frontend should be made by the game developer... Imagine if every game had the same frontend. How crappy would that be?

No, it isn't too much to ask for a walkthrough covering the creation of a mobile networked game. It is however too much to ask for a complete spoonfed game "example".

At some point you're going to have to take a step back and decide whether you should be blaming TNet or yourself. You literally have the full, HEAVILY COMMENTED source code... Lacking experience in programming or networking is no excuse and should only motivate you to LEARN like everyone else has.

Sorry for the harsh tone, I've spent 4 days back in the unmanaged environment. Spent 31 straight hours debugging machine code. The managed environment gives you sooo much freedom, so it's agitating to hear people complaining about simple stuff.

220

TNet 3 Support / Re: NAT Punch Through / TNet Online Play

« on: July 04, 2016, 10:54:13 PM »

TCP punch through is a thing as well. It's slightly more complicated than UDP punch through, but entirely possible. IPv6 should remove the need for NAT, but IPv6 isn't fully rolled out yet, so some players are stuck with IPv4.

I think the idea TomD and I share is TCP hole punching would act as a failsafe for UPnP. Often UPnP fails (I've never had the UPnP part of TNet report a success) for users, and, being users, they are often too inexperienced / inconvenienced to open the port on their router manually. Hole punching would, in theory, eliminate that problem. I don't have a server or a second LAN to test on, so unfortunately I can't test this theory. I believe it would require 3 sockets all bound to the same port. Socket #1 connects to the facilitator, Socket #2 accepts connections (as the TcpProtocol class currently does), and Socket #3 would be used for sending the SYN packet. You can find a PoC in C# on github doing something similar, so it's definitely possible. However, that PoC is primarily for connecting two peers. In TNet's case, we need to connect multiple clients to a single server, so might need to adapt it.

It's an interesting problem to solve, and making port-forwarding a thing of the past would be beneficial to everyone.

221

TNet 3 Support / Re: NAT Punch Through / TNet Online Play

« on: July 03, 2016, 09:54:53 PM »

I'm interested in this as well.

Have you tried opening the port in Windows firewall (and any other application-based firewall), but NOT opening it on the router (letting upnp do that for you)?

If that works, then I think there's a way to programmatically add a rule to Windows firewall which should solve the issue.

222

TNet 3 Support / Re: Stopping a server seems to 'lock' its port.

« on: July 01, 2016, 08:58:12 AM »

How are you stopping the server?
Should be TNServerInstance.Stop().

Actually, that shouldn't even be causing your problem. The lobbylink uses mGameServer.tcpPort when it adds itself to the lobby server, and mGameServer.tcpPort should never be 0 unless mGameServer.Stop() is called in the span of microseconds. I can't find any cases where you wouldn't be getting an error printed to console though, so check that.

I'm stumped, hopefully Aren or someone else will be able to help.

223

TNet 3 Support / Re: Stopping a server seems to 'lock' its port.

« on: July 01, 2016, 06:42:28 AM »

I'm not sure how you're even able to connect with that code. Must be some considerable changes to TNManager in TNet3.
Regardless, I looked over the patch notes and it seems TNServerInstance still exists in TNet3, so you should use that if you want your clients to host servers.

Creating a server:
TNServerInstance.Start(5127);

Joining the server on the client that called TNServerInstance.Start:
while(!TNServerInstance.isListening) yield return null; // (or some other garbage code, just need to wait for TNServerInstance to initialize)
TNManager.Connect("127.0.0.1", 5127);

Stopping the server:
TNServerInstance.Stop();

Joining the server from the serverlist:
What you have works, though you're passing ent.internalAddress for both parameters (not an issue if every client is on the same LAN).

224

TNet 3 Support / Re: How to get server name?

« on: June 29, 2016, 07:32:02 PM »

If you're hosting the server through TNServerInstance:
TNServerInstance.serverName

If you're just a client:
The name is sent when you retrieve the list of channels. So just save it to a variable from there. Otherwise, you could add a custom packet to get the name from the server at any point.
But, for debugging, the IPEndPoint of the server should probably suffice, right? You can get that from TNManager.tcpEndPoint.

225

TNet 3 Support / Re: Use a password?

« on: June 29, 2016, 07:19:36 PM »

Add the following to the top of your source file:

1. using System.Net;
2. using System.IO;
3.