Discussion in 'Multiplayer Networking' started by dylanh7244, Dec 13, 2016.
Quick question! Will the upcoming NAT punchthrough work with WebGL?
Is it possible disable LogIng for UNET?
So the problem is you destroyed an object on the server but it was not destroyed on clients, so you keep getting network messages for that (now non-existing) object? I don't remember hearding about of this kind of issue before, are you using NetworkServer.Destroy to kill the object on the server? Besides that the server should of course not crash just because it received some unknown messages, that's another issue. If you are using spawn handlers then that fix you mentioned in 5.5.2 might help. Have you filed a bug report for this? If you have a repro case/project it would help a lot to receive that in a bug report.
There is a log level field in the NetworkManager inspector (if you are using that), or you can set LogFilter.currentLogLevel to LogError.
It works on UDP based connections (which the transport is based on), and since WebGL is using TCP based WebSockets the current implementation can't work there.
Thanks dev, I already figured out, that Debug is going in One frame. And I already change my log level. Everything works like a charm.
My respawn method works great now.
It's all good now, No errors, it was only a Warnings that took a lot of CPU usage
YOU EXIST!!! Thanks for the update Honestly, docs and a working, in-house, minimal demo (read: The opposite of "Tanks!"), including a REAL lobby -- that's where 1/2 the issues lie -- with standard callback examples -- would satisfy "the beginning" of redeeming UNET: Because there's no sufficient docs/demos, not even the community can help each other.
Unfortunately I agree with this guy. One of the biggest woes of UNET are broken promises. I remember Host Migration "going to be fixed soon" (quoted almost a year ago).
That's wonderful, but if there's no docs or support (although kudos for the recent attention), there's still a long way to go.
Although this rocks, back to the "KISS" essentials: docs, minimal in-house demo, working host migration would be even better (as amazing as that feature is).
I have one simple question for you that I've been asking since June of last year: HOW do you properly disconnect using HLAPI in the lobby?
The core files that needed updating (mostly having to do with lobby) were not in 5.5 -- but I can't speak for 5.6 (although these aren't 1.5 years apart, I saw a # a while back that I'm too lazy to go back and find). For example, this was the only example we had to go by to figure out UNET:
5.4 vs 5.6
Anyway, stick around Glad to see some transparency and progress.
This is the latest in a handful of threads I've seen just BASHING either Unity or specifically the UNET team, whatever that means to people. I assume most of you have worked in software and understand the realities of shipping a product, good or bad. Networking is complicated. I see a lot of complaints that stem, ultimately, from them not understanding networking or UNET. A few of those complaints do at least try to unload the blame on the supposedly bad documentation, but this isn't even really fair IMO. The information has been there for years, as has the source, as have a lot of resources on this forum that have figured most of these things out and get tired of answering the same questions about authority or whatever it is, only to have some angry customer jump in and say how stupid it is that UNET even has player authority. Well, ok. I think Unity's biggest mistake was giving customers something as complicated as networking and telling them it will be easy (or bug free.)
Full disclosure, I haven't shipped a game, UNET or otherwise, so I'm always waiting to see what new frustrations await. But from what I can see, the very few legitimate complaints or bugs in UNET are hammered SO HARD by a really angry minority, that it overall gives the impression that UNET is fundamentally flawed and Unity are a bunch of jerks. UNET is what it is. If it doesn't work for you, move on or change the code yourself. Unity are not a bunch of jerks any more than any other bunch of computer people are. That's my opinion, formed from trying to use Unity for about 3 years and schlepping software while getting blamed for other people's problems and mistakes for about 18.
You're probably confusing things here. "Tanks!" is a multiplayer demo made by Unity, obviously using UNET as the network provider. I have no information that this is going to change any time soon. "Tanks Multiplayer" is an asset made solely by us, supporting both UNET and Photon. We've explained why we have added Photon support to it, and why we would not use UNET for production in its current state in that blog post. Although the guys over at Exit Games used Unity's Tanks! images in their blog post (I've only seen this now), these are two different assets. I'll contact them to correct this.
Interesting thread. I have been working with UNET 10 hours a day for almost two years now, working on uMMORPG, uMOBA, VOXL. Here are my thoughts on UNET after all this time:
The LLAPI works. And if it doesn't, you can contact alex abramychev, he will fix the bug and probably thank you for it.
The HLAPI would be the perfect solution with SyncVars, Commands, Rpcs. I used it in all my projects, and there is a reason for it. It makes development 10x faster and the code 10x shorter. There is absolutely no doubt that this is the right concept for Unity networking. Once you understand it, it makes perfect sense.
The problem is that no one cares about the HLAPI. Here is some simple proof: I reported the highest rated HLAPI bug an enternity ago when @seanr still worked here. A critical bug that hasn't been fixed for over a year, with the usual excuses. This is just one bug, there are countless of others. Or what about NetworkTransform?
We see very clearly that no one here cares about HLAPI bugs and that every promise is an empty promise. The question is, why? Let's think about the possible reasons:
The HLAPI developer(s) simply aren't skilled enough to deal with it. From what we have seen in the presentations, this is likely not the case. All of them worked on major networking projects before coming to Unity.
The HLAPI developer(s) could be part of the 80% group of programmers. They do the work to get paid, and go home worrying about other stuff. Life is difficult, this is understandable and definitely not the programmers fault. It would be Unity's fault for hiring the wrong person. But then this is Unity, the #1 game engine in the world. Why would they hire someone who isn't driven to push out the best networking solution?
Focusing on the wrong features. They mentioned working on steam integration, nat punchthrough and other weird features, essentially building a skycraper on top of a broken fundament. This is a common beginners mistake and it takes only so many community complaints until the fundament is thrown out and replaced with a better one. As far as we know, neither of the UNET developers is a complete beginner. We can assume that they are aware of the problem. We can assume that they would be skilled enough to come up with a new, more simple and more solid HLAPI. Yet they don't, so it might not be their decision to make, indicating a higher up problem.
Unity focuses on the multiplayer services. Unity is a big business. They need money to continue their work. Telling the UNET guys to focus all their efforts on the multiplayer services makes perfect sense from a business perspective. New customers don't know about the state of the HLAPI, so they would likely be happy to pay. If given the option between making thousands a month with a S***ty HLAPI and lots of services vs. the option to make 0 a month with a great HLAPI and no services, it's the perfect explanation for the UNET situation here. It's sad, but let's be honest, who wouldn't do the same?
I think it's safe to say that every sane person here would rather have the UNET devs spend 100% of their energy on the LLAPI and HLAPI, making it absolutely bulletproof and simple while letting the community come up with nat punchthrough, steam integrations, hosting services and so on. It makes sense to care about monetization instead, but at what cost? UNET is about to fail big time, especially with the new Gamesparks partnership on the asset store.
This whole situation sounds like a typical case of letting managers make programming decisions. Correct me if I am wrong, but I just can't see any other reason to make any sense. There is just no way that a 4+ people team of networking professionals isn't capable of developing a good HLAPI, when one guy is capable of developing a good LLAPI.
Seriously Unity. Pick the most skilled developer from the UNET team, double his pay, lock his office door and make him rewrite the HLAPI while spending 30 minutes every day on this forum. This is not AI, not rocket science, not physics, not self driving cars. All it takes is a good architecture. Every single problem can be debugged, every packet can be traced. There is no reason why the HLAPI has to suck if someone would care about it. There is no excuse.
Agreed. I've been a part of the developer world for a long time and unfortunately this is a recurring theme that I've had to witness a few times.
Let's hope they get this sorted out...
Maybe someone from the Unity team can comment on this? (or send a PM )
Thanks for the clarity, great work guys.
I can see why you might think that, but it simply isn't true. I don't think it is fair anymore to ask you all for faith so I'll just tell you how it really is.
We think of UNet currently having four parts: HLAPI, LLAPI, Matchmaker/Relay (Server), Dashboard/configuration (Web)
At Unity, we really believe people should work on the things they have a passion for because that's how you get great things to happen. You see it yourself with how you just described the LLAPI and Alex.
The team has four engineers. Total. Things were covered like this:
HLAPI - Sean R
LLAPI - Alex A
Matchmaker/Relay - Jeremy M
Dashboard/config - Larus O
Each of these guys has a passion for their areas and work tirelessly to make their parts amazing. Our friend Sean had a great opportunity cross his path and we are happy for him that he got to pursue that. Unfortunately, that left us with the following
LLAPI - Alex A
Matchmaker/Relay - Jeremy M
Dashboard/config - Larus O
See the problem with HLAPI? That was the state of things at the start of 2016. And it might even explain the perception that no one cares about HLAPI. We do though, as I'm about to explain.
Of course we immediately tried to find someone with the skill and passion to make the HLAPI everything we all wanted it to be. All you guys with tons of time and experience in this industry already know how hard it is to find and hire real experts so I won't bore you with that. But then we got really lucky and found the perfect owner for the HLAPI. Unfortunately that person had to return to a previous commitment and won't be back for a few more months. We got lucky again and found another great engineer to join us, but their passion is more for the server side of things. So right now we have the following:
HLAPI - Larus O/Michal B
LLAPI - Alex A
Matchmaker/Relay - Jeremy M/Michal B
Dashboard/config - Larus O
That's still just four guys to run what is now a Live service. And still no proper owner with a passion for HLAPI. But we are hopeful the expert we found previously will have his previous commitment satisfied and be able to return to HLAPI a few months from now.
But we haven't been neglecting HLAPI. The team we have now have all been pulling together and fixing alot of the bugs in HLAPI, which you should have in 5.6. They also spent a good amount of time just focusing on docs and those are also coming in 5.6. That doc update is pretty good but not considered by us to be done. We are resolved to always be improving the Multiplayer docs together with the internal Unity Documentation team.
As for the other features being worked on, that comes from other forum members and game teams trying to ship, making really good cases that those features are desperately needed. You may disagree from your own perspective, but we can see a much broader picture and make decisions for the greater good of all our users with the manpower and expertise available to us.
So there you have it. That's how it really is. I hope that all makes sense and gives you all a better feeling about Multiplayer and how the future is going to be ok after all. Also, check out the blog post Larus just made to hear more.
For me this is not the case. For me the most important features are the low level connection robustness, NAT punchthrough, and steam support. What good is the HLAPI if I can't connect to other players in the 1st place? As long as I can connect to other players, and send data using MessageBase, then I am happy. I do not need any HLAPI. Just speaking for myself.
I believe HLAPI pre-packed things (like NetworkTransform) will never work for the majority of players because every game is going to have vastly different controls/physics. So (in my opinion) there isn't much point to Unity spending time on this.
Agreed that having a world-class LLAPI should be the #1 priority. And the 5.6 network transport + NAT punchthrough in Unity 2017 seem to be bringing us exactly that.
I dislike the overly-simplistic code architecture that the HLAPI imposes, even though I understand why it is like that (for accessibility). I prefer recreating something that is similar to UE4's Gameplay Framework, with servers and clients being separate objects instead of having an omnipotent NetworkManager, online and offline being seamless, and with a networked "Actor + ActorComponents" system that replaces NetworkIdentities and NetworkBehaviours. And with all the known bugs, I think it's just safer to make my own system in order to have complete control/knowledge over it.
Also big thanks to @Erik-Juhl for explaining the situation and clarifying everything. I think people will be much less inclined to complain if they know that the HLAPI is waiting for a lead engineer before work can really resume. Sure it's not an ideal situation, but at least now we know what's going on
My vote is 100% for this, even if I am a bit biased. @Zullar I see where you're coming from but the community can solve these problems. The community can't expand on or solve fundamental issues with the HLAPI / LLAPI. And damnit I really wanted to write that steam integration plugin..even if I never have time..
i agree with @Zullar .... unet should just simply work out of the box without dependence on 3rd party, closed source plugins.
i mean really...could you imagine if the rest of the unity engine were dependent on spending $50 for a 3rd party graphics plugin just to draw something on the screen? or another $55 just to play audio? controller input is another $25. nobody would use it. this is why a lot of people don't use unet.
unity is successful because you don't have to worry about boilerplate issues like rendering images, playing sound, and managing input. as far as unet is concerned, being able to connect players to each other in an efficient manner should be considered a boilerplate, high priority issue. (the relay servers don't count...they're bad)
Here is their new blog post on unet
Thanks for the clarification @Erik-Juhl, this brings more transparency to the table. I guess many of us in the forum suspected some kind of gap after Sean left.
The current improvements on the LLAPI are a great thing! I also think that a stable and bullet-proof LLAPI is very important as it is the UNET core at bare bones. Still, I really hope you get back to 100% fuel on the HLAPI part as well soon, because I think it is important too. It's the thing that might get many non-expert people into networking in the first place. Also, a nice and optimized HLAPI is able to shorten the code and make a programmers life much more easy. So, I believe it is 100% worth the efforts to invest further work here to improve it and just make it as good as possible.
Also, I like to say that I really appreciate the current features which are to come. I agree that the community can achieve amazing things. Still, we all know that there is always a certain risk when relying on third party assets. For example, loss of compatibility and support at some time. For some assets, this risk might be very low though, because there are amazingly dedicated community devs out there. Ideally, I like the idea of possible collaborations between the official UNET team and 3rd party asset developers in order to achieve best-possible solutions at a faster speed, and then get them officially integrated into the whole UNET framework. Maybe, this can be an option somehow? At the end of the day, I would like to see UNET include all the features I need to ship a stable multiplayer game. Just my 2 cents though.
I still don't really get what people are griping about or why they're trying to tell Unity how to allocate their resources. Bulletproof LLAPI? It worked before, they've improved it, let's move on. "Improve" or "fix" or "whatever" the HLAPI? Pfft. First you have to get everyone to agree on what they want it to do. The users on this forum don't want an HLAPI, they want a P2PAPI or a client-server API, but whatever it is, they seem to want it all spelled out for them and anything that doesn't work as expected is a bug, poor design, docs, whatever. Let's be real. The services are what don't work, and even that is really a matter of mismatched expectations more than something the doesn't "work." So don't use them. Maybe educate yourself about what the APIs do (and can do) before posting a bunch of stuff claiming that Unet doesn't work, will never work, isn't supported...
Hi, you must be new here. Many of us were promised docs, demos, and improvements. However, there has not been. The only demo has been an outsourced production-ready (opposite of minimalist like all their other demos) demo that doesn't even use the advertised features.
Host migration was (is?) still advertised as a feature, although confirmed by a dev broken almost a year ago. "Fixed soon!" Nope.
Support tickets were unanswered, for even the most basic questions.
Community can't even help each other because there's no proper docs and no one even knows the standard.
SyncVars randomly don't work.
Lobby features simply don't exist -- they just "left it" 1/2 working. The devs still didn't even answer how to properly disconnect - something people have been asking for the standard for 6 months+ now. I asked it again above, but the answer was skipped.
That said, @Erik-Juhl -- simple question: What is the standard of how to properly disconnect from a game/lobby?
^ People are upset because they don't even know simple standards and no one will answer when asked, just like this question above.
These devs above answering? It's the first devs that even answered a real mplayer question about UNET for the past year (not even exaggerating). No staff even roams here. Look when I posted OP and how long it took to get their attention!
Why are we mad? Broken promises beyond comprehension, no docs, no demos, and overall NOTHING compared to the usual standard of Unity. These feature sets shouldn't even be advertised at all - and it should be called alpha.
Many of us aren't just making games for hobbies -- we are spending time and effort relying on Unity to pay rent. We took a chance out there to use this new technology that they SUPER HYPED UP and pretended they are all over it. I follow Unity's usual standards and assumed their word was true. It was not. I'm sure I'm not the only one upset for these very reasons.
I'm with Photon now and I'm never going back. However, I still talk about UNET because I was really getting into it and hoped that it worked. I still hope it works. I also still hope that they communicate better publicly (that blog was a good start) that this is a VERY EARLY, nearly unusable alpha. We wasted months on UNET and my entire purpose of this thread (originally posted when I still used UNET) is for hopes they keep their promises so other indie devs don't suffer like we have.
Repeating something doesn't make it correct.
Since this gets brought up constantly, great place to start. Thank you. Host migration is only broken using the relay service, I believe.
I see the same closed tickets linked to, over and over. Let me translate. "Works as designed" means you are not using the code correctly.
While that's only your opinion, it's also pretty provably false. This forum is littered with messages with random users helping each other. That's why I'm usually on here, rather than to abuse people over something I don't understand. The docs cover everything I've needed to know, and when I didn't understand something, I was able to get help with it here, usually just from searching for an already answered question. The "expert" forums like SO are also full of UNET knowledge. Furthermore, the code is open source, so the standard could not be more known.
Too vague to bother answering, but I assume that like the rest of this stuff, you just don't know how to use it, don't like how it works, or would rather pay for another solution from somewhere else. Go for it.
Lobby is not even a part of UNET and has been updated many times. It's example code. If you can't make it work, why are you trying to use it?
Impossible-to-satisfy customers bring that out in people.
To do something other than nay-say:
I think UNET is great. Some parts of it stalled, and that's sad, but I'm not angry because I didn't pay for it. Which brings me to the next part, the harder part. I think UNET is great, but I don't like or want the services Unity provides. That's a bummer for them because the services are why they are doing this in the first place. Luckily for me though, that's the majority of what is "broken" or hard to use in UNET.
When I started using Unity, UGUI was just about to hit and UNET was close behind. I was, and still am, a frustrated install developer, not a game programmer. That said, all it took was a whole lot of hard work and frustration (and a broken keyboard) to understand the various types of game networking and what UNET was well enough to know how to pick and choose the functionality I needed (from working examples in the asset store!) and come up with working demos that just need a back-end service. Since my project includes a charity deployment with privacy/security concerns, I MUST self-host, so I'm a little stalled on that. If I wanted to use the cloud or do internet matches, I'd be all set.
As for p2p, yep, seems like it's pretty hard to use UNET out of the box the way people want to, but its important to note that only parts of it are broken, and that doesn't mean the LLAPI or HLAPI are broken. The services are broken and/or not useful. Fortunately, there are already good alternatives, so I don't know why Unity would really give a rats ass about fixing their "me too" implementation.
It's 2017. You are using LAN only in your game...?
Funny you say that. I was told worked as designed for host migration last year. They finally admit it in in June that they were able to reproduce it and it was confirmed broken for non-LAN (which is 99% of games that attempt multiplayer in the past 10 years). Other tickets I waited for months of no answer, following up every 2 weeks. One of the QA eventually said, literally this: "I can't force a developer to answer this question" in regards to how to properly disconnect from UNET. This was 2 months later.
It's not that I'm not getting worked as intended (with the exception of host migration, which they changed their answer to later) -- there is simply no answer because no one even knows UNET standards -- there are no standards, yet (docs come 1st - minimalist demo reinforces).
The standard of early 2015 without using HLAPI at all, sure. What questions are you asking? You must have a ninja account because you sure didn't ask here.
SyncVars don't work? This is always the top of the forum -- they inconsistently don't work -- random, a dev's worst nightmare. Even Tanks Multiplayer mentioned this.
It's been asked repeatedly by more than just myself. Here, do a search - for forums alone, not even Unity Answers. Find an answer. It won't happen.
I've provided facts - you have only provided trolls.
Angusmf stop trolling. There is nothing wrong with coming to the forums to discuss bugs and broken features in hopes that things will be fixed.
I am not upset about UNET as long as the dev's making progress are communicating future plans. I think it will be great in the end.
Regarding SyncVar not working... they do not. But it's not random. Here's the reasons.
1: SyncVars can become desynced between server and client. This occurs due another client connecting calling OnSerialize while the value has been changed on the server, but before NetworkSendInterval has expired. This clears dirty bits leaving existing clients with de-synced values. The new client will get the correct value. The SyncVar will remain de-synced indefinitely until it is changed again (or something forces the script to serialize).
2: SyncVars hooks can fail. This occurs on scene changes. Briefly during scene changes NetworkIdentity.observers are removed, and then re-added when the client loads. Any SyncVar changes are not sent to the unobserved client during this period of scene transition (10+ frames depending on load time). When the client loads the new scene the object is re-spawned erroneously. This forces OnSerialize (with initialState == true) to be pushed to the client that just loaded. This correctly sets the SyncVar to the latest value, but hooks are not called (due to initialState == true)
3: Hooks are inconsistent. For SyncVar hooks are called before value change, and for SyncList hooks are called after value change.
4: Callback information is insufficient. For example on SyncList remove callback it tells you the index that was removed... but you have no idea *what* was removed (because it is no longer in the list).
5: Setting a SyncVar to the same value causes dirty bits to flag and chews up network bandwidth.
6: SyncVars are limited to 32/script (design issue... not a bug)
7: SyncVars cannot be set by clients (design issue... not a bug)
That specific enough for you?
Woah. Hold up. This thread is the definition of trolling. I'm trying to provide a less biased voice (and a little support for the devs who honestly don't need this crap. It's not helpful.) I said UNET is great, and I think that these threads, with exaggerations, inflammatory language, and misconceptions, hurt the chances a lot of people have of finding that out. I also said, "I still don't really get what people are griping about or why they're trying to tell Unity how to allocate their resources." dylanh7244 was kind enough to tell me in private message why he cares enough about these issues to go to these lengths. I'm kind enough not to repeat them, but let's say I stand by my assertion that there's a need for a more unbiased voice.
What I see below that are 7 "issues" you seem to know how to work around or are just things you think should work differently. I feel your pain, but this is outrageous behavior from adults, in my own personal opinion.
My private message to dylanh was to reach out and explain myself, to prevent some flame war here. I really am not trying to troll. I'm trying to say you guys are doing a disservice to the community you purport to be helping.
Your argument for knowing what all users want is what exactly?
First, you might want to look into this thread. It is a good example of nice collaboration between UNET developers and the community, and it provides a sound overview of what different people want and need. Of course final choices always remain at the unity team. I cannot imagine that anyone here would ever question this. But we can always point to features we consider beneficial, and to bugs which are currently remaining, in order to help to make UNET better for everone. People here are just doing this.
Just try to not be polemic or derogatory yourself.
@moco2k Thanks for the advice I suppose, and sorry to be polemic, but I think you are missing my point as well. I don't know what all users want, but neither do those two guys, and neither do you. The important part of HLAPI is that it's high level, but "high level" depends a lot on what you're trying to implement. Letting unity know what you need is one thing. But conflating your personal problems getting a project to work with some kind of (imaginary) intentional conspiracy by unity to keep us in the dark or make us suffer is ridiculous and not helpful. And dare I say it, it pisses me off sometimes. These two guys think they "won" something by constantly complaining about the same exaggerated issues and lack of response. They post troll threads like this and then hijack legit troubleshooting conversations with links to them. The claim that unity doesn't respond and that they would not be working on anything if it wasn't for all the noise is just wrong. They've obviously been working and I've seen numerous responses to their gripes, just nothing they liked.
I got no problem with you, bud, but if you think I'm the one causing trouble here, think again.
The situation as I see it:
1. HLAPI is semi-authoritative and for a variety of reasons, some people will never be happy about that.
2. That said, it's almost the only restriction on what you can do with it aside from the bugs and limitations that we've all been made so aware of now, though many are misunderstood.
3. Possible omission from the docs I haven't read from cover to cover: An easy-to-understand yet exhaustive explanation of point 1 and what that means for the subset of games and networking types you can implement with it.
4. The forum is a useful place for finding tips for dealing with 1, 2, and 3 but has a lot of noise, as all forums do, that confuse the issue for folks without the context of already understanding 1, 2, and 3.
I've mentioned above I'm a software dev IRL, and what we do when confronted with an unruly 3rd party lib (all day, every day) is:
a) Work around it or find another lib, or
b) Tell our boss it's impossible to do what they want because of the 3rd party.
I want to make games and i want the easiest tools for this, including networking. So i would like a working HLAPI with a working transform/animation/properties sync and ideally i shouldn't even need to know what the LLAPI is.
@Erik-Juhl I'm very sorry that you and the rest of the UNet team have to take the blame for the UNet issues because obviously Unity doesn't have enough manpower/resources assigned to UNet. Like in any other business this
a) stays like this and the client is not satisfied and finds another solution after too much dissatisfaction - or
b) Management assigns more resources.
I'm curious to see who releases first: UNet or Photon Thunder ( https://www.photonengine.com/en/Thunder).