Unity's networking is DYSFUNCTIONAL.

Again it is amazing! You should add a better AI script. But by better you should add AI that can do all the things the player can do like with the buggy, how it has the glider, you should have the AI able to use that. And have the AI be able to switch their vehicle. Or at least have the vehicle be randomized.

 

Dude the sea piece rocks, although I haven't seen anyone yet get a real feel for the tires on any surface in Unity, always get that sliding on ice effect in every game ever made with Unity, no real "grip" feel.

 

I know exactly what you mean Zumwalt - my high speed offroad tire physics are decent, but at low speeds, the buggy has a tendency to drift sideways much more than it should. I will work on that in future releases. I have been experimenting, and I think the problem can be addressed by fine tuning the distinction between my "static" and "dynamic" tire friction modes, and significantly increasing the friction available in the static mode.

I have AI enhancements planned Freeland, but you have to remember - Mars Explorer is all about having fun with your friends. There are 30 or so players on the release version right now, and they are much more fun to play with than any bot ever could be

 

I'm only saying it would be more challenging if the bots were different. Ya know, mix 'em up a little. But I love the multiplayer thing and I understand the fun with friends and that's one of the only things I did yesterday. But my friends and I really wanted to have a "Human vs. CPU Match" kinda thing. Ya know?

Other than that, It's amazing!!!

 

I would like to see a response from Unity on the issues in this thread.

 

All Right!

HiggyB has promised to send a Unity networking developer in the direction of this thread any day now, and we may have the opportunity to get all the issues discussed here isolated and resolved.

I have been hard at work on Mars Explorer, and the latest version hosts it's dedicated servers on Amazon's Elastic Compute Cloud and includes the capability for server hosts to specify whether player positions are transmitted via unreliable bitStreams, reliable bitStreams, or RPCs.

When in RPC mode, everything works but the lag is just about unbearable.
When in BitStream mode, the lag is still higher than I would like - but everything works pretty nicely 'till the non serialization bug surfaces after a random amount of time and destroys the game for everyone.

Unity: I have clear demonstrations of several issues in Unity's networking, and thousands of players who are suffering from them in my game and would love to help get them resolved. I can't wait to share my networking code with you, and anything else I can provide to help isolate these issues. You owe it to yourselves to either stop advertising that Unity provides full featured integrated networking, or to spend a little time to fix it's bugs and make it usable.

-Aubrey

 

That is a very, very good post, Aubrey.

Thank you.....

 

Unfortunately - another week has gone by and Unity's unresponsive tendencies have continued to be demonstrated.

I have now despaired of trusting Unity to support any aspect of their engine, and have officially given up on Unity's builtin networking library.

If you are thinking of building something real with Unity's networking, think again. It will almost work in many different ways - but the more popular your game will become, the more spectacularly it will fail - and the less support (or even acknowledgment) you will receive from the company who advertised the system as fully functional and who you trusted.

I don't want to sound bitter - it's just that Unity has been such a wonderful company in all other areas I have observed that I am honestly baffled by their behavior in regards to these issues.


Thanks to all of you who have encouraged and aided me.

I have been experimenting a bit with Photon - but although it does look pretty slick, it's design principles weren't quite what I had expected. (After being accustomed to the likes of OnSerializeNetworkView and BitStream.Serialize, NPeer.opRaiseEvent just sounds so foreign ).

Lidgren looks like it may be a perfect solution for me, and I have just begun writing a dedicated server in c# using MonoDevelop that will be deployed on Amazon's cloud, and which will launch and maintain multiple Lidgren server threads to host each game in Mars Explorer. I even plan to have a "lobby" server thread, which will provide a global chat and master server functionality for players who haven't joined an active game.

I am looking forward to rewriting Mars Explorer to utilize lidgren, and will keep everyone posted on my progress!

Happy Coding,

-Aubrey

 

Just so you know you're not alone in the dark, Robur...

I corresponded with Higgy on this issue last month around the 22nd. He stated that he was aware of the various threads and concerns, that he had asked for the dev team to join the discussion. In his words, "asked them to step in post-haste."

That was obviously a little bit before you made your post, declaring you had a similar conversation and a similar claim of 'help is on the way.'

At this point, I'm starting to wonder what 'post-haste' translates to in Danish. :roll:

 

Just to let you know, I've requested a visit from a UT tech person to this thread and I'm now authorised to press it until it happens. You should get a response soon.

 

I'm pretty sure the forum moderators are bored of me injecting this into any thread that is vaguely related to the topic too. :roll:

 

