Unity's networking is DYSFUNCTIONAL.

I searched about after magwo posted.

There seem to be a number of forum threads dealing with a range of topics from the garbage collector, loadlevelasynch() and even a few related networking ones. All seem to point towards validation of Zumwalt's idea, in that in each case individuals suspect a threading bug.

Has anyone poked around Novell's Bugzilla for candidate issues in Mono 1.2.5?

Things like - Bug 347837 - Value of ThreadState not consistent perhaps?

WTB: Ability to search Unity's bug tracking system.

 

So far I am making a complete baseball game with a full implementation of Unity Networking and I have some of the above mentioned problems.

Although I have been able to overcome all the master server problems using some of the workaround posted int he forums. I also have adapted the network prediction script on the wiki to get nice network prediction.

I am very hopeful they will work with Robur and work out the remaining bugs. I really wish they would take these bugs seriously since Robur is a bit of a guinea pig for the rest of us.

 

Since this thread has been running for so long; Here's my full list of known bugs and easy/important networking feature requests. I hope we can see some changes in the next unity release, no promises can/have been made yet though.

http://www.m2h.nl/files/Unity_networking_bugs_feature_requests.pdf

 

lest this thread, dropeth into obscurity....

 

Yikes, the networking has been broken for a long time. Hopefully fixed soon.

 

I've come up with a solution for networkView's being broken on new clients just after joining.

on the server, call networkView.enabled = false, then yield a frame, then call networkView.enabled = true;

Works for me like a charm, and doesnt require re-allocation of networkviews.

It should be easy to detect if a networkView is lost and do the same thing. Let me know if this helps.

 

No way! It can't be that easy

I have tried manually toggling a NetworkView's enabled state in the Unity Editor while functioning as a server without noticing any alleviation of the symptoms on other clients, but I will definitely look into this again.

 

I honestly would have taken forever even figuring out what the problem was without this thread, so it's the least I can do to help.

 

Horsman;

I would love to say that disabling and then re-enabling NetworkViews solved the main issue I am now experiencing with Unity's networking, but it doesn't

When you say that your NetworkViews were "broken", do you mean that they would send RPCs just fine but wouldn't serialize data in unreliable or reliable streams?

-Aubrey

 

Hi Robur,

This did work until there was more latency in the system, and then stopped working :/ Surprisingly, the important part was yielding a frame when the networkview was created, not when it was sent to new players joining. I'll investigate more soon.

The problem can be summarized in the following way:

If two players are connected to the server, and the one that connected first disconnects and reconnects, that same player does not receive reliable or unreliable OnSerializeNetworkView streams but does send and receive RPC's. This is with manually allocated NetworkViewId's.

There are a number of other ways to trigger it, that seem to depend on some factors related to the functions allocating the networkview. I've switched to using RPC's, and have so far not found increased lag to be a problem. In another project,I'm using Sockets with the polling style methods, it works quite nicely as well.

 

The same happened to me with Network.Instantiate() and manually instantiated ids. the only difference was that the reconnecting player didnt broadcast his unreliable OnSerializeNetworkView stuff anymore, but received all the unreliable stuff from other players.
So the player who is unable to broadcast his OnSerializeNetworkView, appears to be invisible on all other players, but not on the server.

I couldnt find an workaround till now
The strange is that this happens for reconnecting players only/most of the time?? Perhaps the ip/networkid of the player is causing trouble on reassign or reconnect?!?

In blobfoot, this happens if there are more players than just 2, connecting and disconnecting.

Ethan

 

Hi Larus - thanks for the update, that sounds really good!

 

