Message Events from Darkstar Project Vanishing in Unity.

This may be a bit of a long shot, but here goes anyway.

I’m experimenting with Unity (trial, 2.5, windows) and the Project Darkstar server by way of the DarkstarSharp API.

Almost everything is working as expected (after much fiddling as I am still novice level at much of this).

Except at some (early) point the Unity client stops picking up events on both SimpleClientListener and ChannelListener.

The main class of the script implements MonoBehaviour, SimpleClientListener and ClientChannelListener. I have tested with the listeners implemented in separate classes but it doesn’t make any apparent difference.

I make the login request from the Start() method. On receipt of the LoggedIn() callback I send a message requesting to be added to a channel on the server. This works, and the JoinedChannel() callback fires as expected. The ClientChannel is saved in a variable in the main class of the script and “this” is used as the return value. A single test event sent immediately by the server triggers the
ReceivedMessage(ClientChannel cc, byte[ ] message) //The channel listener
event handler as expected, and a pair of messages to the server bring back responses through
ReceivedMessage(byte[ ] message) //The session listener
which are used to make a landscape of cubes and place a First Person Controller prefab in the scene.

The client then sends regular updates to the Channel which get to the server, and cause the server to send channel messages back. A C# application which does nothing but login and join the channel (displaying all the messages on the channel) sees everything, both client to server and server-client, but the unity client sees no further events from the server.

I attach the major files in question, with humble requests that my dire code not be laughed at too much. There’s probably some obvious error on my part causing all this.

TLDR; - Event handlers in unity client C# script stop working after a few messages, even though other listeners using the same API and broadcast channel receive the messages succesfully.

136777–5023–$expt_100.cs (9.97 KB)

For anyone curious, I’m experimenting with the feasibility of implementing a shiny unity frontend to a serverside “Rogue-like” game, purely as a proof of concept and the practise.

A long, long way to go yet.

136779–5024–$servercode_119.zip (5.08 KB)

i’m totally guessing in the blind.

But when I made the SmartFoxServer client API we ran into issues with thread safety. Unity is not thread safe at all, and some messages got mangled or lost.

On top of it, Unity doesnt like it if callbacks manipulate e.g. data arrays while they are being used. Best example could be arrays of chat messages currently being looped over in OnGUI, and new chats being added to the array at the same time.

The solution for SFS API is to queue up all messages from the backend, and then process them in the Update method only with Unity being the thread calling.

Again - I’m totally guessing in the blind, so this might not be remotely related to your problem.

/Thomas

I ran into that a while back as well. I was getting quite irritated watching unity editor crashing nastily until it was pointed out to me that I was instantiating hundreds of gameobjects outside of the approved threads.

I don’t think it’s the case here as I’ve stripped it down as far as doing nothing but writing Debug.Log entries to no avail.

I’ll put together a buffer and apply in update system anyway, as I’ll need it later, and I can hope it will resolve this as well.

My thanks.

So, did it help? :slight_smile:

I’m researching using Darkstar, too, which is why I’m curious to know.

There weren’t any silver bullet fixes, but once I’d tightened up my code in several areas, put in the time to catch the exceptions, made sure to close connections properly (etc etc etc) this problem went away.

I’ve since encapsulated my server communication a lot more carefully, and ensured that the communications all follow correct procedure precisely, and it’s sorted this whole area out.

I do reckon Darkstar has a lot going for it, but it is not at all forgiving toward sloppy or incomplete code.