Vanilla

First things first, here's a rough (and obviously incomplete) explanation. You'd differ between DoS and DDoS. DoS (Denial of Service) simply put is using up the resources of the machine by leveraging on a weak spot of the program. You'll see often people targeting the auth server and flooding it with packets and if the server has bad code in it, it'll use up too many resources. This could lead to lags or in worst cases the server to not respond anymore. Now, if you think DoS is bad, we're gonna take it to a new level: DDoS (Distributed Denial of Service). This time it's not only one pc trying to flood the server and consuming all it's resources.. it's a lot. The strength of the attack varies and depends on how many attackers are gonna target your server. There are many ways on how a DDoS works and you don't necessarily need to leverage on bad code in order to attack the server: Even a SYN/FIN Flood can make the server say bye bye - or at least it would, if it could. Now let's get on how to protect against it. If you know how it works you can think about a few strategies on how to fortify against those attacks: 1. Make sure your source doesn't have flaws that could be exploited by attackers to use up your resources 2. Set up a good hardware firewall to block incoming attacks 3. Configure your firewall correctly to drop connections once a connections seems to go mad 4. Harden your system (there are some tunables you can set to harden your system a bit against attacks) There are also more techniques (rerouting traffic, etc..) but I guess for the most people this does not matter too much.

mostly it's converting everything to utf-8 and then run 2to3 tool to convert the scripts. You'll have to make some changes to the scripts tho, since the tool obviously can't be perfect. And then it's changing the the python initialization and modules declaration. You'd better use Unicode in client source, so if I were you I'd start with using utf-8 on client and all files (text files, py scripts etc.) and then swap the project to unicode. You have to change a bit on the client there but in the end it's definitely worth it! After that you can do the actual upgrade to py3. Side note: I also recommend using utf-8 in database tables, server source and files

Well if it's bothering you, why not sharing a guide and helping the people to move to py 3? It's not like it's that difficult to upgrade to py3 tho. But I guess you can't complain if people don't want to touch a running system especially without the knowledge of what they're supposed to do or how to debug after converting the py2 files to 3. Especially since developers tend to just sell their precompiled stuff which runs on - tada - py2. I can imagine the autistic screeching after finding out that after porting py2 to 3 results in some systems done by greedy devs not working properly. But yes I agree, it's best to use py3 in any case possible!

You can pack almost any dll the client needs. It makes sure that the environment the players run your binary is the same. For example there's visual studio redistributable which depends on the vs version installed - and even then there are multiple minor versions. If you use vc 140 compiler for example players will need the 140 redistributable, otherwise they can't run your binary. To make sure the players have exactly the same dlls as you, you'd just bundle them with the client - which of course leads into more dlls located inside the client directory. But this way you can distribute your dlls and make sure the players have the same version of them thus reducing possible bugs. As @Gurgarathsaid tho, it's always possible to link statically which means you don't have to include those dlls anymore.

devIL is open source so you can just download the source, compile it and use it in your client. You should not just replace the dll without proper source adjustments. But you can easily replace devIL includes and compile your own dll. Just use that instead, it'd work without breaking guild mark display. And no, you do not have any disadvantages. But you can compile the dlls with more recent toolsets and thus benefit from faster dlls and also more recent versions often allow you to use more tools from the library or even have some bugfixes.

There are many ways on how to find that one out - one simple way to do it is just use tasklist /m It will print out your running programs and what dlls they've loaded. To upgrade a dll you'd do it both in compilation (update includes etc.) and then obviously the dll. Sometimes it does work to upgrade a dll just by replacing it though you'd be careful with it since it'd lead to unexpected behavior. Of course you can't upgrade major revisions, so don't even try to upgrade the python2 dll to python3 without changing the source - but if you do, you can delete the old python27.dll and use a more recent version instead.

You probably have too many heavy queries running. Execute this statement and see what queries are running. You may want to tune them down, cache results, etc... I guess you're running a webserver that accesses these databases? Mostly badly written admin tools could be the culprit for such heavy loads: SHOW PROCESSLIST; Also memory consumption isn't that high for such a big server. Check your buffer sizes, table cache and query cache because maybe you'd tune them to reduce cpu usage. It's a bit of a trade-off since you'll have more memory consumption but since the cpu bottlenecks your server for obvious reasons it's definitely a good deal. More info here: [Hidden Content] and here: [Hidden Content]

Actually you can already use the same approach we currently have with chat flooding. Many people don't implement this fix but I find it to be mandatory: You can just use the same variable for every chat thing (be it whisper, etc.) or even companion add. Because there are many more things you'd technically flood the server with. I'd changed it so you have three variable types: fast, mid, slow. Depending on how fast a player can actually trigger this (like itemuse can be triggered way more often than a chat command should be) the variable count is higher and cleared each few seconds just like the current anti-spam works. You can fine-tune those variables and thus prevent flooding with each command. This can also be used for itemdrop packets, making it possible to once again write with 1 yang on the ground without having to fear that someone might flood the server (because he'll get kicked after too many packets within a time span).

well you'd just make a check if the window is focused and if not, then release all pressed keys. This could be done in the OnUpdate of game.py

I think the same issue is with cryptopp, too. Like, modern cryptopp versions are working with modern c++ standards. The old ones may cause issues. Did you check if you have the most recent version?

Not that I know of, but just to throw in my two cents: Why would you even want to downgrade directx? Before you do that you'd probably check on how directX works. Maybe even go for higher directX versions, but you shouldn't put all your effort into a Downgrade.

Most likely your boost version is way outdated. Try and grab the most recent version instead, it'd be compatible with more recent compilers and std versions.

That's why I said, regardings bigger servers you have to make sure the players are distributed. And you can do that with many tools. You as an admin have the power to influence that. With let's say events, rewards for smaller empires and stuff. People will tend to change the empire in such cases if they are not in dire need for their old empire. People are afraid to use tools to make a better distribution of the empires. You'd technically make the maps work with only 2 empires - why, for example, not make the maps for the third empire still be there? But make it like in ruins or something? This could go along with the idea of making this play after the war and having one empire be utterly defeated. This could still make all the maps keep their meaning, but of course, it feels a bit.... mehr in my opinion. I think 3 empires is the way to go.

In my opinion.. 3 is the way to go. I mean you'd try and use less empires but it'll only mask the problems, not fix them. A low playerbase is the biggest problem of all, so other empires may look empty. And this is actually one of the things where a server admin can work on. Making the server attractive enough so it doesn't matter which kingdom you choose. Second, you can always make the three empires interact with each other. Be it by events or by systems that make it work together. In the past I saw such things happen and people were wilingly changing empires. For example you'd do events by empire and then make the rewards for empires with less people bigger, so the playerbase will distribute wilingly. Raise the rates (exp etc.) for example for an empire that has less people there. All these are just ideas that might help fight the main problem. The problem are not 3 empires, the problem is the distribution and lack of players.

One important thing before you enjoy the time with c++11: Make sure you look over all iterating loops. Because behavior changed for c++11 to autodetect for loops with iterators. Sometimes you may encounter shortened loops with iterators. In modern c++, so since c++11 your compiler will detect the loop and automatically increase the iterator. This may create a lot of issues. Have a look for example at CancelServerTimers in questmanager.cpp. If you don't fix those loops you may encounter issues and crashes.