You hear that Higgy? When it comes to pulling teeth Andeeee is saying he has a bigger pair of pliers than you.

 

Ooh, let's not start this kind of thing ;-)

No, this has been passed to the dev team by me before and again by Tom more recently. However, it appears the dev team were unclear about who was supposed to be answering and nobody actually did. We've now tightened things up a bit, so that forum mods can poke the developers and clarify who should answer. The teeth-pulling pliers are available to Higgy and AntennaTree too, it just happened to be me who responded to the thread first. I'm not sure which of us is Curly, Larry or Moe, though ;-)

 

Robur, I am a blatent idiot for never asking you this before in either private PM's, Emails or in the thread, so I mise well fess up and ask here, what "exactly" are you trying to send data wise? How many itterations per second and are you throtteling the data to match a dedicated frames per second support?

Example for this would be, are you sending the players position information, transform information and a custom class of information that would include acceleration factors in your interpolation code? Meaning are you interpolating with a prediction based on latency in the formula every frame or are you doing it based on a fixed assumed frame rate?

The best I have seen are filters that take into consideration that the average player will not have any greater than 30 frames per second of data with a 115ms network connection delay throttled using the fixedupdate instead of the update. If you are not throttling your data and dealing with a fixed frames per second on all player base, you are most likely flooding the servers with way to much data, regardless if you are dealing with it based on a time stamp difference between the sender and the receiver within a given norm, you are still sending the data which is buffered, transmitted, received and translated, so in essance is still acted on.

Over time this will eventually cause lag and delays in information being properly used on the server and on the clients, especially in a broadcast set, it becomes exponentially worse by the increased amount of players to the game. This is a flat out right thorn if you have a dedicated game server not running in batchmode.

 

I'm not sure either about the Curly/Larry/Moe situation. And FWIW, Andy has shown himself far more adept at using the pliers than any of us. So much so that we decided "bah, who needs a dental plan, we have Andy!".

Edit: and yes, we do expect some engineering eyes on this thread any time now, thanks for your patience everyone!

 

And the plot thickens....

 

Another day passes and Robur has not arrived to kick ass...

 

Robur has already stated he's lost faith in Unity's networking and moved on to using Lidgren.

The Unity folks have acknowledged that something is broken. I think that's all anyone really wanted, instead of silence. We simply have a choice. Wait until the next Unity release and cross our fingers, or do like Robur.

 

i am also going the raknet plugin way.
not only for the known reasons, also because of performance and stability

will share it if it becomes usefull

 

Larus;

Glad to hear that Unity is interested in resolving these bugs. Very glad to hear that it is scheduled for the next release!

If you play Mars Explorer for 20 minutes or so with several other players, you or someone else in the game is practically guaranteed to experience the "No Connection" issue.

To facilitate the isolation and resolution of all the bugs discussed in this thread, I am providing Unity the complete project folders for the latest version of Mars Explorer, and for Mars Explorer's headless dedicated servers.

The complete Mars Explorer 2.21 project will be accessible through support ticket # 313286.

Mars Explorer's dedicated server project (along with pertinent client networking code and custom WiggleBox bug test projects) is available for all interested parties to download here.

All The Best,

-Aubrey



Others;

Quietus is quite right, I am very busy with other things (such as the 2.6.1 webplayer failure), upcoming Whirld 3 library, and release of Mars Explorer 2.21 (Be sure to check out the brand new Sky King world - it's awesome! ...And I did fix the buggy handling Zumwalt

At this point, I honestly can't recommend the use of Unity's networking to anyone. I am looking forward to sharing my experiences once I have had a chance to delve deeply into Lidgren.

 

What was the fix to the buggy handling?
I am finding that in 4 different network libraries, Unity client simply stops sending data over time from the client, so I backed to a TCP/IP Sockets version that also experiences this when communicating between Mono's version of System.Threading and .Net version of System.Threading, something isn't right between the two different versions. I can't put my finger on it, but I can guarantee a connection from the client to the server, but Unity is simply throwing an invalid Thread message back to the thread state in Unity itself but I still get data from Unity because the thread is running, the port is open, the communication is happening, the server gets the message, but it is like a simplex connection.

I have gotten zero response back from Unity on this issue, and also with an editor bug issue that I have discovered with regards to the view frustum and transform.forward as another issue, I have zero problems out side of Unity with the network component in TV3D, and in 3Impact but Unity on the other hand, same code, same everything, simply dies. It appears to be Mono specific problems though, so I seriously doubt they will even bother to respond about either of these two issues since frankly it has nothing to do with Unity per say but the fact they are using a bug riddled version of Mono.

 

They've admitted that it is broken and that's a start. However if what you're saying it true it's very depressing. It means it won't be resolved until the next major release of Unity includes a mono update. One that we'll have to pay money for?

We'll know for sure once Robur finishes converting to Lidgren. If he expends all that effort only to encounter the same issues he's going to punch a wall!

I would hope that the Unity folks have thrown a ton of resources at the problem and made it the company's top priority. Not just thrown in one guy's inbox. If not, they should do the right thing and simply remove networking as a core component of Unity's feature-set listed on the webpage.

 

I'm planning to do "larger-scale multiplayer" in the longer run and Traces of Illumination is kind of my testcase for that ... and Unity's built-in networking, while in my opinion, quite beautifully designed for what it was meant for ("make lower-scale networking somewhat accessible to the masses") just wasn't designed for "larger-scale multiplayer" (the bugs sure are annoying but I'm sure at *some* point in time they *will* be fixed but I doubt the main direction is likely to ever change towards anything larger scale and it's probably even questionable whether that would be desirable at all) ... I guess it just took me a very loooong time to really get this (it's not like UT is making a secret about its networking being meant for "low-scale") ;-)

