Sunwell Core released to the public

Our auth server easily supported 3-4k players logging in after a crash in under a minute, with no problems or lagging at all. If you've got problems with auth, check your code. If auth is a problem for anyone, take it out from newest TrinityCore, it's not related to gameplay anyway. Do you even know what you're talking about? This has nothing to do with initial authserver, but the gameserver authentication, which will block network threads (because you have 5+? synch queries per authentication request), e.g. incoming packets from all sockets on that network thread will be blocked which leads to client side delays in both sending and receiving packets. Who cares if it's ACE or boost? ACE is actually faster fyi. I loved how TC switched to boost and after 3 months they commited changes like "finally fixed auth server, players can login now". I will agree boost::asio is trash, however, you do know that there's more to boost that the asio networking, right? http://www.boost.org/doc/libs/1_55_0/doc/html/container/non_standard_containers.html Breaking is done per-player and after opcodes for that player were processed (no interrupting in the middle of an opcode) for more than 3ms. No opcode is blocked for N>1 updates. If 3000 players and hundreds of tasks are handled in just 25ms (from our talks I know this is some dark magic for you), 3ms for a player is more than enough safety upper limitation per update (in fact per session update and then again map update). If you have ever played on Sunwell, you would have known no one complained about response time. It was very fluent, due to diffs being extremely low. It checks each and every opcode, then breaks the loop (which already has enough reasons to break the loop, due to lame design and ordered packet processing with 2 updaters) if that opcode took longer than 3 seconds, NOT after all the opcodes have been processed. It is very easy to hit 3ms minimum on packet processing, if you logged them you would know. Check out newest TrinityCore: https://github.com/TrinityCore/TrinityCore/blob/3.3.5/src/server/game/Server/WorldSession.cpp - oh, it's the same! You know, Warden does not protect from any popular cheats (tele hack, speed hack, etc.), it's just a first line of protection and Warden response packets can actually be spoofed. It's server's task to verify client behaviour. So judging from your comments in the core, this is now an excuse to use the 'TC way'? Lol. Yes warden responses can be emulated, has anyone done that? No. Will anyone do that? Most likely not. Do not give people a free pass to bypassing warden with a simple string change. This has been a known exploit for bypassing warden since like 2012, come on. Can't see anything wrong with the code. It's all over the place and nonsensical. Oh, so that's why the core has avg diffs of 25ms at 3000 online. It's because we added more locks ;D *facepalm Called TC shit. The core was designed to be single-threaded at first and multithreading was added much later. This forces you to either work around some shitness or code asynchronous maps, which requires changing basicly everything, from big things, to even smallest ones like quest scripts. Look carefully and you will find a hundred more cases of calling TC shit in the code. Of course TC isn't great, it's from people not contributing and hundreds of developers of all skill levels working on an open source project (that only until recently started to actually care about code quality in pull requests). This is probably the worst place in the whole code ;d Please read attached README.txt file, it's explained there. MoveMaps without having transport data perform very poorly on transports (both motion and static ones) and there are just a few if's to force proper behaviour. Anyway, players don't care whether you do if(map==X), they only see working results. ¯_(ツ)_/¯ Lock acquired, element inserted, lock released (in guard's destructor). Other thread working at the same time also acquires lock, copies the elements from that container and releases the lock as soon as possible. What's wrong with that? Then what you would be looking for is a spin lock using the pop & swap method, not a unique mutex and iterating the list to insert into another list, which is extremely inefficient. Auctions are not modified during Map::Update, so that thread is free to read auction data. No, Auctions are not modified in map updates, but player data (which you use) is.

So tell us, how is your problem with using ACE, calling core shit, or single-threaded auth working fine, related to players experiencing the game? Sure I guess from players perspective it doesn't matter as long as they can login and do quests, but what you guys did is nothing special. Given enough time and enough hacks anyone can do the same. The problem is when the underlying code base is fundamentally flawed you pretty much screw your self out of anything in the future. This would be a common example of, fix one thing and it breaks 10 other things.

I will say this again, I am not this trayz guy that you assume I am.

/r/wowservers Thread Parent Link - sunwell.pl