Messages

226

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

« on: June 28, 2016, 09:26:59 PM »

Just join 127.0.0.1. You can get the port from TNServerInstance.listeningPort.

227

TNet 3 Support / Re: Tnet 3.0 about AntiCheating?

« on: June 19, 2016, 04:43:31 AM »

There is an anti-cheat toolkit on the asset store you can use that helps. It'll prevent CheatEngine from modifying the values, but you really can't stop dedicated cheaters. Ideally the anti-cheating code should be yours. Generic ones are much easier to circumvent as doing it once means the same method can be applied for every app using the method.

I wish people would stop talking about that "anticheat". It takes about 5 seconds to *disable*; it's a complete joke. No heartbeat and resides in CLR environment...

but, can player add yourself to ban list?
I think it best, If player сhange the value to unacceptable changes - he, automatically, go to ban yourself?
I cant find: how add to ban list somebody?

Players can ban themselves if you set the server option "playersCanBan". This only enables them to ban themselves, not others. Admins can still ban others.
Use TNManager.SetServerOption("playersCanBan", true) when the first player connects, or add it to mData on the GameServer when it starts up.

228

TNet 3 Support / Re: Unable to Connect.

« on: June 19, 2016, 04:34:18 AM »

Your router doesn't support hairpinning. This is perfectly normal. If you're connecting to a device on your local network (including your own PC) use the local address, otherwise use the public address.

229

TNet 3 Support / Re: IPv6 support?

« on: June 12, 2016, 10:19:29 PM »

I need to study OS level networking again, but couldn't you bind two TCPListener's to the same port? If they're listening on different local addresses (IPAddress.Any, IPAddress.IPv6Any) there shouldn't be issues, right?

Supporting one or the other means a fraction of players won't be able to host / connect, even with ISP's supporting dual stack.

Anyway, I guess it isn't a big deal, thanks for confirming it's a problem with TNet and not on my end.

230

TNet 3 Support / Re: SetHost() switches to their server instance?

« on: June 11, 2016, 09:55:38 PM »

That function isn't in TNet2, so I can't answer definitively. If I were to guess, I'd say that you're right, you have to be in a channel to use it.

If you're trying to get channel values from the game server to display on the lobby server list, refer to ThreadFunction() in TNTcpLobbyLink.cs (assuming you're using TCP). At the bottom of this function you'll see a BinaryWriter being instantiated and a bunch of values being written. You can add something like:

1. lock (mGameServer.mLock)
2. {
3.     writer.Write(mGameServer.mChannels[0].playerLimit);
4.     // any other channel data
5. }
6.  

Then in TNServerList.cs you'll have to modify the Entry class's ReadFrom and WriteTo functions to include your newly written values.

Note: given code is only an example and isn't very safe.

231

TNet 3 Support / Re: SetHost() switches to their server instance?

« on: June 11, 2016, 01:20:32 PM »