So ... I'm currently considering changing the networking-backend and moving over to Photon for the networking. I haven't decided for sure, yet - mostly because that means I'll not only have to "do a little porting" but basically have to re-design and re-write large parts of my networking-approach (just one example: I have 115 different RPCs ... that is "no big deal" in Unity but will probably be a nightmare in Photon ... and there's a lot of other aspects ... at least, fortunately, I'm not using buffered RPCs, Networking.Instantiate or NetworkView-synchronization ... lucky me ;-) ).

With Unity's networking, basically, I've hit what I think to be a "solid wall" at around 80 or so players per server ... and Unity networking only supports connecting to a single server at a time (and that aspect is *very* unlikely to ever be changed; admittedly, I don't think that's something a lot of people really need, so for what Unity networking is intended for, there really is no reason to change that). There would be ways around that limitation (I could do server-transfers for clients and do "chat over multiple servers" via the backend database to which all servers connect). But ... that just doesn't feel like fun ;-) so, while I haven't made the final decision, it's *very* likely that I'll move over (fingers are already tickling).


Anyways, regarding what zumwalt wrote about Mono:

Mono 1.2.5 just plainly sucks and I can't wait to get my hands on a version of Unity with a "proper Mono framework". Like, another user just ran into an issue with Environment.TickCount (which is used by Photon) doing funky stuff around every second (going "back in time" two seconds - wouldn't it be cool if we could use this for actual time-travelling!? ;-) ).

I'm not quite sure if this is related in any way to the issues with Unity's built-in networking, but I do remember having seen something similar with Unity's networking before (network timeDiffs acting very oddly). Maybe Larus could look into this (if you're using Environment.TickCount anywhere, it's likely that this has a very unpleasant effect on Unity's networking, at least on Macs).

