Quote:
Originally Posted by fantasy942
Hi everyone.
Im here for talking with all the opennos "community" about the problems of the emulator.
This isn't a post for random isnult, emulators compare or kidding others.
So, having said that, let's start the real discussion 
After some test, the part of code that result using more Cpu for me was:
MonsterLife
Drop Handler
BCard
I was think about change the BCard management from this big switch to something more performing.
About the Drop Handler there isn't so much to do... This part of code need a total review xD
I still have no idea about the MonsterLife but, i will studing something about that to...
What did u think?
Did u find other stuff that need to be changed?
Did u think that Opennos can be more "stable" than now or is just a waste of time?
PS: I apologize in advance for my English but I hope it is at least understandable xD |
Since you seem to be really attached to OpenNos, i'll still give a real argumentation, I'm sure that you won't accept it, cause you are denying facts since several months if not years (we already had that discussion)
"big switch to something more performing", don't worry, this switch does not create a significant overhead, the only thing that does, is all the implementations behind it.
The "CPU" wastes are coming from several things that got side effect overhead and aren't traced by
- Too much usage of lambdas
- Too much usage of LINQs (yes, allocating a delegate has an overhead, using a delegate is slower than having static symbols to call)
- Unmanaged concurrency (ReactiveX, complete abuse of it...)
- Direct calls to the databases (thread blocking I/O) instead of having a queued/batching/background approach
- SpinWaits (Synchronization over channels are badly done, its 100% dependant to the synchronous transportation layer ("OpenNos.SCS") make it slower than it could be over a properly managed message queue)
- No fast cache (redis/inmemory), in too much places of the code, everything is just loaded from database
But, CPU performance is not the only criteria about :
- Full of null checks everywhere cause the game core & game logic code is written by script kiddies without riguor
- Exception silencing
- Pure OOP code driven architecture in 95% of the code, which makes everything code related, while many many things could just be data driven (game logic code)
If you don't get it, all the core of OpenNos needs to be rewritten, and given how shitty the game logic code is written, it also needs to be rewritten.
We achieved to have a really smooth gameplay (no sluttering) & performance on NosWings' beta, it took several core rewrites (at least 3 since I began writing WingsEmu in June 2019).
Of course, WingsEmu's architecture is nothing comparable to OpenNos/NosCore, it has many similar architectural choices with SaltyEmu, all that improved thanks to the experience we acquired.
All these things are useless if you don't include a
serious monitoring of your platform/softwares :
- Game realtime metrics
- Performance related realtime metrics
- Pure software related realtime metrics (this helped me finding that we had too much GC calls)
- Exception reporting
An "emulator" is a real software that requires to be well made to be able to scale, but given the technical skills that it requires to have a properly, it can not be handled by script kiddies.
Riguor, a lot of documentation & articles to write about MANY things
It's not for nothing that MMORPGs is one of the hardest kind of softwares in game engineering, there are much things to think about due to the "Massive" amount of objects to compute.
Leechers can cry "gneugneugneu opennos/noswings cpu issues" but, so far, we've seen a lot of people crying, no one really took the time to learn how to design such softwares.
That's why NosWings will outstand once our work will reach a stable phase, because we know what we are doing.
Our beta testers can confirm how fast we are adding things & deploying updates, it takes me one command to deploy and 30 seconds to update any of our components (game server, web api, metrics, monitoring, centralized logs server, CI/CD runners...)
Nothing that you guys are taking care of, but actually, it saved us more time than it took to be able to do it.
