Showcase Mirror - Open Source Networking for Unity

You mean this happens in HLAPI or HLAPI Pro stable or HLAPI Pro experimental?
If HLAPI Pro: did you download the latest experimental?

 

In HLAPI. If you did not fix it, it's still in HLAPI Pro, no reason you fixed this when touching NetworkTransform .

I'm sorry, i don't use HLAPI pro because for the moment you only fixed HLAPI component and not core function like NetworkServer / ClientScene /RPC / Command / NetworkIdentity (things like that )

And HLAPI pro require to modify dll, things i'm not fan when using Unity =) . I wait for stable and (maybe ^^ ) official version =).

 

Sure, no need to rush. I did fix one of the most critical bugs that you can probably reproduce in your project too:

 

Hi is it possible to implement alternative of Network.time on HLAPI pro? Thanks.

 

Progress: doing some stress testing today. I can run through a herd of 1000 monsters without any issues whatsoever. That was not possible 2 years ago when I started with UNET.

Yes, but I probably won't any time soon because I don't want to break any functionality when people upgrade to or downgrade from the original HLAPI.

 

Hello @vis2k,

Many people have never used the NetworkAnimator or the NetworkTransform because of various reasons, 2 of the most being:

1) Using the NetworkAnimator there is lots of 'moonwalking'.

2) Using the NetworkTransform, network movement isn't smoothed and very choppy/inaccurate.

Most of the tutorials I used involved making my own networked animations/syncing movement.

In your new "NetworkTransform", is the player movement synced better now? Can I actually use the Transform now?

 

Yes, my NetworkTransform uses interpolation. There are still a few things I might tweak later on, but it does interpolate.

 

I'm still confused as why the HLAPI Pro needs to be a dll to overwrite.

Technically speaking, ain't you able to write your own system on top of the LLAPI? So why would you need anything internal?

 

Dear Unity,
Please hire Vis2k. I would like to use your engine and UNET to make multiplayer games. Vis2k has done more updates in a week than I have seen from UNET is 3 years.

 

I agree completely and 2nd the motion.

Vis2k has worked tirelessly and relentlessly for nearly 2 years on his uMMORPG asset and with Unet, identifying and reporting bugs in the HLAPI, finding work-arounds, and testing the limits of what is possible with higher level networking in Unity. There are few people with as much experience dealing with the HLAPI and now he is well on his way to understanding and fixing the code base for the HLAPI.

However there is still a lot of work to be done and it makes sense for the powers that be at Unity to offer him a job, contract or some kind of arrangement so that this work becomes official.

 

Progress: uploaded a new experimental version:

• [2017-08-14] NetBuffer replaced with C#'s built-in MemoryStream
  • Problem: UNET's NetworkReader and NetworkWriter use a custom NetBuffer class that emulates C#'s built-in MemoryStream to save allocations because the internal buffer can be passed along directly. This is a bit of a philosophical question, I'd argue that being able to access the internal buffer from the outside is a bad idea because any bug will be incredibly difficult to track down. Using the built-in MemoryStream means less code, less complexity and the odds of ever encountering a bug in MemoryStream are virtually zero. Another argument is that computers get faster every year, so a few extra allocations won't matter too much a few years down the road, but any bug would still be terrible.
    
  • Solution: replaced NetBuffer with MemoryStream. Also changed .Position to 'ushort' to support up to 64KB. Previously it used short.maxValue for packet size checks, which only allows up to 32KB.
    
  • Note: we can always go back to NetBuffer later when UNET is 100% stable. But for now this seems to be the smart thing to do.

I used this version for the 1000 monsters test by the way.

Some of the NetworkTransport classes are 'internal', so you can only access them from the DLL right now. There's no way around it as long as they are internal. Also I am not sure if we can even run the weaver as a regular Editor script.

Thanks for your trust guys.

 

Update: uploaded a new experimental version.