So, in any case, whenever UT gets the current version of Mono injected into Unity, that will be one of the really bright days that will make it into the history of "The Wonderful World of Game Development" (I'm quite sure getting a recent version of Raknet and PhysX into Unity should also be pretty cool ;-) ).

I don't mind if that's a major release and I'll have to pay for it - I've had so much fun with Unity 2.x that I'll be happy to send them over a little cash for even more fun with Unity 3.x (and I think one major release every two years is pretty decent ... except for: *please* keep up to date with Mono more frequently in the future ... one Mono update per major release just gets too painful IMHO) ;-)

 

The 'fixed' master server has been in beta for 1 year, 4 months and 1 day as of this post. I'd sure like to know how long since the set of relevant bugs were first logged in the database. Unfortunately, we can't seem to search fozbug.

There are some games that I think would still fall under your 'large scale' simulation, such as Planetside, that due to it's FPS twitch nature has player limits around what you say you're currently doing with your Tron game.

Sure there are some things that would help a great deal in terms of flexibility. You mentioned multiple concurrent server connections. Another would be the ability to have a separate server and client project.

But all in all, Unity's networking, if it actually worked as advertised, could still be capable of quite a lot.

Jashan, I don't believe however that there is any game engine in our reach that caters to 'large-scale' simulations. I think there's an Ryzom MMO engine or some such, but that's about it.

It's just too specific of a topic, with a legion of different approaches. Consider each MMO has it's own drastically different idea on an efficient application protocol, visibility/interest management, node partitioning and client transfer, etc. There is no once-size-fits-all solution like there is for an FPS simulation.

Photon seems like a great solution, I'm probably going to buy it once they clean up the documentation and examples. I think it's a great fit for your game as well.

But for all the people who would like to leverage Unity itself as a server for a project, if Zumwait is correct we're SOL. We can't quite replace Unity's broken networking with our own, if our listening thread chokes on it's own spew randomly. Unfortunately that population set includes me.

p.s. You didn't mention though, what's causing the 90 player ceiling you ran into. I imagine we're talking headless server on osX.

 

I have no issues with paying for a release that includes a newer version of mono, especially one for the System.Net and the System.Threading, this two are very important to me, besides, as a Pro owner, I will have to pay for the update as it is, but the regular Unity owners will get the exact same update for free I don't care much about the time stamp thing, I am using my own code to get the delta time for each packet. The problem is that the regular socket networking appears to go from bidirectional to monodirectional, well that is the only way I can explain it. I can seriously start up my server, start about a dozen instances of Unity and join the game server easily and it work for days on end, then I can shut everything down, then simply start it up and about 70% of my instances report that the Thread state is stopped but I am recieving game information from that running thread on those clients, and the other 30% of the clients recieve the data and act on it. Very frustrating since I want to use that sockets version for the web based version of the game since I can use DarkNet for the non web based or use Photon.

I can't use DarkNet for any web based game, so I would have to use Photon if I can't get sockets to work, I do love Photon though, but long term, I need to save up for their unlimited license model. I have used RakNet natively and setup a multi server connection from Unity, I have a screenshot around the forums with this working, but again, I can't use RakNet natively in a web game, so then I am back to Unity implimentation of Raknet, I have in the "old" wish list, the request for a custom server connect that allows us to connect to multiple servers at the same time, we'll see if they add that.

Back in the old 1.6 days, I pushed for Raknet to be used in Unity and it got in there (not to say that I had ANYTHING influence at that decision, I am glad they did it with v2.x) I am just not happy with HOW they did it.

I am very anxious to get my hands on the version of Unity with a newer Mono, I just wish I knew how much money I needed to keep saved up to pay for my Pro update.

 

I very much agree to that. And I think it's still an area where there's quite a bit of room for creativity and coming up with new solutions that are not just "reinventing the wheel" but really an approach that's best done "custom". So, instead of getting the "create MMO-button" (haha ;-) ), I'd rather have tools that I can build on. Flexibility and open-endedness is the key.

I think Unity does this perfectly in pretty much all areas that I have dealt with so far ... except networking (and audio ;-) ). There simply currently are a few walls you run into and there's just no way around it (well, maybe some way ... but I've followed zumwalt's postings, and I think he really investigated into this and did some excellent work but it seems like a lot of "working around limitations", which is exactly the opposite of what I usually see with Unity where you can just focus on building that which is the "creative part", the game specific stuff, while Unity handles "the boring rest").

But then, maybe it's just too much to expect of a game engine to also provide "open-ended networking". So, I'll see where I can get with combining Unity and what it's best at with Photon and what that's best at (I also kind of like being able to say "my game is built on Unity and Light" ;-) ). And I'm pretty sure "audio-love" is on its way, so "everything client" will eventually be just fine.

... and me ;-) ... what I'm currently planning to do is keeping certain aspects of the game logic (collision detection + movement) in a Unity server which runs as a client of the Photon-server. Multiple such servers can connect to the Photon-server and the game logic provides an almost trivial way of load-balancing (basically, Traces of Illumination only has "instances" with up to 20 players "per instance"; of course, "peer-to-peer"-based networking would make sense for that kind of game - but that's just something I'm not too interested in because that won't work with the other game ideas I'm having).

Btw, I'm actually pretty happy with how I can - with a single Unity project - "dumb down" the server programmatically when it comes to anything visual while at the same time "smarting it up" when it comes to "the stuff the server needs to handle" ... even though I had to implement my own kind of "conditional compilation" (I really hope for proper support of project-wide conditional compilation symbols in one of the next versions) and "stripping" the project during runtime.

One thing that may become a problem when going with Photon is that currently, the asset server only works with Unity - but putting my Photon-project into a Unity project will give me lots of compilation errors. That's not good :-(

Headless on Windows (all cameras removed, all renderers deactivated, all objects not strictly necessary to implement the game mechanics destroyed). I'm not perfectly sure but my feeling is that handling all the networking "stuff" and at the same time handling persistence and at the same time handling the complete game mechanics for a lot of players was "just too much".