Host isn't actually who's hosting the server instance, it's more like "channel operator". The first player to join the channel is designated the host. There's a few ways to migrate from one server to another. You could have the current server send out an RFC designating which player is to start up the new server instance right before shutting down, but that wouldn't work if the current server host crashes, only if they gracefully exit. This is an easier problem to solve when it's fully p2p. Unfortunately TNet is not :p
Here's what I'd try doing (it's no small feat):
* Lobby Server keeps track of players connected to each registered game server
* When Lobby Server detects that a game server shuts down with players still connected:
    * Run some logic to determine which player should be the new server (ping-based, or entirely random)
    * Send packet to that player notifying them to start up the server instance
    * Wait until the new server instance from that player is registered
    * Send packet to every other player that was on the original game server, notifying them of the new server instance
* Other players receive the packet notifying them of the new server instance and connect as usual

As for your other question, you'd need to take a look at TNLobbyLink.cs, TNLobbyServer.cs, TNLobbyClient.cs, and TNServerList.cs
You're correct, you'd need to send the channel info from the game server to the lobby server and parse that on the lobby client.

232

TNet 3 Support / Re: IPv6 support?

« on: June 10, 2016, 06:26:48 PM »

Finally got a chance to test it out.
Testing with TNTcpLobbyServer,

1. mListener = new TcpListener(IPAddress.IPv6Any, listenPort);
2.  

will only accept IPv6 addresses. Project is built using .NET Framework 3.5 (standalone, not Unity) on Windows 10. Similarly, IPAddress.Any will only accept IPv4 addresses.
Tested with online port scanners:
IPv6: http://www.ipv6scanner.com/cgi-bin/main.py
IPv4: http://www.canyouseeme.org/
If the listener accepted both IPv4 and IPv6, both port scanners should report a success; however, only the IPv6 scanner will report a success. Encourage use of Wireshark to verify the incoming connection is IPv6 or IPv4.

Additionally, with the changes made to TNTools.cs, localAddresses returns a bunch of invalid IPv6 addresses (Teredo Tunneling Pseudo-Interface, Temporary IPv6 Address, and Link-local IPv6 Address). This messes up local connections as localAddress will often return one of the invalid addresses. This much, at least, should be an easy fix.

233

TNet 3 Support / Re: IPv6 support?

« on: June 07, 2016, 06:18:43 PM »

So, bad news, mSocket.SetSocketOption(SocketOptionLevel.IPv6, (SocketOptionName)27, false); throws an exception because the specified SocketOptionName isn't found. So that means you'd have to have two sockets (and TcpListeners): one for ipv4 and one for ipv6. Right?

234

TNet 3 Support / Re: IPv6 support?

« on: June 06, 2016, 11:31:03 PM »

Oh, I see I did. I don't have the ability to test, so this is needlessly hard. Additional changes:
TcpProtocol::ConnectToTcpEndPoint():
Change:

1. mSocket = new Socket(tcpEndPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
2.  

To:

1. mSocket = new Socket(tcpEndPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
2. if (tcpEndPoint.AddressFamily == AddressFamily.InterNetworkV6)
3.         mSocket.SetSocketOption(SocketOptionLevel.IPv6, (SocketOptionName)27, 0);
4.  

GameServer::Start():
Change:

1. mListener = new TcpListener(IPAddress.Any, tcpPort);
2.  

To:

1. mListener = new TcpListener(IPAddress.IPv6Any, tcpPort);
2. mListener.Server.SetSocketOption(SocketOptionLevel.IPv6, (SocketOptionName)27, false);
3.  

TcpLobbyServer::Start():
Change:

1. mListener = new TcpListener(IPAddress.Any, tcpPort);
2.  

To:

1. mListener = new TcpListener(IPAddress.IPv6Any, listenPort);
2. mListener.Server.SetSocketOption(SocketOptionLevel.IPv6, (SocketOptionName)27, false);
3.  

Are there more changes I'm missing? Specifically for TCP, as I'm not worried about UDP. I'm a little wary that SocketOptionName.IPv6Only doesn't exist. I think mono supports it though. If not, then it seems you'd have to create two TcpListener's instead of one.

I'd love to sink my teeth into TNet3, but I'm not ready for the transition yet. Thanks though.

235

TNet 3 Support / IPv6 support?

« on: June 05, 2016, 08:13:09 PM »

TNet had issue with parsing IPv6 addresses in the past (see: http://www.tasharen.com/forum/index.php?topic=13794). However, even with the parsing fixed - in TNet2 - Sockets are created with AddressFamily.InterNetwork (see TcpProtocol::ConnectToTcpEndPoint()), which, as far as I can tell, only supports IPv4. In .NET 4.5 Sockets support dual mode, but I don't think Unity has caught up to that yet.

If I change AddressFamily.InterNetwork to tcpEndPoint.AddressFamily, will this introduce incompatibilities? Has IPv6 support been more thoroughly planned out in TNet3?

I know this is something I could test myself, but I thought I might check here before potentially breaking the whole game


edit: Here's all the changes I've made in TNet2. I think this should solve IPv6 problems when using TCP. Not sure though. The Lobby code (client and server) should be fine already.
TNManager::Connect (string address) [full function]:

1. string parsedAddress = address;
2. string[] split = address.Split(new char[] { ':' });
3. int port = 5127;
4. if (split.Length == 2)
5. {
6.    int.TryParse(split[1], out port);
7. }
8. else if (split.Length == 9)
9. {
10.    parsedAddress = address.Substring(0, address.Length - split[8].Length - 1);
11.    int.TryParse(split[8], out port);
12. }
13. Connect(parsedAddress, port);
14.  

TcpProtocol::ConnectToTcpEndPoint():
Change:

1. mSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
2.  

To:

1. mSocket = new Socket(tcpEndPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
2. if (tcpEndPoint.AddressFamily == AddressFamily.InterNetworkV6)
3.         mSocket.SetSocketOption(SocketOptionLevel.IPv6, (SocketOptionName)27, 0);
4.  

TNTools.cs -
Tools::ResolveExternalIP (string url):
Change:

1. string[] split1 = text.Split(':');
2.  
3. if (split1.Length >= 2)
4. {
5.    string[] split2 = split1[1].Trim().Split('<');
6.    mExternalAddress = ResolveAddress(split2[0]);
7. }
8. else mExternalAddress = ResolveAddress(text);
9.  

To:

1. mExternalAddress = ResolveAddress(text);
2.  

Tools::IsValidAddress (IPAddress address):
Change:

1. if (address.AddressFamily != AddressFamily.InterNetwork) return false;
2.  

To:

1. if ((address.AddressFamily != AddressFamily.InterNetwork) && (address.AddressFamily != AddressFamily.InterNetworkV6)) return false;
2.  

Tools::ResolveEndPoint (string address):
Change:

1. if (split.Length > 1)
2. {
3.    address = split[0];
4.    int.TryParse(split[1], out port);
5. }
6.  

To:

1. if (split.Length == 2)
2. {
3.    address = split[0];
4.    int.TryParse(split[1], out port);
5. }
6. else if (split.Length == 9)
7. {
8.    address = address.Substring(0, address.Length - split[8].Length - 1);
9.    int.TryParse(split[8], out port);
10. }
11.  

Sorry for ugly formatting. I tried

236

TNet 3 Support / Re: Best practice question

« on: June 04, 2016, 02:02:26 PM »

I'll try my best to answer your questions:
1. Players are part of a channel. Channels contain a list of SavedRFCs (and SavedObjects). So when you send an RFC with XXXSaved this RFC is simply added to that player's channel's list of SavedRFCs (as seen in TNGameServer::ProcessForwardPacket(...)). When the server is shut down it calls TNGameServer::SaveTo(...) which iterates over all channels on the server, and, if the channel is marked as persistent, saves all RFCs and Objects to a file. Note that this save routine is also called every 2 minutes. When the server is started back up again, it simply reads and loads the file.

2. Yes, and you'd have the TNServerInstance hooked up to a remote lobby server somewhere, so other players can see it. This lobby server would be hosted by you, but the actual game server would be hosted by your players (in your scenario). If you want the host to control AI and spawning, just check TNManager.isHosting in your AI / spawn functions.

3. You're saying you want each player to store their statistics locally (such as their level, rank, inventory, whatever)? You'd have to add some custom logic for this, as by default the data is stored and loaded by the server. Perhaps you can have each player save their stats to a file locally, then whenever they join a channel have them forward the contents of this file to every player in the channel (Target.OthersSaved). There's lots of ways to deal with this, entirely dependent on your design / needs.

4. I don't have any experience with local split-screen. tno.isMine will always return true or false. Uhh, hmm, I might set up a custom object creation function that determines if it's a local player, and, if so, which local player, then save this to a variable in your Player script. Then check that where ever you'd check for tno.isMine (in addition to, not instead of). Another approach could be having a static LocalToNetManager that's passed inputs from each local player (again, with an ID) and forwards these via RFC. This approach might be easier, I think you could use tno.uid (which is handled by TNet when instantiating) instead of having to set a custom ID for local players.

5. I think there's some confusion here. If you're using the AutoSync script, there's no need to sync inputs, or vice versa. To answer your question though, you can send input updates very frequently, but be sure to test it thoroughly before release (there is such a thing as too much). Also, if you're syncing inputs, I wouldn't be syncing the transform very often at all. Maybe once every 5 seconds or so, just to correct any drift from missed packets.

edit: Yeah, 30 seconds was a silly suggestion. Changed to 5.

237

TNet 3 Support / Re: Setting up controller script for Mecanim syncing

« on: June 02, 2016, 05:14:27 PM »

Thanks Aren....

I understand the syncing input. The problem is now deriving the thridpersonanimator from TNBehaviour... It faces the same issue as the thirdpersoncontroller.... Might I also mention , both thirdpersonanimator and thirdpersoncontroller are within a namespace ..... Could this be why I cannot derive them from TNBehaviour?

Both scripts have this format...

1. using UnityEngine;
2. using System.Collections;
3. using TNet;
4.  
5. namespace Invector
6. {
7.        
8.         public abstract class ThirdPersonAnimator : ThirdPersonMotor ///changing this to TNBehavour throws errors
9.     {
10. ///////stufff goes here////
11. }
12. }
13.  

C# doesn't support multiple inheritance. You can, however, inherit from one base class and multiple interfaces. What Aren was getting at is you'd traverse downwards until you find the root base class and derive from TNBehaviour there. Though, that might not be best practice. I'd go with the original suggestion of using GetComponent<TNObject>().
Or have your network syncing logic be a completely separate script attached to the gameobject (remember: Unity is built to encourage the component paradigm).

238

TNet 3 Support / Re: Tnet 3.0 How work [RFC] for specific player?

« on: May 29, 2016, 11:13:27 PM »

tno.DestroySelf() will destroy the gameObject containing the TNObject component. This is also done on every other client as well (the destroy message is propagated through the network).
Since it destroys the gameObject, you're probably seeing a race condition between the destroy and those next two lines of code. Try updating your statistics before calling tno.DestroySelf().

If your problem is that your statistics aren't syncing and you'd like them to be synced, then consider using TNManager.SetPlayerData(...).

239

TNet 3 Support / Re: il2cpp error on Disconnect

« on: May 29, 2016, 06:29:03 PM »

If you press Ctrl+F while Visual Studio (or whatever IDE you use) has focus, it'll bring up a search button. You can adjust the search options to search through the entire solution. From there, the search term I chose was ".Abort();". I came up with 4 results:
TNTcpLobbyServer.cs - Stop() function
TNUPnP.cs - Close() function
TNGameServer.cs - Stop() function
TNUdpLobbyServer.cs - Stop() function

240

TNet 3 Support / Re: Sync player states and animations

« on: May 27, 2016, 01:30:21 PM »

1. public class NetworkManager
2. {
3.     public const byte NETID_SYNC_INPUT = 1;
4. }
5.  

Just makes it easier to maintain / read.