Messages

1

TNet 3 Support / Re: TNet Dedicated Server

« on: June 15, 2017, 01:27:15 PM »

Hello Entelicon,

Yes, it would work well with a dedicated server/client system. The base system is designed around p2p as each channel on a server has a channel host which manages the RFCs and such. Although the way I did it was I listened for a command argument that triggers the server to be launched and I also listen to a name command which has all the servers info for example: "Sever Name_My Map_GameMode" then I split the name by the character '_' to pull all the info.

So basically:
1) Listen for the command.
2) Launch server.
3) Join channel as host. (Now you have a dedicated host)
4) Set server name
5) GG

Look at this thread for some more info if needed: http://www.tasharen.com/forum/index.php?topic=15313.0

2

TNet 3 Support / Re: RFC Calls in Other Classes

« on: June 13, 2017, 10:43:01 PM »

It works, as long as the script is on the same object as the other script as the RFCs link with the TNObject. So let's say class A has rfc with id 2 and class B calls send on id 2, as long as they are on the same object then it would work. If class A is on Object A and class B is on Object B it won't work.

It's mostly a feature to simplify sending RFCs as you don't have to type the whole method name.

3

TNet 3 Support / Re: Is TNet right for my game (1v1, turn based strategy)?

« on: June 11, 2017, 11:27:48 AM »

Yes, this is do-able in TNet. Just as cmifwdll said you can create a headless unity client, I have done this for my game. I listen for the headless command argument when executing the game then I launch a server with the name being another argument. I contain all server info in my name split by (char)58 so for example: "name (char)58 map (char)58 mode" then when I read from the master server I just split the name and fill in all the details. Now once you have that headless client, there will only be one host. So you can simply do authoritative commands by sending RFC calls to the host and having him handle all the logic and stuff.

4

TNet 3 Support / Re: Odd Issue

« on: June 11, 2017, 11:21:37 AM »

No, and the anticheat toolkit asset is absolutely horrendous and should never be used. Its "injection detection" just scans loaded assemblies and if a name isn't whitelisted the "detection" event is fired. It's possible TNet's RuntimeCode package creates and loads an assembly at runtime, but extremely unlikely. I don't have the package to verify.

Seriously though, that anticheat is a complete joke. A brain-dead paraplegic monkey can completely bypass it several different ways with no risk of detection.

Haha you knew right away. Ya, it has to be something triggering it. Anyways, do you know of any other anti-cheat solutions I could use in Unity? I don't really have the drive to mess around with developing my own anti-cheat solution right now as I will have to learn more about hacks themselves. I will eventually get to it but at the time I am looking for a quick solution.

5

TNet 3 Support / Re: Odd Issue

« on: June 10, 2017, 08:11:33 PM »

Does TNet possibly try to inject a dll or something at runtime when starting or joining a server? Seems like the injection detection was causing this.

6

TNet 3 Support / Re: Odd Issue

« on: June 10, 2017, 08:02:59 PM »

Issue resolved: Anti-cheat is being triggered forcing the game to close but the game just says not responding.

7

TNet 3 Support / Re: Odd Issue

« on: June 10, 2017, 07:40:33 PM »

After reading on the forums I think this may be an issue related to Application.Quit() being called. I will look into my code.

8

TNet 3 Support / Odd Issue

« on: June 10, 2017, 02:50:46 PM »

So I have an issue where hosting a server in the editor works fine even connecting works fine. In the build exe, it makes the exe not respond when hosting and it force closes. If you try connecting from build, it just force closes the exe without a warning. I checked the log files and couldn't find any errors or anything. I am really confused as it seems to only be with this project. All my other projects that use TNet are fine.

Note: the project was converted from using Forge, it's only the hosting part that has an issue right now.

9

TNet 3 Support / Re: Adding Mod Support

« on: December 20, 2016, 10:48:15 PM »

In Windward I simply compiled TNet into a DLL, then included that DLL alongside the modding project. Basically take TNet, take out editor classes, and compile that into a DLL using Visual Studio.

Oh alright, are you fine with the end user having the DLL? Is it possible to make a DLL with only DataNodes and it's dependants?

10

TNet 3 Support / Adding Mod Support

« on: December 17, 2016, 12:56:35 PM »

Hello,

I am currently adding mod support to my game and I have some questions. I am using the extra RuntimeCode asset that comes with TNet to compile C# code at runtime for the scripting part of modding. Now the question is with datanodes, currently our mod system utilizes asset bundles to package assets but datanodes seem to offer a more simplistic system for the modders side. I was wondering how I would package the datanodes in the project without packaging the actual whole TNet as that would redistribute TNet and that is not permitted. Hope the above makes sense and I am looking forward to a reply.

Thanks,
  Sebastian

11

TNet 3 Support / Re: Host Change doesn't go well

« on: November 04, 2016, 10:03:45 PM »

I don't see your JoinChannel call in the code you posted. Make sure you also call it as persistent. By default it isn't.

Yes this was the issue, I changed it to persistent in the join channel call and just had to change some things with some of my scripts then it worked fine. Thank you for your help!

12

TNet 3 Support / Re: Host Change doesn't go well

« on: November 01, 2016, 04:12:44 PM »

I'm surprised the coroutine isn't overflowing the stack from infinite recursion. This *could* be your problem, but not very likely.

I don't have TNet3 so I can't check the params you're passing to TNManager.Instantiate, but make sure the objects are being marked as persistent.
There could be a bug with channels but it's doubtful. Place a Debug.Log n your object's OnDestroy function and examine the call stack.

To be clear (and to summarize for when Aren swoops in) this is what's happening:
1. Two players join
2. The Host begins instantiating network objects from a coroutine
3. The Host leaves
4. Some time later, the player that was previously hosting rejoins
5. The rejoining player does not see all of the network objects that the other player sees.