That's why I'm planning to follow an approach where my Unity game servers only handle what's really easy to implement in Unity (and difficult to implement from scratch otherwise): Collisions and movement; and let the Photon-server do all the rest (stuff like "can this player use that power-up right now?", and of course: distributing the information via the network). I also really like that I can use .NET 3.5 in Photon because that way, I can implement proper performance counters (which makes testing and monitoring a server-application and finding bottlenecks *much* easier) or a proper persistence layer (which I think also doesn't mix too well into a Unity based game server ... especially not as long as Unity's still using Mono 1.2.5).

 

Ooops - are you saying this is happening with the Mono sockets? If that would be the case, I'd guess that Photon may very well be effected by the same issue (well, maybe not - in my understanding the client is .NET / Mono but the server is C++ ... so if it's an incompatibility between Mono and .NET that wouldn't be a problem with Photon - but if it's an incompatibility between Mono and "anything else", I'm pretty sure this would have an effect on Photon).

 

Maybe someone should go see if there's a FusionFall forum. Try and search for issues like "I runz around but nobodies moven helpzor!" It might possibly be a good bellwether on the issue.

That's very interesting. I had not thought of doing that. I imagine all the RPC's would still work and such, as Unity still thinks it's one project.

You should post something about that in the huge hacking thread. The technique would benefit some, who might be concerned about having to distribute their entire server logic along with their client.

Lol, so an authoritative server that also happens to have an authoritative client? That's quite interesting from a number of standpoints.

That's the same reason I wanted to leverage Unity, wanting to use all the fancy bells and whistles in a Unity based server instead of spending time implementing everything from LOS code on up.

 

FusionFall as far as I am aware (and hopefully one of their cats can drop a hint here) used a completely custom approach using sockets without utilizing Mono's System.Threading or Mono's System.Net approach (which I haven't done yet), Photon works for web based games, I was looking for a very simple approach for <50 players at a time using nothing more than what Unity supplies (without using Raknet) based on Mono and the two items mentioned above. See the only real limitation that I am dealing with is the limitation of the browser based client approach. Even with Pro, Unity does not allow us to deploy custom libraries (unmanaged code), so that eliminates my Raknet kit I made, so that leaves me with having to make a custom .Net 2.0 set, well, if I want to use just what comes with Unity being Mono driven, I have to have the sockets created in Unity talking to sockets created in .Net native.

That is the disconnection.
Photon simply works, Raknet simply works but has some bugs in its current form in Unity which will eventually be resolve, the mix between Mono and .Net doesn't simply work, now this could also be the fact that I made my server and windows client in Visual Studio 2008, which even with the project target set to .Net framework 2.0, I have a sneaky suspiscion that it still is using what ever Microsoft decides to grab for the library up to my 3.5 framework folders. Unity can't control that and I can't using the Mono version of System.Net ans System.Threading in my VS 2008 project without it puking.

I am experiencing a cross compatibility issue, of which Unity has no control over. There is definately no pointing the finger at them on this one, it is not their developers fault at all, I have not moved my code that does all the heavy lifing from the .Net library that I wrote straight into Unity yet, that will be my next step this week, right now Unity is trying to handle the native library set from Mono as I create my thread and make the call to the library, passing it socket information in my loop, which in my library I am also using System.Net and System.Threading which of course with the library is using native windows libraries, but in Unity it is using Mono libraries, don't get me wrong or misunderstand me here, a pure Unity project without any external DLL's written in either VS 2003, VS 2005 or VS 2008 could probably work with a VS 2008 written server project, I am mixing the two which appears to have limitations. Just learning the ropes with what I can mix and what I simply can't mix, there is no documentation that says which libraries you can and can not mix and expect to work.

A socket message is a socket message, I see there is confusion in all this networking discussion as to what is going on and where it is happening. Raknet message is limited to work within the framekwork of the build used, in this case Unity is using Beta 3.0 code of Raknet written back in 2007. They wrapped it into the base code, so the client / server starts happen as Unity starts. Did you know that when you load Unity Editor that Raknet is already running? Well it is, you can call a core Raknet server from Unity and connect and send the message, recieve it and act on it. What you do not have is the guts to the defined serialized classes that are inside Unity. To get to all of this stuff you need to buy Unity source to see it.

It isn't like Unity networking does work, because it does. It is just that there is no documented case on all the different ways to make it work.

 

Zumwalt, I think that confusion started when a page ago you jump in and appeared to suggest that the root of all these problems is really mono's threading model. That of course sounds quite plausible. Now you appear to be backtracking.

If a bug in mono's threading model is not really germane to the serialization, vanishing connection and other networking issues robur and others have documented in this thread, I'm confused as to why it was mentioned in the first place.

I know I'm now scratching my head, wondering if a Lidgren based server will actually work within unity or not.

 

Ah - I see. Thanks for clearing that up! I remember running into a similar issue a while back: When I wanted to create the persistence layer, I needed System.Data.dll or something like that; and since I had Mono 1.9.1 installed on my Mac, I simply grabbed that assembly from there and put it into my project. That seemed to work smoothly (I could connect to my database ;-) ).

