uMMORPG Official Thread

Ive seen others complain about this issue- can you check with your original animator of the warrior and ask him what up?

 

@ArtsyChen do you happen to know what this could be from looking at it?

 

@SickaGamer last I heard @Malbers has not and is not integrating is there something I am missing?

 

Hey vis, not sure if that has been discussed here but what would be the best way to update ummorpg as you work on the core features and keep customization i have made. I noticed Unity doesn't work like SVN style, so you could merge updates. It wants to import vanilla ummorpg and i would have to do all the customization again. Maybe someone here has a good method?

 

Check out the information channel in our discord. We have a git repository with all the previous uMMORPG versions. I think that's the easiest way to update, by looking at the changes and copying them over manually.

 

Progress: V1.147 pending review!

• Character selection previews are now cleared on client when joining world, not on server
• UISkills: removed unnecessary skills.FindIndex because we don't have buffs and skills in one list anymore
• EquipmentSlot: overlays don't block Raycasts anymore. Makes drag and drop easier.
• UINpcTrading/UINpcDialogue/UILoot/UINpcPetRevive/UIChat singleton added to avoid FindObjectOfType calls in Player.cs

 

News: uMMORPG and my other Assets are 50% off today!

 

I'm getting an error stating `Utils' does not contain a definition for `ClientLocalPlayer'

what happened to ClientLocalPlayer because it isnt there? did something replace it?

 

In the latest version (1.148), it was replaced by Player.localPlayer. From the release notes in the thread's first post:

• Player.localPlayer added to replace Utils.ClientLocalPlayer() function. This is easier to use.

(Dialogue System and Quest Machine users will be able to download updated integration packages from pixelcrushers.com.)

 

Sorry for breaking this guys, but I think it's a lot easier to use Player.localPlayer instead of calling this weird function.

 

Sorry I read through it a few times but must have over looked that line. I figured it was replaced with something like that

 

Progress: V1.150 pending review, now with Mounts!
https://i.gyazo.com/0ab2ed5c36282576b56a4e85ae53d858.mp4

 

Any steps to make this work with .Net 4.x, i. e. Unity 2018.3?

 

Good question Rowlan. I am waiting to get 2018 LTS released so I can use it with VS Pro. I suppose you want to use them both also?

Hopefully 2018 LTS release will happen soon so we can use uMmorpg with VS Pro and other tools.

Cheers
Ronny

 

I'm using Unity 2018.2.14, with .NET 4.x & VSPro on uMMORPG 1.148 and it works like a charme.

 

Thanks, I figured it out. Doesn't work with 2018.3.0f2. After installation into a clean project it changes the scripting runtime from .NET 4.x to .NET 3.5. When you set it back to .NET 4.x you get compilation errors because of a duplicate dll in sqlite. Removing the duplicate dll solves the problem. However, I didn't check if that breaks anything in runtime

 

I am still waiting for 2018 LTS before I take a look at it, since LTS is kinda important for multiplayer games, let alone MMOs.
But there are some people that tried it on 2018 already, and I think it works.

 

Your sqlite dll is causing a duplication error. I doubt that will change with LTS. But deleting the dll solved the problem for me.

 

Is there a tutorial on how to add silver and copper?

 

What I meant was: I will take a look at 2018 when LTS is released

As currency? As resource?

 

Hello,
To start great work,

this asset is really practical, however for some time I try to raise the scene upwards of 50 in Y axis,
for example:

Bandit = 52.093 instead of 2.093 by default

everything but in position +50 axis y,

but if I cast the scene in game mode it does not work the character or its representation remains at its original position, and therefore impossible to do anything an idea of where it can come from.

I specify that I get all that is already created in the scene by default.

The goal is to try to insert an ocean below.







http://image.noelshack.com/fichiers/2018/51/2/1545122835-1.png
http://image.noelshack.com/fichiers/2018/51/2/1545122835-2.png
http://image.noelshack.com/fichiers/2018/51/2/1545122835-3.png

 

Go to Window->Navigation and rebake the Navmesh Also delete your old database.sqlite afterwards so that your player spawns at the new spawn point.

 

Hello, I have a question. In crafting, I can put only a single copy of an object. for example, Is it possible to put 2 objects "wood" and 3 objects "rock"

 

Sure. Not with stacks though.

 

Hi vis2k and other people they can help me,

first i bought ummorpg, and I wan't to a clean start with that in 2019

When updates a relase for example major updaten with significan changes how can i save my progress on my project

Second question is what for models are good to change amor helms. ... umma2 or morp3D or a other system? Can an one share

 

Keeping track of version changes with git and then applying the changes that you want manually is probably the best way to do it. If you join our discord (see my signature) then you can find the official git repo where you can see code changes in your browser.

The current armor was created with just 3DS Max.

 

I would recommend you using UMA. Morph3d is pretty much dead and not supported and developed further by the Developer. For UMA there already exists Addons for uMMORPG.

 

Hello everyone,

I'm about to start a new project and want multiplayer aspects in this one, I'm at the point that I will use one of these 2 tools: uMMORPG or Atavism 2018.3. I hope someone here used both and can shoot me some pros and cons for both of them and help me choose.

Also I see a ton of add-ons for uMMORPG, are those necessary or are just for fast-tracking some parts of game creation?

Thanks in advance.

 

You will obviously get biased replies depending on where you ask.
Some people like uMMORPG more, some like Atavism more.
I never tried atavism myself, but from user feedback it seems like what people like in uMMORPG is the simplicity (only about 6000 lines of code).

 

V1.153 pending review!

• Mirror updated to latest version (OnStartClient not called in scene objects fix)
• NetworkNavMeshAgentRubberbanding simplified. Sends position every 100ms instead of path & velocity magic
• NetworkNavMeshAgent: reuse HasPath detection
• NetworkNavMeshAgent OnDeserialize now resets path when reading velocity to properly handle ResetPaths. Fixes a bug where monsters would slide on the client if they were killed while moving
• Mount.OnStartServer doesn't load skill templates anymore. Mounts don't use skills.
• Mount: removed unnecessary MOVING state and EventMoveEnd event. Mount only cares about alive or dead.

 

Thanks for your hard work @vis2k , looking forward to the continuing developments. Thanks again for helping me get my order registered to my email in discord.

 

Last Post in 2018:
Well guys, it's been a long year for uMMORPG.

I made some hints now and then, but let's make it official: uMMORPG V1 is finally in LTS (long term support) mode. In other words: this is the perfect version to start your MMO project on, because the next updates will be almost entirely fixes and improvements without breaking features, while I research V2.0 on the side.

I am currently deep into Mirror again, with around 100 improvements during the last few days. The primary goal is simplicity and stability for my own sanity. The side effect is faster and faster networking performance. 500 CCU per Zone should be no problem for uMMORPG now, and I hope that we can all test 1000 CCU per Zone together in late 2019.

It's difficult to find the right words for everything that happened, so I guess a big thank you to everyone fits best. It's unbelievable how many people came together to make the MMO of their dreams, and trusted me enough to pick uMMORPG for it. And big thanks to everyone who purchased it on the Humble Bundle sale this year. I still can't believe that this really happened.

I mentioned this before, but this is my dream job and making my MMO engine is the only thing I ever really wanted to do. Thank you all for making this possible, and I sincerely hope that many of you guys can eventually launch your MMOs because of it.

I wish you all a good start into 2019!

 

I wish their was a “love” option, because the “like” option isn’t how I feel.

 

As currency

 

Progress: V1.154 pending review (important bugfix release)

• Mirror updated to latest version (rpc hashing, syncinterval, fixes)
• NetworkNavMeshAgentRubberbanding: TargetResetMovement includes the reset position so that client keeps in sync with whatever player position was on the server
• Fix warrior not attacking monster when double clicking after reaching target
• Fix client not being able to target other monsters after killing one
• Player.cancelActionKey instead of checking for KeyCode.Escape everywhere
• NetworkNavMeshAgentRubberbanding: simplified local player movement change detection. Fixes a bug where server would constantly detect client moves

Not sure what you mean exactly. There is already gold, you could rename it to silver. There are also item mall coins.

 

So I would like to add gold in addition. Silver and copper inflict it. Say gold silver copper as payment medium

 

Ok, try it

 

Research Progress:


This was uMMORPG this morning: 1000 monsters on the server with noticeable performance hickups because of the current proximity checking method:
https://i.gyazo.com/a73b58db09da3c44dda953bc8fcb64ad.mp4

This is the new ProximityChecker that I am currently researching:
https://i.gyazo.com/375d7297a52cb33352dfe40ece5683bc.mp4

No more hickups. Execution time for 1001 proximity checks went down from 952ms to 31ms.

In other words: one huge step towards the 1000 CCU goal!

 

I read UNET is deprecated; has this asset been migrated to the new (or different) network platform? Have you considered Forge Networking from Bearded Man Studios? Its free and open source now.

 

Asset moved to https://github.com/vis2k/Telepathy and https://github.com/vis2k/Mirror long time ago

Supports 500 CCU easily on one server, Vis is working towards 1000 CCU per zone.

 

Thanks @Sehlor ; it wasnt clear from the release notes...

 

First of all, great work on this asset. I haven't implemented it yet, but I've followed its progress for a long time (along with the entire Unity network landscape), and your progress has been inspiring to watch. I think you (vis2k and all partners in crime) are one of - if not the most - dedicated devs in this space. Also congrats on getting out from under unet, that must have sucked D:

After developing a metric @#$% load of networking applications myself in C / C++ over the last 20 years, I have no interested in low level networking in C#, which is why I'm stoked on your work. Just two questions, after having taken a cursory look at telepathy code. My utmost apologies if these are asked and answered already.
1) Are you planning on sticking to thread per client model? I don't know the specifics of C#. I'm more familiar with directly using async IO (linux epoll) than overlapped IO (windows), and my plan is to run all backend under linux. That being said, my understanding and experience is that thread-per-server is only superior in terms of ease of implementation/use/general QoL/number of grey hairs. In performance it is inferior, unless your bottleneck is elsewhere (eg. bandwidth, such as the case with a media server for voice or video) thus you see high performance networking apps using thread pools of configurable size (so users can adjust for their hardware concurrency). Also currently in master, I see the listen server spawns new threads, which doesn't seem optimal. That creates a condition where restoring a server from an outage, the listen thread will bottleneck as all the barbarians storm the gates (or does C# use some high level thread pooling magic and I just don't know?). Also another issue would be server migrations. Same situation with a stampeding horde waiting for your OS to spawn threads. I doubt distributing accepts across threads is the way to go though, or even a decent use of your time since mostly it's a non issue. And anyway, to do that effectively on linux you need EPOLLONESHOT and EPOLLEXCLUSIVE, which are kernel 4.5, and I have no idea if/when that would be implemented in C#. I think it's totally reasonable to do all accepts on one thread, but not if that thread is waiting on the OS to spawn more threads. I see those two issues (thread per client, and listen thread spawning) as closely related in your current architecture.
2) Are you planning on adding an unreliable layer over UDP? I think you've been very smart not to go for reliable UDP, and I see you are using some high level wrapper around TCP_NODELAY, which is smart especially on the client (is there no TCP_QUICKACK sockopt in C#?). I can't believe Unity rolled their own UDP reliable lib from scratch and didn't expect a dumpster fire. TCP is a great choice, kudos for seeing through the "BUT GAMES NEEDZ DA UDPZ" stigma, but I definitely don't want to implement things such as client movement updates over TCP. First there's the overhead issue (IPv4 = 20 bytes, TCP = 20 bytes, UDP = 8 bytes) which seems insignificant (it's only 12 bytes, right?), but when you start pushing concurrency to the limit it is not, and it's even more not if you do world (non-instanced) events where everyone stands nice and tight together. It costs you in terms of money (hosting fees) and the server's overall bandwidth limitations. Second, UDP doesn't need to ACK each movement update which is ideal. Third, UDP doesn't need to guarantee sequencing which is REALLY key. TCP is forcing the application to wait for a lost movement packet when a newer packet has arrived out of sequence. The TCP implementation is not allowed to ACK the new one until it ACKs the missing one (thankfully it can ACK both at once when the missing finally arrives), but no payload is ever delivered to the application layer until it is ACK'd. And when it finally arrives in your application it's useless data anyway, because you only care about the most recent movement. So yeah, sorry for the technical details which I'm sure you already know, but if you don't plan to add UDP unreliable, then I would likely have to add it and even knowing how trivial it is, I just can't get sucked into low level C# networking. *insert "They pull me back in" godfather 3 gif here*. Neither can I just implement a plugin to native code, as that will become problematic on consoles (specifically Nintendo, which I think still has two developer streams, with the one allowing native access being much harder to get for new companies)

Anyway, sorry for the text wall, just getting closer to committing to a network library and thus giving serious consideration to the specifics (and thinking out loud a little bit). I've gotta say I love how active you are at developing this (and have been for some time!), and I love how this is your dream job. I hope it remains so and you earn as much as you need and then some Don't let yourself get burned out! Also, I would be dropping cash on this project if I use it in a product ... not a bribe or a carrot or anything, I would only ever want you to do something that's best for the asset as a whole and thus all of its users, yourself included ... just saying this is great work and the price you charge is far too low when it's being included in a commercial product *and* it includes your support work. It would be cool if you could price Unity Free and Pro assets differently, but that's a different train of thought

 

Please join the telepathy discord, maybe you can give us some tips! (see my signature)

We have three different telepathy branches at the moment: threads, async-begin (tcpclient.beginreceive) and async-await. There are two more versions on my hard drive that I have been researching in the last two weeks.

• async-begin is very slow, can't handle much traffic, and allocates a lot of memory for each callback.
• async-await offers simple code and performs well in standalone benchmarks. Unity uses main thread context for all await callbacks though, which seems to choke it again. We are still researching this though.
  
• threads won't scale to 10k/100k CCU because thread switching is just too slow. 500-1000CCU still runs fast enough, and it seems to run way better than all the other branches in our Unity benchmarks. There is value in having no background magic and no hickups. It's just 2 threads per client, that's it. I was actually surprised by how well this performs, considering how everyone is not only against TCP, but also against using threads for each connection.

500 CCU in a real world project seems doable with threads at the moment, based on previous tests with uMMORPG.
1000 CCU might be doable, but we'd need to test it.

If 1000 CCU works, then that will be more than enough for Indie MMOs. You'd be more worried about where you stash your money at that point.

But of course, we aren't set on threads. If you ever used Erlang, then this all seems like we are trying to sharpen our knives to eat soup better, when what we really should be doing is use the spoon..

Valid concerns. I am optimistic though. If we finish our MMOs 1-3 years from now, then hardware will be even faster. We will have optimized things even further - in fact, we pretty much doubled CCU every year since starting uMMORPG. 20-50 was the limit not too long ago..

Right now, threads are our best option from what I have seen.

After three years of UNET UDP hell, I will never go back. If I would've used TCP from day one, then a lot more people could've finished their games by now, and I could've spent more time on features and less time on figuring out why monsters don't spawn randomly.

There are other transport layers for Mirror though, and Mirror still supports channels for Cmds/Rpcs. So you can use which ever existing (r)UDP solution you like.

I agree. What's good enough for Minecraft and WoW, is good enough for me

That seems to be the only real usage for unreliable channels in MMOs. But then on the other hand, you'll need rubberband movement anyway. It doesn't matter if you have a 100ms or 20ms delay for movement - if it goes through the server first then it will always suck for the local player. I don't do this in uMMORPG yet, but in uSurvival I just let the player move where he wants and then let the server reset him if necessary. This works just as well with TCP.

Of course, if you want to make the next Counter-Strike then that's probably not a good choice. For indie games/MMOs though, it seems to work well.

True. Personally I'd prefer to never worry about lost packets though, I don't mind if it costs twice as much bandwidth. Especially for indie projects, knowing that I'll never have to worry about networking is huge. Who cares if the server costs $100 or $200 a month then - by the time you hit real bandwidth, you will also hit real income.

For the same reason I'll use Unity's google cloud server hosting when it's released. Setting up, securing, updating and keeping your own server alive is way cheaper, but who has time for that? I'd rather not hire an extra person to deal with it, and let Unity/Google worry about it for me.

I am familiar with that emotion. Would've been great if UNET just worked and we could all focus on our games instead. But now that we aren't in hell anymore, there seems to be a lot of value in vertical integration. We can fix bugs / improve performance immediately, that's really cool.

 

Yeah I can see that I'm being very nitpicky, for which I do apologize. Also I'm one of those dudes with few grey hairs who only knows how to use IRC, but I'm sure discord isn't exactly hard to figure out. I'll join in once I start implementing the base of my gameplay. It's probably smarter to switch to that soon, as I've been working on compute-based render pipeline with Unity's currently inadequate tools, while they simultaneously set up all the proper tools for that work in the SRP :S

I probably came off really harsh against thread-per-client. The truth is I have a number of systems that are thread per client and they perform quite well, and are simple to understand / extend. That is pretty key in keeping your sanity and helping you move forward with higher level work without getting burned out. But they are demonstrably slower under heavy load. How much slower and does it even matter? It depends and it depends, so I actually think it's fine that you stick with thread-per-server and it will be quite usable for me and for 99.999% of all Unity devs. But ... one thing I would love to see would be an option where I can pool all the worker threads at Server startup (apache2 style!). That will make your listen thread as fast as possible without any redonkatron async IO hacks in modern linux kernels, or overlapped IO nonsense in Windows (which probably happens under the hood anyway, because Windows). But if it's not a priority for you that's understandable. If it matters to me when I go to implement, I can do that and drop you a PR or just hold it locally and patch mine if you don't like it, though I prefer not to be out of sync with the main project.

500 CCU is really great, and I probably won't even *need* 1/2 of that. I only want to use as little resources as possible to power fairly simple multiplayer features. I'm not interested in a game with 1000 people standing up each other's asses, though it's super cool and I understand why some people are interested! That's an even bigger nightmare from the rendering side than the networking side, though. To be honest, right now I'm adapting budget scenarios (from C++ network protos to new C# ones) that prove a wildly successful open beta (itself a highly unlikely scenario) wouldn't tank my game service, and also wouldn't cost more money than we have before the revenue stream kicks in. It's a very fun game of spreadsheet tinkering ... I should release it as a minigame :'(

Hey man, if you don't wanna go back to UDP even for unreliable, I get it hahaha. Personally, I've never been burned by unreliable, and I've had mainly positive experiences with UDP. I've never used UNET, though I've looked through what exists of it on the C# side. I have a lot of telephony / voice services that use UDP (RTP proto) and they wouldn't quite be possible, or as effective if done in TCP. There isn't really time to stop and get a retransmission of a 20 ms long audio segment that's been lost and now is too old to be played in the call anyway. But the control channels (SIP proto - initiating calls, progressing their states, transmitting RTP ports and media formats) can totally be done over TCP, and sometimes are. When reliability is paramount then TCP is clearly a no brainer.

I did want that option, but for longer term. It's not necessary for me right away. I'm not sure I will use Mirror yet - though I'll definitely try it out! - and I'm not sure if I will implement a separate transport for unreliable either. I can always loop back around and implement it later on. As you've noted, you need a game that people actually play or none of it matters anyway. With indie resources, it's better to stay high level and make sure you have solid gameplay and polish.

Oh you mean you don't miss having a middling quality black box networking lib that's central to everything you are doing? Weird No offense to the engineers who worked on that though, as I'm sure most of their clients don't have any problem with UNET, and they built it under resource limits and a time frame to get the job done.

Hahaha oh man, that is what I do and have done for about 20 years. Server management is like tying my shoes at this point. If you need help load testing, just create a build for automated test clients and I'll be happy to lay waste to your servers. Are you just building on Windows / VS for now? If no one in the crew has experience with it, I could help with a CMake project that builds the VS solution custom (or builds a MakeFile in linux, or an XCode project on mac). Pretty sure C# enjoys core language support from CMake. Maybe C# devs use something cooler than CMake though, I wouldn't know. I'm pretty much a C# noob at this point. I did use the .sln on Windows, but I wasn't sure what to do on linux.

Btw, I researched my own question a bit re: TCP_QUICKACK. It is not available in any .NET API from what I can see, though I know for a fact it is implemented as a socket option on both Windows and Linux. TCP_NODELAY is doing you big favors in bypassing both the send buffer and tinygram prevention aka nagle's algorithm. But I'm not certain that TCP_NODELAY is forcing the PSH flag in the TCP header, or that the PSH flag always results in an immediate ACK (I *think* it does, but it's ultimately up to the receiver OS what to do). I'll have to set aside time to verify this, because it's worth knowing for sure if you want the least possible latency from TCP (aka WoW quality, which maybe you already have but I want to be sure). My understanding is that at the receiving end, packets with the PSH flag must be immediately ACK'd (unless there's a missing sequence number) and delivered to the application layer, thus bypassing the receiver's delayed ACK and receive buffer settings. If TCP_NODELAY isn't always setting PSH, then TCP_QUICKACK will still be useful. Regardless, it can't hurt to set it if possible. Even if there's no way to set it as a socket option, server admins do always have the option of forcing quick ACK as a server wide setting using the registry or in /proc. That could be undesirable though, and obviously users won't be doing that for their clients. I'll look into that further when I get a chance

 

Please join, 20 years of networking experience are always useful.

PRs are always welcome!

Mirror/Telepathy runs where ever Unity runs. Most will run the server on linux I guess.

 

Does this support MySQL yet? Does it support zoned instances?

 

Yes
Yes

For about a year it supports mysql and instances via free addons.

 

Hello i want to use this for unity 5.6.3 (upgrading is not an option)
I am getting error when i play an empty scene:

System.TypeLoadException: Could not load type 'UnityEditor.Compilation.CompilerMessage' from assembly 'UnityEditor, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
UnityEditor.EditorAssembliesrocessInitializeOnLoadAttributes()

and

TypeLoadException: Could not load type 'UnityEditor.Compilation.CompilerMessage' from assembly 'UnityEditor, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
System.Reflection.MonoMethodInfo.GetMethodInfo (IntPtr handle) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:59)
System.Reflection.MonoMethodInfo.GetAttributes (IntPtr handle) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:75)
System.Reflection.MonoMethod.get_Attributes () (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:245)
System.Reflection.MethodBase.get_IsSpecialName () (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MethodBase.cs:184)
UnityEditor.Build.BuildPipelineInterfaces.InitializeBuildCallbacks (Boolean findBuildProcessors, Boolean findSceneProcessors) (at C:/buildslave/unity/build/Editor/Mono/BuildPipeline/BuildPipelineInterfaces.cs:149)

 

I also tried experimentaly to use unity 2017.4.1f1 and i get this error in the demo scene only :\
TypeLoadException: Could not load type 'Mirror.TelepathyTransport' from assembly 'Mirror.Runtime, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
Mirror.NetworkManager.InitializeTransport ()
Mirror.NetworkManager.InitializeSingleton ()
Mirror.NetworkManager.Awake ()

 

Use the latest LTS release from here: https://unity3d.com/unity/qa/lts-releases