• [2017-08-14] LogFilter redundant log level definitions removed.
  • Problem: log levels were all defined twice for no reason, once as enum and once as ints.
  • Solution: removed redundant log level definitions

Not too exciting this time, but necessary.

 

I think you meant NetworkTransport, but so what? You can make your own NetworkTransport.
And you can add .dll as plugins to your asset.

 

Or use the NetworkTransport DLL perhaps?

 

Sorry, meant NetworkTransport of course. That's the LLAPI by the way, no need to rebuild that one. It works great.

C#'s 'internal' types are only available within the same assembly (according to the documentation), so that probably wouldn't work. They'll probably make those classes non-internal eventually - I wouldn't worry about that too much.

 

But I mean the UNET NetworkTransport DLL

 

Why do you need internal access to the llapi? I think the hlapi shouldn't have that D:

 

Glad to see somebody working on the HLAPI. I've done some work as well and if you are doing an overhaul I have some improvements.

I see you increased sync var limit from 32 to 64. Consider completely restructuring the dirty bit pattern for 2 advantages.
1: Less dirtybit overhead
2: Remove SyncVar limit all together

UNET's SyncVar dirtybit structure is
A packed UInt dirty bit mask. This is a compressed UInt and takes up between 1 and 5 bytes depending on the amount of SyncVars. For example if you have 1 SyncVar there is 8bits of dirtybit overhead. If you have 32 SyncVars there is 40bits of dirtybit overhead. If you do decide to stick with standard UNET convention but have 64 sync vars make sure that dirtybit mask is compressed to 8-72 bits!

What I've done is instead switched to this format.
Foreach SyncVar
Read/write bool dirtyBit
Read/write payload (if dirty)