Later, I discovered that the Unity editor crashed on exit whenever I had started my server in the editor. And the server (standalone) always crashed directly on close. That was *hell* to debug ... I simply had no idea what was going on there (and since those crashes only occurred when I was closing the apps, it didn't bother me too much, either, at least in the beginning). Finally, I found out, replaced the assembly with the one from Unity and everything was smooth (well, except that those connections aren't too reliable ... but that's another story ;-) ).

 

Yeah. The only thing you must not do is #if-out the actual RPC declarations. So, you can do:

Code (csharp):

1.  
2. [RPC]
3. public void MySecretServerRPC(someParameters) {
4. #if SERVER
5.     // your super-secret server sauce
6. #end
7. }
8.  

But you can't do

Code (csharp):

1.  
2. #if SERVER
3. [RPC]
4. public void MySecretServerRPC(someParameters) {
5.     // your super-secret server sauce
6. }
7. #end
8.  

Ah ... I had been following that thread for a while but I guess I missed that part.

I maybe should mention that I was inspired to that idea by reading some stuff on "service based MMO servers"; not exactly sure where ... oh well, wasn't hard to find:

Shea Street (Tantrum Games), "Massively Multiplayer Games Using a Distributed Services Approach" in Thor Alexander (Editor) Massively Multiplayer Game Development 2, 2005; p. 233

 

You see well there's the catch. I was totally unaware that Unity supported preprocessor directives. I remember discovering that Unityscript didn't support macros (something I used quite often in C obviously), so I had simply made the assumption that they didn't exist.

I'm going to assume that it's a C# language feature. I'll have to be a convert if so.

 

C# supports them. Unity doesn't - but at least Unity "tolerates" them, so you can use them without Unity giving you errors. So, what I'm doing is having the defines in every code file and then have a script that comments those defines in/out for all code files on demand. It's not exactly "convenient" but now that it's implemented, it works. See also my answer to: Is there a way to have debug code compiled out for a final build?

What? Are you using UnityScript. <meKids>Sorry, can't talk to you anymore ;-)</meKids>

Write it a 100 times: "C# is the ONLY ONE" ;-)

OF COURSE, you have to be a convert! (Now I wonder if Eric will jump in ;-) )

 

Lol.

Until now, I never had come across something I really needed that Unityscript didn't provide in some fashion. Preprocessor directives certainly fits that category.

Now if C# has macro facilities to boot, I'm sold! I remember way back in the ansi-c days, where it sometimes felt like a third of your program would consist of macros. Boy were they useful.

I will say that the availability of mondevelop has also slightly increased the possibility of my moving to the dark side. But it will have to wait until I'm finished my current project.

P.S. Sorry robur for pulling your thread off-topic. Here I'll fix it.

Unity: Your networking is admittedly buggy and useless. Fix it sooner rather than later kkthx!

 

Yeah, yeah, yeah! ;-) Vote Now!

No! No! No! Macros are evil. C# doesn't have them ;-)

Ok ... back to topic: I think Unity's networking has great potential for what it was created for (and possibly beyond that) but it needs more love ... and more flexibility. On the other hand ... if you look at the "networking" entries on Unity feedback, it doesn't seem like that many users care that much:

Networking: VoIP support (e.g. RakVoice) is ranked 19th with 118 votes. That's nice. I'm considering integrating my game with TeamSpeak 3, and possibly Skype (would be a loosely coupled integration ... maybe a more tight integration with TeamSpeak 3 for standalones, if the TeamSpeak 3 SDK is easy enough to use for someone who doesn't particularly love C++ ;-) ).

Networking: Headless Server Support had 109 votes and is completed. That's great!!!

Linux: Headless Server ... hm ... has 79 votes ...

Networking updates is ranked 41st with 31 votes (and I think this is important stuff!)

Networking: Fix Windows Vista - a bugfix request (argh, wrong channel ;-) ), is ranked 55th with 19 votes.

