Named pipe _u~
|
I’m going to talk about something I have not yet completed, but I mentioned it in my previous blog. What I have been trying to accomplish is to have one Windows Form application to communicate with Unity . The idea is to use the windows form application to control Unity. Reason for wanting to do that is several, but mostly it’s to see how it can be done. Now the original plan was to use network. I have successfully tested network communication through console and I know that works. I did not test that however with Unity, but Unity has its own networking pipeline and I did not want to mess with that. There are however ways to deal with it, but I figured that I would test something simpler. The solution I’m currently testing is NamedPipe. I thought I would get away with not having to deal with creating a different thread for Unity, that turns out to be false. You need to have a thread running that monitors the incoming traffic. Setup so farI created a windows forms solution with 3 buttons, a color picker and a window. The window is just a multiline textbox which catches debug messages. But the 3 buttons for now are used to send 3 different messages to the Unity game. Reason for choosing named pipe in the first place, was that it was a .net feature that I hoped would be easy to use. It is sort of easy to use, but one thing I forgot was that sending text to another program is easy. However distinguishing between different commands is not that easy through text. What I needed to do was to create a packet system. Yes, it sounds dumb, but since you are writing data in the form of bytes, you need to communicate through those bytes. Converting them from and to the data you need. PacketsThis is not set in stone yet, but so far the packet system I created was just an enumeration and a size of the buffer coming in. I set the buffer to be 512, but one of the things I didn’t know was that the size of the buffer coming in, is the size of the buffer I set. Basically the byte array I get is 512bytes long, even if I get 12 or 60 bytes of data. So in order to know how many bytes that I need to read I needed to get that information in the header. The enumeration I wanted there because it is easier to remember that PacketType.MoveLeft is to move left than 0, 1, 2, 3 etc. This distinction makes it easier to also know how to decode the message that comes in. I have yet to make a package handler, so I need to do that too, but current testing shows that it works to for instance change the background color from a color picker that Windows offers. Which is nice. I don’t know if that is something I will use. All of this is just because I wanted to see how to pass information from one program to another. So far it works. Unity editor crashes left and right though, but that is I believe more related to the thread that I needed to create in order to constantly monitor the stream. The program that sends stuff is fairly solid, it does crash if it starts up before Unity, but that is a minor fix. Tips for those who want to test it outThere are two ways to use named pipes. One is with streamwriter and streamreader, the other is doing it without. I had lots of crashes with Unity by testing out the streamwriter and reader. I decided to do it over, and now it works better. Some of the reason however is that I found out that if you BeginWrite, you need to EndWrite. Same with BeginRead, you need to EndRead too. So if you have something that begins, always remember to end it. Another tip, if you are using threads and you separate them and make them run in a loop in the background, be sure to abort them at the end and also make sure the loop ends. I used that in the deconstructor. That did not work well, use the: OnApplicationQuit method instead. That way when you click the play button again to make it stop, the thread stops since the deconstructor doesn’t run in the editor. At least the loop never stopped unless I put stuff in the OnApplicationQuit method. Can’t explain why, did not research it. Tested it and it worked. Patience. IT will crash. A lot. Unless you’ve tested it before and know exactly how it works before starting. Anyway next time I hope to have more to share. I did not share any code, it contains a lot of debug messages, as threaded operations in Unity seems to be harder to debug, so instead there’s a million of Debug.Log messages. Last tip: Make sure to disconnect the pipe before stopping Unity. If you want to read more about this though here’s a couple of links that helped me: |
