How is UNET as of now?

Havn't touched UNET for a year because how bad and unstable it was.

How is it now, is it more stable? Or is it still "alpha"?

Have been using PUN since leaving UNET but I would like to come back to UNET.. Is it anywhere near production ready?

Anyone ditched UNET and is using UNET again?

 

If you've been in any of the recent threads asking the same question, not a huge amount has changed in all honesty.

What I have noticed myself though:

• documentation has been improved in some areas, but there's still a lot of work to do on that front
• we've had some performance boosts in the LLAPI, although some have expressed performance loss in the HLAPI
• there have been some additional features added, mainly revolving around the ability to monitor the bandwidth usage

As far as whether it is "production ready", it always has been. It's just down to how you use it. For example, if you only plan to use the LLAPI you'll be fine since that part of UNET is solid and works as expected, it just lacks documentation. Certain parts of the HLAPI are still a tad buggy and performance heavy, but that is generally the nature of a service that is designed for convenience.

If you are using PUN, which is the closest thing to an out-of-the-box multiplayer solution (at a massive cost in potential performance!) then the chances are you're not going to like UNET despite it being a better solution if you use it correctly. So you may be better off sticking to PUN, unless you are brave/patient enough to venture back into UNET.

Hopefully this helps, good luck!

 

Our experiences have been mostly positive. We did start using HLAPI for everything, then had to go and move the more performance/data heavy bits to the LLAPI. And, yes, the HLAPI is ... well, i found you have to read the actual code to understand what is going on there, if you are doing anything at all beyond the most general use of it. But yeah, i'm pretty happy with the networking stuff overall. Sad that we are missing a built-in NAT Punch-through solution, but i know Unity is working on that, and is also working on integration with Steam's networking API/solution.

 

I've only done some basic UNET stuff to try it out but what I did create worked fine and made sense. I stayed in the HLAPI. I'd like it if the source was available for some of the components so we could see exactly what is happening. (is it?)

The team building it is only four people so it's pretty slow, I think that is why people feel like nothing is happening. Patch notes are generally slim on UNET details too, but again, it seems to actually work fine when you use it correctly.

 

I'm just bewildered by the entire mess. Might throw darts and see what sticks.

 

I spent a huge amount of time trying to work around HLAPI bugs and ended up gutting the HLAPI bit by bit because I couldn't work around them. My advice would be not to use the HLAPI at all (Specifically I had issues with SyncVars, SyncList, NetworkTransform, NetworkAnimator, Command, ClientRPC, and NetworkBehaviour].

The biggest UNET issue I had is how NetworkIdentity.observers are dropped during scene transition. This causes SyncVar/SyncLists hook/callbacks to fail and ClientRPC to also fail and only be sent to some client. SyncVars can also become permanently de-synced when a new client connects because it clears dirty bits.

The other big issue is how data transfer on an object is not allowed to be bidirectional (all data must be Client --> Server or Server --> Client) but I needed it to be both (i.e. motion of the player is controlled by the Client but the animations/stats/inventory are controlled by the Server). This is a design issue, not a bug.

And there's a lot of other less severe issues as well.

 

RMFE. Again.

HLAPI works great except for edge cases which are fixable since the source is available. It's sad to see people discovering these issues and not fixing them.

 

There's no guarantee or communication around HLAPI, so no... wish there was more docs and clarification so I *could* at least try. Currently, it's hard to tell what Unity envision as the HLAPI.

 

I don't understand what guarantee you're looking for (it's already an API, so anything we care about as end-users is not going to change,) or communication besides lettings us know they don't have a full time dev. Sorry that keeps you from trying. I must be doing it wrong, because I just submitted fixes for the first two real HLAPI bugs I've run into personally and can now move on with my game. There's no magic or even particular complexity to it. It's sitting there waiting to be extended and fixed like any other open source API.

As for docs, sorry. Anyone can complain about docs, no matter how good they are. I've said this before. The docs would need to be able to spoon feed knowledge about how networking works, game networking works, and basically how to write code to make some people happy. Which would render them useless for the rest of us. Note the two sections on Unity docs: guide and API. I read the guide 1% of the time, and the API docs the other 99%.

And not to be a snob, really, cause I hate this answer, but the source code is all the documentation you ever really need.

 

Hey guys, a bit off topic< I've already created a thread about it, but what is more reliable [TargetRpc(channel = 0)] via default Reliable Sequenced channel or connection.Send(networkMessage)?

 

Haha, totally off topic! Thank you! I believe that Send will use the reliable channel anyway, although that's probably configurable. Any difference would be in the code that handles the messages, so they're not comparable exactly. If you're having network drops, maybe try the latest beta or latest patch. The most recent releases have some kind of fix that applies to reliable channel.

 

Hi, thanks for your reply, yes Send will use reliable channel by default. I thought that something wrong with TargetRpc) So, does use of TargetRpc for inventory handling could cause any troubles?

 

If you run into the issues @Zullar mentioned above, then yes. If you use Send, all that code is replaced with yours, and all the bugs will be yours also. I use Send, Commands and Syncvars. I don't think TargetRpc existed when I started, so I haven't used it. I haven't run into those zullar issues with syncvars, and commands (yet) but I do have to take care not to send traffic before Network server.Active is true.

So the answer is whichever you want more: potentially spending time debugging someone else's code, or writing some of your own.