Networking: SendReliable Parameter on RPCs - got a mere 4 votes (3 of those are mine ... I posted that one ;-) ). Rank 143.

Networking: Built-in Server was declined (3 votes ... and I think it's obvious why this was declined ... seems like someone didn't read the manual ... Unity is not Counterstrike ;-) )

Networking: Script Interface for the RPC buffer has 3 votes, giving it rank 167.

You can get the whole list by simply typing "networking" in the "Unity needs" textbox (for some reason I can't "open" completed and declined items).

Well, at least Scripting: Upgrade Mono to 2.4 / 2.6 is ranked 7th with 261 votes. Yay! ;-)

 

HERESY!

Code (csharp):

1. #define REMOVE_FROM_LIST(item, head, next)  \
2.    if ((item) == (head))        \
3.       head = (item)->next;      \
4.    else {               \
5.       temp = head;          \
6.       while (temp  (temp->next != (item))) \
7.      temp = temp->next;     \
8.       if (temp)             \
9.          temp->next = (item)->next; \
10.    }                    \
11.  

Is a thing of beauty!


I can't quite vote for anything. All 10 of my votes were used immediately and never were returned! It feels like the phone company, stealing my roll-over minutes! :wink:

Still, I don't think a module's popularity on the uservoice site should have any bearing on the priority Unity assigns to resolving the networking issues in this thread. It's listed as a core feature on the product website and it's broken. That's what should be driving it.

To me it's analogous, say to, rigidbodies randomly going insane for no apparent reason. Then facing the possibility that it will be fixed as you put it, 'some day', and we'll likely have to pay extra money when it happens.

That's the way Garbagegames used to act and treat it's customers. From my experience with the Unity folks over the last couple years, they have a lot more integrity than that.

 

Agreed.

 

Well, I am not back peddling, Everything that is documented in this thread by Robur and others are all valid issues. Mixing .Net libraries and Mono libraries is an issue, even versions of each set of libraries are an issue, On the back end, Unity is using PINVOKE to do a lot of the heavy lifting between platforms and between library calls, that is why all C++ libraries have to have publicly exposed using DLLEXPORT single methods and hates subclassing. They have issues with ordinals and properly defining the "what" which is in the DLL, now, when we place a C# DLL in the folder, they are disassembling the library to get a list of public methods since we are not suplying Unity with any information about out library, including not exposing it to COM.

Lets assume for a minute that upon dropping a DLL (LIDGREN) into the Assets folder, that Unity gets a list of publicly exposed methods, the library was built with x86 checked off and built in VS 2008, even with framework 2.0 selected. That is the export targets, however, in the library was used System.Data and System.Net along with System.Threading, the runtime versions of those 3 should be no higher than v2.0.50727, prefferably they should be v1.1.4322, to have a better accuracy, they should have been with v1.1.4322 or v1.0.3705 which has a higher chance not to hiccup against the current version of Mono being used.

Yet there is still one more catch, the developer has to know that on the .NET tab when adding the reference to their project, to look at the Version column, not just the runtime column. for things to work correctly (or as close to accurately as possible) with Unity and Mono in Unity 2.6.1, you need to try to only use Version 1.0.61025.0, however, in the list if you have upgraded your framework and applied all of the correct pratches, you have Version 3.5.0.0 with runtime of v2.0.50727 which causes havoc to say the least.

For best compatibility at this time with Unity, you really need to have Visual Studio 2003 with framework 1.0 being runtime v1.0.3705 but no greater than Visual Studio 2003 with runtime v1.1.4322 and version 2.0, I actually plan on going out this weekend and trying to find a machine with Windows XP Pro on it still and install just Visual Studio 2003 and starting from scratch to see if I can get past my networking and threading issues, all of my machines are now either Vista or Windows 7, and as you can imagine, those are version 3.5 right now.

Even raknet project is a vs2003 project, hopefully you can guess why, since raknet works and compiles even on beta 3.0 of raknet in vs 2005 and vs 2008.

 

Well I'm still confused Zumwalt.

You are describing a runtime versioning issue. Not a bug in Unity's networking (topic of this thread) or a bug in Unity's threading that is causing bugs to arise in Unity's networking. :?

 

Ok, look at it this way, Unity networking built on RakNet has provable over time lag / disconnection issues, this is runtime obviously. Another form of internal networking is using .net sockets with threading and Unity, again runtime. (Actually everything is runtime)

