Well, if you have a .Net dll that is compiled with 2.0 framework in mind, simply drag and drop the DLL into the root of the assets folder, then add a Using statement at the top like you would normally in C#. At that point you can use the DLL.
If you take a look at the LinkSyncSRC.cs file, you will see that at the top I have the following:
using UnityEngine;
using System.Collections;
using System.Runtime.InteropServices;
using UnityTCPIPLib;
using System.Security.Permissions;
using System.Threading;
The permissions one isn’t used in this example so you can forget that one if you want.
Now on into the core code:
Connector test; // member of the UnityTCPIPLib
string lastMessage; // what we have received last
public Transform PlayerCoord; // transform position of target object
void Start()
{
test = new Connector(); // our guts and glory
Debug.Log(test.fnConnectResult("localhost", 10000, "Test User"));
// localhost obvious, 10000 port, Test User player name
if (test.res != "")
{
Debug.Log(test.res);// how did we do
}
}
At this point, I have made a connection to the server, passed it some info, and received an ACK back so I know things are working. Sockets are not the most effecient way to do things but hey. So now after I do some key checking, passing test data back and forth from Unity, when you close Unity:
void OnApplicationQuit()
{
try { test.fnDisconnect(); }
catch {}
}
Notice something here, I am ignoring any errors spit back at me. There is a purpose to this madness, you see, when you close the socket connection, or make a call to have it do this, you are not guaranteed that it happens immediately so the socket remains open and locked for a short period of time, but that time will exceed a game loop duration. And we really don’t need to care.
When we shut down the listener in Unity, you need to wrap it in a try/catch because the listener can delay on shutting down and Unity won’t take that into consideration when the Editor tries to terminate the thread. The Editor is non-bias on this, it has no care about your threads at-all and no way for Unity to know or understand threads you create.
So in essance, for a moment, we are orphaning the thread but the call to terminate it is queued up in windows message queu and will eventually trigger (rather short time, but enough to make Unity puke), change your code to:
void OnApplicationQuit()
{
try
{
ts1.Stop();
}
catch(Exception e)
{
Debug.Log(e.ToString());
}
}
Then look at the log, most likely you will have a error related to a lock state call, which is safe to ignore. I have updated the code some today for VS 2008 client/server/DLL, and have been testing it locally. I will test it against Unity in the next few hours and add some more outputs in the editor and post up the new build / code and screenshots. Hopefully it will be pretty straight forward.
I wouldn’t recommend using this for anything over 4 players though and most certainly nothing with massive amounts of data back and forth, I have seen as much as 120ms delay between the player announce himself to the server, the server broadcast that player attaching to all connected and those connected refresh their player list with that new player.
Although that could simply be my dev machine.
Let me know if any of this information helps.