What happens if you completely restart the game before rejoining?
Also, perhaps you shouldn't instantiate objects in the coroutine? There could be a race condition during the disconnect process. Actually, a modification could solve that:

1. // Spawn Timer
2. IEnumerator spawnObjects(spawnableItem itemToSpawn)
3. {
4.         int lastCount;
5.         // Make Sure Is Host
6.         while ((TNManager.isConnected) && (TNManager.isInChannel) && (TNManager.isHosting))
7.         {
8.                 while (GlobalSettings.currentOptions == null) yield return null;
9.                
10.                 // Spawn Objects
11.                 if ((spawnedObjects[itemToSpawn.objectPath].Count <  itemToSpawn.maxSpawn) && (spawnedObjects[itemToSpawn.objectPath].Count != lastCount))
12.                 {
13.                         lastCount = spawnedObjects[itemToSpawn.objectPath].Count;
14.                         string go = itemToSpawn.objectPath;
15.                         Vector3 spawnPointY = new Vector3(Random.Range(-(worldSize.x/2), (worldSize.x/2)), worldSize.y, Random.Range(-(worldSize.z/2), (worldSize.z/2)));
16.                         RaycastHit hit = new RaycastHit();
17.  
18.                         if (Physics.Raycast(spawnPointY, Vector3.down, out hit))
19.                         {
20.                                 int objID = Random.Range(1, 99999);
21.                                 if (go.Contains("Blob"))
22.                                         TNManager.Instantiate(1, "CreateBlob", go, true, hit.point, transform.rotation, go, objID, true, 1);
23.                                 else
24.                                         TNManager.Instantiate(1, "CreateObject", go, true, hit.point, transform.rotation, go, objID);
25.                         }
26.                 }
27.                 // Timer
28.                 yield return new WaitForSeconds(itemToSpawn.spawnTimerInSeconds);
29.         }
30. }
31.  

The above should only be called once per join per itemToSpawn. The coroutine will stop running if the player is not the host, is not in a channel, OR is not connected.
Additionally, I read somewhere that local variables are persistent throughout the coroutine's lifetime, so I'm assuming int lastCount will function properly.
This should eliminate race conditions and attempts to ensure objects are given enough time to instantiate fully.

Even with all this I don't know what exactly is going wrong. For player B to see the object means it's passed through the server which means it's been saved on the channel. Packets are kept in a queue and processed in order. If a player disconnects the queue is cleared. So when the Instantiate packet comes in it means the player currently exists on the server so it'll properly be assigned an owner. When the player disconnects any persistent object owned by that player is transferred to player[0] (this is done after the disconnecting player is removed from the list, so 0 would be player B in this case). Then the SetHost packet is sent out. Then the ResponsePlayerLeft packet is sent out. In this, every TNObject on every client that's owned by the disconnected player sets its owner to TNManager.hostID (which was set in response to the SetHost packet that preceded this one).
When a player joins, the channel's list of objects is iterated over and each object is created on the connecting client. The only way player B can see an object and player A can't is if player B ignored (or fails to execute) a networked Destroy call or player A ignored (or fails to execute) a networked Instantiate call.

Other than that, the only possible way I can see this happening is if the objects aren't being marked as persistent. Again, check your TNManager.Instantiate call to verify that the persistent flag is true.

Nope no luck unfortunately, all the objects are missing when the guy joins back. This is really odd, its like its not saving the packets.

1. // Spawn Timer
2.     IEnumerator spawnObjects(spawnableItem itemToSpawn)
3.     {
4.         // Make Sure Is Host
5.         while ((TNManager.isConnected) && (TNManager.isHosting))
6.         {
7.             while (GlobalSettings.currentOptions == null) yield return null;
8.  
9.             // Spawn Objects
10.             if((spawnedObjects[itemToSpawn.objectPath].Count < itemToSpawn.maxSpawn))
11.             {
12.                 string go = itemToSpawn.objectPath;
13.                 Vector3 spawnPointY = new Vector3(Random.Range(-(worldSize.x/2), (worldSize.x/2)), worldSize.y, Random.Range(-(worldSize.z/2), (worldSize.z/2)));
14.                 RaycastHit hit = new RaycastHit();
15.  
16.                 if (Physics.Raycast(spawnPointY, Vector3.down, out hit))
17.                 {
18.                     int objID = Random.Range(1, 99999);
19.                     if (go.Contains("Blob"))
20.                         TNManager.Instantiate(1, "CreateBlob", go, true, hit.point, transform.rotation, go, objID, true, 1);
21.                     else
22.                         TNManager.Instantiate(1, "CreateObject", go, true, hit.point, transform.rotation, go, objID);
23.                 }
24.             }
25.  
26.             // Timer
27.             yield return new WaitForSeconds(itemToSpawn.spawnTimerInSeconds);
28.         }
29.     }

13

TNet 3 Support / Re: Host Change doesn't go well

« on: October 30, 2016, 01:24:18 PM »

Ya TNet 3 is better than 2. I had 2 for quite some time and then when I went to 3 it was a lot smoother. I noticed a lot of new features, you can check Arens post on patch notes if you are interested to see what has been changed since TNet 2 to TNet 3 but there is a lot.

14

TNet 3 Support / Re: Host Change doesn't go well

« on: October 30, 2016, 10:10:54 AM »

Yes that is exactly what is happening. I will give the code a shot, silly me I never thought of doing it that way. One second I will respond with the result.

15

TNet 3 Support / Re: Host Change doesn't go well

« on: October 27, 2016, 03:55:41 PM »

Forgot to mention that I got rid of the host change callbacks. I just made it so the Coroutine is ran on everyone but only processed if host.