Feedback Another 2 bugs. Why is this netcode out of preview?? RANT

I am porting a really simple, very small game to networking. When I noticed this was out of preview, I was so keen on checking it out. My expectations weren't very high, I mean, let's face it, anyone who uses Unity for a long time has had their expectation bar lowered to the ground.

However, I expected simple things like, I don't know, scene object synchronization after late-connection not being broken, or being able to do things like picking up and throwing stuff around to be done fairly easy.

What I was greeted with instead, was networking which requires me to download scripts like "client network transform", scattered around the internet, just to give player ownership over their own position, because it's not in the package. Hey, I read that there's a reason for that, so I tried my best to ignore the shortcomings and continue.

I tried parenting NetworkObjects, to learn that there's 50 restrictions on that, had to rewrite Animator because it wasn't syncing properly and was sometimes getting glitched. Learned that NetworkAnimator.ResetTrigger actually SETS the trigger locally, and 100 other bugs that I could count left and right.

Now, I'm here to report 2 more bugs that I found just now, namely, when ownership is changed from client to host, the host gets 'OnLostOwnership' message for some F***ing reason, even though he gained it.

On top of that, Why is there "Ownership" on NetworkObject AND on NetworkBehaviours?
Even if there is a reason for that, there's a bug that when player disconnects, all the NetworkObjects owned by the client are given back to the server, but only partially, because networkbehaviours are not, which generates even more issues, and in overall is confusing, and not explained at all in the docs.

If I wanted another mirror, I'd just use mirror, at least I'm already familiar with it. But to spend time learning new fancy networking, just to hit wall whenever I turn, is just disappointing.

 

You're in this thread but others aren't, so I'll chime in my response here about the "change in mindset" regarding network programming: https://forum.unity.com/threads/pla...arder-than-it-should-be.1343492/#post-8483444

I cannot comment on whether this is correct or not, but it could very well be. Consider that this message was sent from the server to all clients. The host is a client, too. You will encounter things like that more often than not specifically for the host because he has split personality issues.

Now you could argue that Unity should consider the case where the server is also a client (the host) but I can imagine that would be a tremendous mess with littering if/else everywhere to consider cases where the server is also a client. Normally, you'd program a server-side of things and a client-side of things. The special case of "host" is something the developer using Netcode has to deal with. Because who is to say for every possible event whether the host as the client shouldn't receive that specific message?

Things like OnLostOwnership - even if it seems illogical on the surface - may actually be necessary to be sent to all clients including the client-host for the simple fact that the server might decided that "no, you didn't lose ownership because by authority of my simulation I hereby command you to deal with retaining ownership of said item". You want to know why? That's another RPC you'd have to send me ...

And so does the host talk to itself. If it were human, he'd be under psychiatric evaluation. But this is Sparta! Uhm, networking ...

Once you get into the mindset that the host is simply "special" and treat him like a client and the fact that every client receives all messages/events by default, it is a simple matter of checking for IsServer/IsHost/IsClient in RPC calls and the like.

You do have to constantly think about that and it's easy to make mistakes, this is the bane of network programming. But over time you'll get used to it.