Except bools which always write their payload (no dirty bit... that's just wasteful to send 2bits when only 1bit is needed).

To do this I created a bitwriter. Currently with UNET/.NET if you use a NetworkWriter to write a bool it actually uses up 8 bits. This is wasteful. So a bitwriter writes in bits instead of full bytes. Then before sending across the network I round up to the nearest byte.

Then there is the added overhead how UNET sends bitmasks for every script on an object even if 1 script is dirty. For example on my player object there are 30 synced scripts. If I change 1 bool on 1 script it will serialize all scripts and send 30x8 + 8 or 248 bits of data even though only 1bit was changed! Two ways to improve this issue are either
1: Create a dirtybit for each script. If the script isn't dirty then just write 1bit of 0. Then you'd have 30x1+1x8+8 or 46bits (not great but better than 248bits!)
2: Send each script individually. Instead of a NetID for each GameObject I've created an ID for each serialized script. If 1 script of 30 is dirty and sendInterval has expired I send data directly to that script ignoring the other 29 scripts. The main reason I did this is so that you can have bi-directional data on each object... meaning data transfer from Server-->Client and Client-->Server-->OtherClients all on the same object.

Lack of bi-directional data transfer was one of the major UNET issues I've had. In many games the client will have control over player position (Synced Client --> Server --> Other Clients) but the server will have control of almost everything else like health/inventory (Server --> Clients). UNET doesn't allow this!!! You have to use 2 objects or messages to work around this fundamental design issue. So if you are overhauling HLAPI I'd strongly suggest fixing this.

I'll just link all the bugs I've found here. Most are HLAPI. As you overhaul the HLAPI maybe you can fix some.
https://forum.unity3d.com/threads/my-compiled-list-of-unet-bugs-issues.403578/

Good luck. Good that somebody is working the HLAPI!

 

Wanted to try new versions, but it seems like there isn't NetworkTransformChild anymore. Was it removed after NetworkTransform change?

Any suggestions on this?
Like an upgrade guide or something.

 

The HLAPI is built on top of the LLAPI.

Thanks for the suggestions. All of that sounds good. My main priority right now is stability over everything else, so I am not too worried about bit optimizations just yet - that's not the HLAPI's main issue. But a year down the road once we have a 100% stable and bug free HLAPI, then this becomes very interesting again when we can worry about saving 10% of bandwidth for MMO scenarios etc.

Serializing only those components that are actually dirt is on my ToDo list, I too think that this is important. It seems to make sense to still include them all into one packet, at least initially. So that once a player spawns, all the data is already there for initializations.

As for bidirectional data transfer: would have to research that once the HLAPI is stable. I try to not add any features just yet, only stability and simplicity, keeping compatibility with the original HLAPI.

Yes it's not in there right now. I didn't know that anyone uses that. What exactly is the use case for that?

 

Progress: working on some code improvements that bothered me for a long time.
Here is an example of the old ChannelPacket.SendToTransport function:


This code is way too complicated for what it actually does. Why does it check the error code if TransportSend returned true? Why does it check NoResources twice? Why does it have two error messages? Why does it sometimes 'return false' and other times 'set result and return result'? When exactly does it reset the Position?

This is a good example of what's wrong with the HLAPI. It's as if the most complicated implementation was always picked over the most simple implementation.

Here is the new version:

It calls TransportSend, checks if it worked, and if not it checks the error code. Does exactly the same, is almost half as short and can be understood by just looking at it. These kinds of improvements will need to be applied in a lot of different places, and they should pay off greatly in the future.

 

I'm not too sure, it's from legacy parts of the project. I bet it's for sync'ing multiple transforms attached to the root of NetworkTransform (since you can't have the netId on the child's of a netId object).

Probably I'll just take it down, since I've already rewrote a replacement for a server authoritative movement instead of default NetworkTransform.

Edit: Yep, it was just a part of the redundant code. Works great, looking forward to future updates.
Edit2: Welp, spoke too soon. Works okay with one project setup, but I was unable to connect two different projects due to

But CRC check is disabled in NetworkManagers in both projects.

 

Just catching up here, glanced over one post about reinventing the wheel. Sadly Vis you have to. Unity when doing Unet did a whole lot of poor practices, high overhead, and well I can not say more than why Unity why.... I am with ya man, if I can be of help you know where to find me!

 

A better way to handle network movement is to have a poller that runs on its own exec thread and quickly travels through virtual zones and sends the data to the virtual zone parent (virtual zones are the visual area of a player) client has listeners for that, and just responds. Client in turn does not have to send its movement data to the server, the poller picks that up during its normal routines. Set properly it should poll everything in under 1 second, generally you will not notice any hiccups

 

Agree with you stability/robustness is more important than efficiency. But its a lot more than 10%. For example look at a basic scenario with 4 players x 30 scripts at 50ms send interval at 64 SyncVar dirty bit overhead is...
4x30x(1/0.050)x64 = 153,600 bits/sec of dirtyBitMask overhead! This is only for the dirtyBitMask and doesn't include the packet header & uint NetID & ushort messageType & data payload.

One of the biggest stability/robustness issues I've with UNET is how SyncVars can become desyned, SyncVar hooks can fail to be called, and ClientRPC's can fail. This happens for a 2 reasons. 1: Whenever a scene change occurs the NetworkIdentity.observers are dropped and re-added. This creates a brief time (~10 frames or so) where network data transfer does not occur to that object (SyncVars and ClientRPC). When the client loads the new scene and the client's NetworkIdentity.observer is re-added the server then pushes a full "spawn" serialize (initial state == true) to the client. This gets the client's SyncVars to the latest value... however hooks will not be called... even though the value may have changed. It's worth mentioning that ClientRPC during this time will also fail to send (even on the host!). Custom OnSerialize/Deserialize (initialState == true) code will also be called repeatedly as UNET attempts to "re-spawn" each object on each scene change. To fix this bug I think it's best not to drop NetworkIdentity.observers during scene change, but alternatively as a bandaid you can ignore all 2nd and subsequent OnDeserialize (initial state == true)... this is what I do as a stopgap. 2: SyncVars can become desynced for a different reason. If SyncVar is dirty and new client connects it will push new data only to the new client and clear the dirty bits. All existing clients will have a SyncVar with the old desynced value indefinitely until the value is changed in the future and serialized to all clients. To fix this either A: don't clear dirty bits when a new client connects or B: push to all existing clients (if dirty) first. I do the latter to fix the bug.

 

Glad I am not the only one that thinks UNET HLAPI has a lot of questionable design decisions.

 

Yes one of the first big red flags to me when messing with Unet is what the client even has a choice.... In a multiplayer service the client is a viewport/interface, maybe you let it move and tell the server its moving, but otherwise the server loops through everything, organizes it, and sends info to the client. At most the client politely asks if it can do something. Otherwise you end up with....well hacked clients, look at all the hacker problems 7 days to die has for example, direct result of client being allowed to do more than view/request.

On top of that, server should basically just be a live tracker/calculator/decision maker and authorization. Something is totally wrong when you have a super small game with not much going on and the server is eating up so much. Why is the server even keeping track of object models and name plates, all it needs to know is the positions and what its attached to. Pure data nothing more. Syncvar is a silly way to track data too. When the server loads, load everything off the database which should just be a save file, into appropriate collections like hashtables and dictionairies. When the client connects grab its last saved state, put all of its relative not critical stuff into a properly flushable/sortable/interruptable/non blockable message stream, and all of its data it shouldnt have any control over into collections, properly send it out to the client serialized, then the client deserialize and load its initial state upon login. From there just send managed bits of data to tell the client to update things. I havn't quite worked out how to do all of my tride and true methods for server to client optimizations in c# yet, and I have been shown some c# tricks for at least one major thing which makes me wish I could do it that way in java. However anything that the server and client both use be it common functions, values, and sometimes even lists of things to use for shortening the messages through tcp, should have some kind of library both can call to. In this case I am really missing the never need to finalize abstracts and good old interfaces, as well as multiple implementations lol. Still principles are the same.

Basic example take the entire list of commands that a player can issue to make requests to be able to do something to the server, usually the command on the client side would just load up some parameters and fire it all off. However if in that library you have a constant, I think the c# way is public const short CMD_SMITE = 24 for example... we are assigning a short to every command the player can issue to the server. Why, now we just add to our message protocol (used to bytebuffer, but seeming memorystream is the way with c#) a nice short 24 with a command header. Server gets that deserializes, heck server knows all, thats all it needed, it can take 24, grab that same constant pool, know what command, grab its datapool of the players instance and pull any parameters that command needed. For smite maybe it grabs some variables like intelligence, wisdom, faith, casting then feeds that to handle_smite command, which does all the logic, then sends back to involved parties (caster, target) to play particle effect, do damage, take mana. Again dumb it down as much as possible to send the least amount through the interface.

Too long winded I know I do that, but this is important to me because I really want to use Unity. Instead what we are dealing with right now is way too much client power unless we really work on telling the client to stop, way too many commands going back and forth without being optimized, and I also think quite a few garbage issues.

Round robin back to the syncvar why deal with that dirtybit mess when you can just narrow it down to the least amount of bytes and tell the client hey setHealth 90 and guess what setHealth is in that short list, so its maybe whatever your command header is, 2 90

Java handles strings where c# likes bytes but in the event of socket sending even in java I like that small data handling of bytes through when possible, just gotta remember to reloop till all bytes are handled, then flush. Have yet to have a good performance comparison for the memorystream but since c# does not handle buffer overloads, probably better lol.

 

Uh, unet is a classic server authority design.

 

Hey, did you happen to fix the "Can't start a match because of password field being blank"? I really don't know what causing this.. but it's driving me nuts.

 

Yeah they say that, but then you have to go through and explicitly tell the client to be a client and the server to be a server all over the place, if it was true server authority the client wouldnt be able to do anything but read and interprit to start with. So obviously that is a pipe dream, you gotta make the server authority so just do it the tride and true way and make it do what it should in an optimized fashion.

You say classic, a classic server is what I am describing, these broken, hacker all over the place insecure modern "authority server" models just don't work. When I think of a HLAPI I think of options you might not use, that is a bit easier to understand or at least more comfortable than the LLAPI it is built on top of. Great example imo of this Javassist, built off ASM, I can understand Javassit, ASM makes my head hurt. I think the HLAPI should be able to implement an authority server for smaller multiplayer games with a few hooks easily, but needs to be powerful enough for people with big dreams to get the job done without writing a server outside of Unity. Scalability, options, thats what HLAPI's should be about.

Honestly though all my suggestions are premature right now, only posting for posterity for later. Vis is on the right path atm, he is going through cleaning up the ... strangeness, and getting rid of useless stuff. Thats a great step 1, and fixing a few bugs while he goes through.

 

Uh, if you change things on the client, it's not sent to the server and the server does not replicate it.
Unless you are explicitly expecting it on the server, nothing will happen.

So of course you can changes things on the client.
Even games like LoL which people call the client "video players" you can actually change things, set positions, change speeds, but nothing happens on the server. You are just F***ing your own game.

 

You should really read what authoritative server means and how you could build it with any networking library. If you are expecting to build your game from components out of the box I have a bad news for you.

 

Its called having your server run checks on everything every loop, some things like common collectors that need to run over several methods and objects stick in a coroutine to do its thing so your main thread doesnt choke. Client lets say wants to hit something, its asking the server if it has that ability, server clears it and lets the client hit the something. It takes like no time to pass that both ways unless you have serious latency problems. A client is an interface. Much like a web browser and a website server. Browser looks, sometimes the server will ask for input.

 

I don't, however this is claiming to be a high level api. I could sit here with heck I can think of 4 good choice languages off the top of my head and just build a server from scratch. This is one of the things that has kept me from diving well into c# all the naysayers, and limited thoughts. Open source communities don't think that way, they dream big. As I said before these are like end product design ideas. Not demands, and it is nowhere near ready to implement yet. However what would be good is instead of going hey Xype, I don't think you know anything you suck. Start a conversation with me, explain your design ideas, its all about everyone dreaming big, thinking out of the box, then concluding with what is possible/best out of the braintrust. That is how things move forward.

 

Just noticed a post about thinking the HLAPI should do all of the LLAPI stuff. There are some things in the LLAPI that are easy and understandable just like they are. Look around at HLAPI library packages all over the place. Give ya a couple real fast, Javassist, cglib, both HLAPI on top of ASM but they leave ASM for any chance they missed something some niche needed, and a few things that did not need changing. You have to make choices sometimes where time is better spent. He is going over the code line by line right now just tweaking some serious problems and trying to fix the bugs that have not been addressed for a long time now.

 

Progress: going through all the classes one by one, improving the obvious parts. Fixed a few potential bugs already. Also improved some messages to send less bytes, e.g. SpawnFinished will send 1 instead of 4 bytes, which has quite the impact with thousands of monsters.
Will be released soon..

Did you rebuild the other project too?

Thanks for the suggestions.

Might make sense to send one byte for 'amountOfDirtyBits' followed by the dirty bits. So 8 SyncVars will use 1+1 byte, 16 SyncVars will use 1+2 byte, 32 will use 1+4, 64 use 1+8 and so on. This way it only uses as many dirty bits as necessary + 1 byte for the amount, and a 'unlimited' amount of SyncVars be possible. I will put that on my ToDo list to look into later on.

About scene changes: I noticed that too, and I know why it happens. The HLAPI has some serious issues with scene changes right now, I wouldn't recommend doing that ever. It's like a 50% change that it will cause weird things to happen because the server might already send data when the scene wasn't loaded on the client yet. I have this on my research list too, that will be a tricky one though.

Never heard of that one.

 

Thanks for that. I was working on making a system (albeit a very nooby system since I am starting out) for server authority. I have been working using the default UNet on 5.6.1f1 and then switched the files to your as you mentioned.

Here is how my folders look like (note: I already replaced the Weaver.dll):


When I started Unity after the replacement I am getting these weird errors:

NetworkManager: First channel needs to be Reliable because in the code Channels.DefaultReliable is 0.
UnityEditor.DockArea:OnGUI()

NetworkManager: Second channel needs to be Unreliable because in the code Channels.DefaultReliable is 1.
UnityEditor.DockArea:OnGUI()

I have a custom NetworkManager (nothing fancy) but just in case you can find it here.

Anything I am doing wrong?

Also one more question, if I may. I am trying to do server authority with movement. If I add a NetworkTransform and NetworkIdentity to the player and just move him about without ticking the "Local Client Player" in NetworkIdentity it doesn't move. If I tick it, it doesn't move in the server. If I tick Server only it doesn't move in the client. I already wrote the movement code with the default Unity but I was wondering if there is an "out of the box" thing in HLAPI Pro one can use for movement for example.

Sorry for the noob questions and thanks for this.

 

Yes, I added the channel warning to save you from crazy things. If you take a look at your Networkmanager in the Inspector, your first channel should absolutely be some form of Reliable and the second channel should absolutely be some form of Unreliable:


Reason being that the HLAPI defines Channels.DefaultReliable = 0 and DefaultUnreliable=1. The HLAPI sends some stuff around assuming that your first one is reliable and second one is unreliable. If they aren't, then bad things might happen.

Here is how I do local authoritative movement in my VOXL asset:

• Enable local authority in NetworkIdentity
• Use NetworkTransform
• Then in your Player script do 'if isLocalPlayer then do movement'. NetworkTransform will send the changes to the Server, Server will broadcast it to other clients

 

Oh, I didn't know about the channels thing. Well the strange thing is that it is set to just that by default here it is:

I haven't changed anything and this is the default. Do I ignore the warning in that case?

I am trying to do server authority not local authority. Do I instead just not tick the isLocalPlayer or do I need a custom made solution similar to the one I made with the original HLAPI?

 

I just tried it with the default values too:


No warning for me. Maybe there is a second NetworkManager in your scene somewhere? Or some 'ghost' object in the Hierarchy? Or maybe the warning appeared before you changed them, so you can just clear the warning now?

For server authoritative movement you need to disable local player authority and then send a command to the server when the player wants to move, then let the server handle the movement.

 

The Network Manager is the only one in the scene. I checked no other network managers are in this scene or any other scene. I also didn't change anything. I haven't touched anything on the Network Manager apart from clicking on the "Advanced Configuration" part and that is it. So I didn't change it to those values. These are what I found after replacing the files and clicking on Advanced Configuration...

Clearing the error, clears it out. However once I enter play mode and stop it, the errors come back. Moreover Network Manager is a singleton so there should be only one in the scene no matter what.

 

Could you send me a stripped down version of the project so I can debug it?

 

Sure no problem here is the link.

 

you will get errors if you set the server thing in the network manager properties and try to play from the editor.

 

Sorry what do you mean by "server thing"? You mean the option Local Server when you play? If that is the case it didn't do that with original HLAPI and the error appeared before me playing in editor. If not, then please elaborate.

EDIT: @vis2k it seems that Unity was just bugged. When I restarted Unity the error was gone completely.

 

Yes just tried it myself, no error here either. Good.

 

No, in network manager theres 2 checkboxes sorry NetworkTime NetworkIdentity

 

Thanks a lot for your quick support and great help . Sorry for the false alarm.

Neither of which were ticked. It seems it was simply a Unity bug and all I needed was to restart Unity as it was displaying phantom warnings.

 

A bug I noticed is when you have networkIdentity object in scene. If you connect to a server the first time everythings is ok. If you disconnect and re-connect without changing scene ... bad things happen ^^" (the object is not spawn / error ).

 

Does it happen with the original HLAPI too?