It's probably bug B3 on my list ( http://m2h.nl/files/Unity_networking_bugs_feature_requests.pdf?a ).
To fix this(workaround); whenever a new client connects, execute this code on the owner of networkviews (server + maybe some clients..but it can't hurt to run it *everywhere*)

Code (csharp):

1.  
2. @RPC
3. function ResetNetworkViews(){  
4.     for (var playerInstance : PlayerInfo in PlayerList) {
5.       if(Network.player==playerInstance.networkPlayer || Network.isServer){
6.          for(var oldNetView : NetworkView in playerInstance.transform.GetComponentsInChildren(NetworkView)){
7.              var newNetView : NetworkView = oldNetView.gameObject.AddComponent( typeof( NetworkView ) );
8.              newNetView.observed = oldNetView.observed;
9.              newNetView.stateSynchronization = oldNetView.stateSynchronization;
10.              newNetView.viewID = oldNetView.viewID;
11.              Destroy( oldNetView );
12.          }
13.       }
14.    }  
15. }
16.  

Note that I'm using my PlayerList and PlayerInfo here, you need to maintain some kind of list to all the networkviews.

 

@larus:

Good to hear you found sth on that topic to fix. I think this could solve my problem. *HOPE*

Is there any targetdate for this release?
Weeks, Months... Years?

@leepo:

Mh, every player allocates his own player, so everyone in the game needs to call this code-snippet on his player's networkview if someone new joined the game? did i get that right?
i'll have to try, thx for help

E

 

Glad to hear that you found my testcase useful, Larus!

I am really looking forward to the update. The potential of my game's networking finally being something like reliable after several years of headaches is quite exciting.

 

Three thumbs up for this news. Here's hoping for a long list in the next changelog under the networking section.

 

I'm not Larus but I can chime in here with information. Think more on the weeks to a few months range, not many months nor years. I'm being vague as things are still in flux and there is no specific release date to share publicly just yet. But rest assured, it's coming.

 

I am building my baseball game on Unity networking trusting that robur will torture them enough to get the problems fixed. I just popped a major boner. This sounds promising....

 

Now that 3.0 has been announced, I am really on edge for a bugfix 2.x release or the opening of the 3.0 beta...

With the most massive networking issue reported as fixed, an upgraded version of Mono, and the new iPhone networking, 3.0 could finally get networking right!

 

Ya that would be superb.

 

All we really know for sure is the following:

1. There is no patch that fixes these issues. There are hints that a patch will arrive, but even when these hints have been made they have clearly stated that it will not solve all issues.

2. A lot of promises have been made about the functionality that 3.0 will include. But even there the plan is not to have all this functionality available in the first release. So we really haven't been given any guarantee of these issues being resolved.

3. Unity has never guaranteed backwards compatibility and do not support older versions of their software (ex: you can't get a fix on your 2.5 license).

4. They have never released minor updates more than twice a year for any particular platform.

5. Their licensing model changes on each major release.

I won't draw any conclusions from this. These are just an assortment of facts.

 

aside of point 5 which is not a fact but something you made up as it seems for fun or confusion.

The licensing model for 3.x is the same as for 2.x, just that there are now more addons available than with 2.x (where the asset server client was the only thing present)

 

I disagree.

A subsection of your license agreement are the terms under which a product is supported, which is a big factor that companies should take into consideration when purchasing software. It should not just be based on the terms of use.

By this definition the license for 3.0 is very different, because what you buy now is on pre-order. You are buying with no guarantee of any features actually being implemented. You get access to betas, but betas aren't supported. And the shop doesn't allow you to buy a 2.x license anymore, it only offers a product that does not exist yet.

As for 2.x there was a significant change in the licensing model from 2.5 to 2.6 with the discontinuation of the indie license.

You can argue that going from paid to free seems like an improvement for the customer. But the fact is that the terms of the agreement have changed, and that is all that I'm saying with point 5. I have not attached either a positive nor a negative connotation with the statement.

 

Ok, constructive suggestion time:

Maybe its time that Unity acquires a networking API from a third party developer... Let's say Photon for instance.

That way they could focus on something that they find more interesting?

 

nothing changes for the unity 3 license. nobody forces you to invest in early adopter licensing. you can wait until its released and upgrade then, you can wait even longer and upgrade later.

all up to you.


the difference is that you can get it for less than the regular price and in addition get granted access to the beta builds, something that previously was a "exclusive club"

so realistically seen your "fact" is not only wrong but double wrong

 

I'd have to agree with Dreamora.

Indie wasn't discontinued. Indie's price was just reduced to $0. The license still exists as Unity (Free). This licensing still exists on the Unity license comparison page.

Also, your purchase of the 3.0 license is what grants you (unsupported) beta access. That beta access isn't the actual 3.0 license.

Exit Games (Photon/Neutron) would be an excellent 3rd party to go through, but they're stuff is very much in-house. It's subscription based, and most of it is hosted on their servers. It doesn't seem like they give out their code. They're business model is based around keeping it private and on their servers.

However, the idea of a 3rd party networking solution sounds good.

 

With all due credit to my esteemed fellow forum members I reduce my fact list to 4:

All we really know for sure is the following:

1. There is no patch that fixes these issues. There are hints that a patch will arrive, but even when these hints have been made they have clearly stated that it will not solve all issues.

2. A lot of promises have been made about the functionality that 3.0 will include. But even there the plan is not to have all this functionality available in the first release. So we really haven't been given any guarantee of these issues being resolved.

3. Unity has never guaranteed backwards compatibility and do not support older versions of their software (ex: you can't get a fix on your 2.5 license).

4. They have never released minor updates more than twice a year for any particular platform.

 

We already have a 3rd party networking solution. It's called Raknet.

What's needed is a perspective within Unity that product maintenance is just as critical as feature creep.

 

Is this small 2.6.x bugfix-release still planned?
Any news on this?

 

I don't think this is happening anymore...

However I did get another friendly email again today, encouraging me to pre-order Unity 3...

My guess is that they are focusing on their android client which, you'll agree, is a way cooler than getting this to work.

Maybe the future is HTML 5?. Google Chrome 5 now allows secure socket connections, maybe in combination with Web-GL we could have an open standards engine to develop with in the future.

 

I dont agree!

I want that 2.6.x update!

It would be horrible if the bugfixed 2.6 version would be the 3.0.
This would mean we would have to pay again for features we already paid for in Unity 2.0. (I wanted working networking in Unity 2.0 or 2.5 or at least in 2.6 or 2.6.x).

 

We should be so lucky if they actually make an effort to fix networking in Unity 3.0, never mind having a 2.6 code-branch which they would have no intention of maintaining going-forward for a couple of disgruntled customers.

As far as I can judge their thought process, I get the feeling that they are doing a big android drive so that they would still have presence in the mobile environment even if i-phone decides to pull the plug on them.

 

I suspect that lots of the issues with the networking system are related to the currently implemented version of Mono, and this may not be something that would be feasible to upgrade in the final 2.6 bugfix release.

By all means, Unity: please give us a final, fully functional 2.6 - but don't let it slow down the 3.0 release

I will be quite happy if they have given the networking enough love to make it functional in 3.0 - including those fixes in 2.6 would be icing on the cake.

I feel your pain Ethan - I don't undersand why Unity advertised networking as a major feature in the 2.0 branch, it just wasn't fully baked... Quietus is right on: Unity's priorities should revolve around eliminating bugs to make their product rock solid, and only then adding awesome new features.

 

We have absolutely no idea what they are fixing and doing other than what has been mentioned. For all you know they are making a new networking system (Highly doubtable, just an example).

 

I can understand why you'd prefer to have the networking issues fixed in 2.6 but to be honest I'd also rather have all focus on the 3.0 version which IMHO should also update to the most current version of Raknet. It would be economically insane to update Raknet in 2.6 and it would just be as insane to try to fix issues in 2.6 that might be fixed "automagically" by simply using the most recent version of Raknet for 3.0, maybe with a somewhat more "accessible" approach than what was done in the 2.x version (i.e. Raknet being somewhat more "exposed" so we can actually use Raknet instead of just what Unity offers ... which IMHO would almost be like "new networking" even though it could be done in a way that doesn't break compatibility with the old approach).

So while I see your point and find it valid from an individual's point of view, I'd still rather have all efforts focussed towards 3.0.

 

Exactly...

You can only evaluate the product once it has been created and then decide if it has the functionality that you require.

That is why it doesn't make any sense (unless you have lots of cash to throw around) to pre-order. Because historically we know that Unity doesn't necessarily deliver what it advertises.

 

Well then i don't understand why it was announced that way. If it makes sense or not.

Let's see if deferred rendering will work in 3.0 ... or perhaps we have to wait for Unity 4.0, the most awesome polished super release ever (just like 2.0 and 2.5 was!).

Enough complaining for today ... i know that Unity is just made by humans, too.

 

OOoh maaan... you just destroyed the idea I had about 200 monkeys sitting in an office, randomly hitting keys on a keyboard...

 

I think both 2.0 and 2.5 were incredibly great releases if you look at the overall impression (so were 2.1 and 2.6 - I would have expected those to be major releases, at least 2.5 and 2.6). However, in any software product as complex as Unity, there will be bugs in some areas - and in an area as complex as networking, that's even more likely, as unfortunate as that may be.

To me, networking maybe not having the priority at UT that I personally would have liked means that there's simply not as much demand for networking as one might have expected - which is quite understandable given the complexity of the subject matter. I'm not sure how well it works for what it was designed for (very small-scale spontanuous multiplayer sessions) but I would guess that it will probably work well-enough for most of those cases. Otherwise I'm pretty sure that the priorities would have been shifted accordingly.

In any case, Unity's networking is certainly good enough to get you started and once you've taken that hurdle, there's viable alternatives for the networking layer that are specialized to just doing that. Maybe it was a mistake to advertise networking as it was advertised but as you mentioned: Making mistakes is just natural - everyone does it ;-)

 

(a) I don't know the status of this issue myself as I'm not a networking guru in Unity, but at this point you should not expect any more 2.x releases, it's all about 3.0 at this point (might not be the reply you wanted but it's factual and true so you can base your plans off of it). And as to your notion about a "big android drive", well, you just don't have any idea how our team is structured then. I say that because we have our primary dev team focused on Unity 3.0, we have our iPhone dev team focused on 3.0 and we have yet another separate team focused on Android. Different teams handle different platforms so that one platform isn't suffering because of focus on another platform. I'm not wiping away any concerns over these issues, I'm simply stating that whatever is or isn't happening in this feature area has *nothing* at all to do with Android so much as it's likely to be about 3.0 (desktop/web).

 

Honestly, just put the issue a side until 3.0 is released anyway, the mono update means tons, including threading fixes do to the way mono changes were made over the years between the original version that 1.x and 2.x were on, and a revamp to 3.0 opens doors. I have enough client / server prototypes using RakNet right now, I am just waiting patiently for 3.0 to hit the shelf so that I can drag / drop and see what happens.

I suspect that what I have working, should work in theory to allow a stand alone raknet server with a client that is not internal to unity but works hand in hand with unity, although, I could get the wonderful unity death when I place it in unity and run it, but that only means starting from scratch again, and for me, no big deal. Lets just enjoy life until 3.0 is released, then go yell at goldfish if we need to.

 

So did Unity3 fix anything that makes unity's networking 'dysfunctional'?

 

I think only 4-6 are actually valid bugs as pointed out by people running their own master servers are doing fine. And no, nothing has changed with networking

4, I've occasionally had issues with. often restarting the server will fix connection issues.
5, I just don't use serialization. I like to control every little detail of network data and when it's sent, so I only use RPC's which work great.

6 is the only one that I am currently a bit sad about. Yeah, it can be worked around using your own instantiations with rpcs and such, but it'd be nice if network.destroy did remove the rpc call for the instantiation from the buffer. At the very least, this should be mentioned in the user manual.

 

http://en.wikipedia.org/wiki/Infinite_monkey_theorem ?

So, the Network of 2.6 is the SAME as 3.0 ?

 

If there are any new or outstanding problems with Unity 3.0 networking, then please start a new thread for them.