To understand where or how these issues happen, you have to understand the Mono limitations for one side of the coin and you have to understand Raknet on the otherside of the coin. Unity -has to have- a seperate thread for the network component. Stating the not so obvious here but if Unity internally is utilizing mono threading and that component shows flaws in connection / disconnection / latency over time and invalid threadstate responses even with sockets, wouldn't one start to come to the conclusion that a core mono bug is possibly causing all of these issues?

I am digging farther back to where everything began, on the Mac. There are several 'unknown' factors here, I could presume that Unity is built on C++ in XCode which made its port to Windows rather smooth, since for the most part C++ is C++, on Mac or PC doesn't really matter. Mono acts one way on the Mac and slightly different on the PC do to the Windows. If Unity is going to "fix" networking, then all aspects on each side are a need to know.

As Robur created the thread and the thead stands as being that networking in Unity is dysfunctional. Ok, so then the why or how and where come into play. Raknet on the Mac in Unity acts slightly different than that of the Raknet in Unity on the PC build. Same goes for the custom sockets interface, same goes for the thread start. On the Mac, based on tests from last night, I can get my project to run 100% of the time and get a good connection to the Windows server, same project, same package on the Windows box to the Windows server crashes Unity about 60% of the time on 3 different test boxes with the same memory access violation in Mono module.

Raknet on the Mac eventually stops either sending acknowledgement or stops receiving acknowledgement commands, same for the PC, it just eventually dies out. Could be minutes, could be hours. What is common between the two is buffer/cache of the network information. Raknet -should not be- using Mono objects, but it -might- be, I do not know how they are handling the threading piece for Raknet within the client itself.

I would find it odd that both ways of creating a networked game have similar fate and both items not be related somehow.

Lets just assume for a second, that they are related, we have an open connection from the client to the server from within Unity using Raknet, eventually the client no longer "receives" information from other clients, but is still "sending" information that is being acknowledged at the server, the thread doing the work has a false running state reported back to the client so the client has no clue the thread is still active, but the server is still getting the messages from Raknet.

Now lets also assume for a second that for some unlikely reason the thread broke but now is in a "hung" state. This would cause Raknet to no longer respond to messages, but could allow Raknet to still send messages. Now for some reason this same scenario exists with sockets. So now mentioning the threading issues becomes a plausable location to look.

 

Yes. That's why Jashan and myself gave it a lot of weight when you mentioned it, as a bug in the mono threading would certainly be a good candidate for a cause of a lot of these issues.

Hence the confusion as it appeared, at least to me, after making that statement you somewhat backed away from the conclusions we had come to.

 

Then it is true? Higgy did run over the networking code with his motorcycle then poured a beer on it!

 

Come now, let's not drag Higgy into this :wink:

I am fascinated by your research Zumwalt! It sure would be ironic if the core issue is at a lower level than that which I am about to expend a large amount of effort to tunnel under...

 

It is extremely easy to find out, create a stand alone windows sockets server, in Unity use the system.threading and mono sockets to connect to the windows .net sockets, you will soon find out what I am talking about. I am also using delegates and events to act on the information provided to me (since obviously you can't have direct interaction between threads), I use delegates to pass information from my networking thread response to other portions of the program. I would be much happier if someone else was able to come to the same conclusion that I have, that and it would be a sanity check.

I am in the process of expanding my Photon base of networking code to try to see how far I can push the Virtual Server, I already know what I can push with Raknet across to it, so I want some larger user base tests, obviously nothing on your scale of thousands though.

 

Hm, interesting thread.

I'm experiencing something... perhaps similar:
http://forum.unity3d.com/viewtopic.php?t=41836

You do realize that delegates and events are in themselves just method calls basically, which are run in the thread that invokes the event? Just checking.

Delegates and events have NO built-in thread safety. You will need locked queues or something similar to get thread safety.

 

I have mentioned this before, but my experience is that the networking issues with Mono and .Net sockets can be overcome provided:

1) You don't use ANY async networking, and instead create your own thread and poll it "old school" style to receive data. Any of the async stuff will eventually cause you grief, manifested in editor crashes during reconnects, clients crashing, etc.

If anyone can provide an example that uses async sockets and works reliably I would love to see it, but I have spent a considerable amount of time trying various combinations of options and there are always problems with crashing.


2) Carefully protect Unity from any sort of foreign thread calls by converting all the incoming data into events or similar and queue them up. Have Unity poll and empty the queue using Update or FixedUpdate.

Hope that helps.

 

I have a helper async class that I have written that does the heavy lifting for the delegates, it is a type of fire and forget system, it uses waitcallback and threadpooling with dynamicinvoke call. It is thread safe.