Mister D

Looking at today's date I would not take it too seriously.

Here is my take on this, based mostly on my assumptions, and a little information I read on this forum. There are loading screens when traveling between continents, and to and from battlegrounds and instances. As I understand it there is no change in server IP-adress or port, but I assume they do use separate machines for the different continents and battlegrounds (multi-realm) and instances. So the server IP we see probably belongs to a proxy that takes care of the networkconnections to the clients, and does the encryption and compression and redirects information to the correct server, dependent on the characters location. The loading screens are probably to mask the handover between servers. As I said, these are mostly my speculations. I have no solid information.

Is the world database only written to with certain GM commands, or are there writes that are caused by normal gameplay? Are these DB changes kept after a restart or crash? What about the Scriptdev2 Database? Are there any writes to this Database? Are any changes kept after a restart or crash? I'm just trying to figure out which databases I could restore with old backups and which ones I need to secure against data loss. So far I figured out that of course the character database needs to be secure, and the realm database too. But the world database and scriptdev2 database I am not yet 100% sure about yet.

Is that a joke? The bandwidth per player is a few kilobits/sec MAXIMUM; usually they will probably use far less. A 150Mbit/sec connection is easily enough for tens of thousands of players. Also unload timers only affects CPU/memory usage. Has no effect on bandwidth. The question was in two parts, one about bandwidth, the second part about memory usage, it was answered in the same way, so the 150MB was about memory usage, not bandwidth. The unload timers were also in reference to memory usage, not bandwidth. At least that's how I read it. Now a question of my own, earlier when MMAPS was in development I read that all the MMAPS were being loaded at startup, and not unloaded, and it needed 2,5GB of memory. Is this still the case, and if not, how is memory usage and CPU load with full MMAPS en VMAPS enabled? (I've only ever tested with two people online at the same time with full VMAPS, so my old server and my connection haven't been stressed, and I was wondering if MMAPS was still out of the question with only 1GB or RAM).

Did your server crash and restart windows? Make sure your server is stable, and put shortcuts to realmd.exe and mangosd.exe in the startup folder to make them start up automaticly on windows start/restart.

The main problem is, turning off SSE2 doesn't seem to fully turn off SSE2 in at least the couple of components that give problems, if this is a problem with the compiler, or the code in those components I don't know. So it's not logical that you have to turn off SSE1 as well, even if your CPU does support SSE1, but to make it work you do have to. When I first ran into this problem the first thing I tried was to turn off SSE2 manually, while leaving SSE1 on, when this didn't work I thought it wasn't a problem with SSE and went on to look for the problem elsewhere, so it took me a lot of testing and recompiling before I actually tried turning off SSE1 as well, because it doesn't make sense that this would be the problem, but it worked. So if you have a machine that doesn't support SSE2, turn off all SSE, even if your machine does support SSE1. I really don't like this solution though, it feels hacky, since there is obviously a problem somewhere in the code of the affected libraries, or in the compiler, this just avoids the problem, but it would be nice to know where the problem really lies. The compiler I use is VC++ 2010, I have no idea if there is a problem with other compilers, this would probably be good to know, since it might just be the compiler's fault.

The instructions that are used are decided by the compiler, it would probably take writing some extra subroutines, some that specifically use SSE and some that don't, for the same purpose, and the option to switch between them, to make it possible to disable it after compiling. I don't know how other software do that, which offer the option to turn off and on different instruction-set extensions. And as far as I remember the problem lies in some included libraries, not the mangos code itself. It took me about ten rounds of re-compiling before I actually figured out the problem, but this is not the first time it has come up on this forum, so the old threads should show up in a search. Turning SSE off in the compiler isn't so much work, at least in the microsoft compiler I use, I don't know if this same problem exists when using GCC and linux, or how you would turn off SSE there, this would interest me since I do plan on switching to linux. Making instruction set extensions switchable in a .conf file would only make sense if you wanted to use the compiled binary on many different systems. to me Compiling an optimized binary for every different system seems to me to be the best solution performance-wise though.

As far as I know the compiler just turns on all the optimizations that the CPU supports. The problem here is that while the CPU in question here supports SSE1, it does not support SSE2, and somehow the compiler puts in some SSE2 instructions anyway, even when specifically being told to only use SSE1 instructions. When I first got this problem I manually turned SSE2 off, but left SSE1 on, since my CPU supports SSE1. This did not work because somehow unsupported instructions were used anyway. Only turning off all SSE worked. SSE is not simply for multimedia, its a set of SIMD instructions, Single Instruction Multiple Data, so a single instruction can be used on multiple pieces of data simultaneously. It could speed some things up if the same thing has to be done to many pieces of data, doing many of them simultaneously. SSE1 is only 32 bit, single precision, and on the old Pentium III SSE instructions were pretty slow.

I too can confirm that this is a problem with SSE/SSE2 instructions on SSE1 only CPU's. I disabled all SSE instructions and it worked afterwards, but I believe someone else disabled SSE on a component by component (not quite sure what the jargon is since I'm relatively new to compiling) basis and found out there were 2 component libraries that were giving these problems. So turning off SSE for only those components works well too. I use this for an old Pentium III 933 MHz machine, but I've read about the same problem occurring on Athlon XP machines, which also have SSE1, but not SSE2.

I had exactly the same problem with the first mangos I compiled. For me it was an issue with unsupported instructions for the CPU. (Exception code: C000001D ILLEGAL_INSTRUCTION) Mangos uses SSE and SSE2 instructions, I was using a CPU that didn't support SSE2 (a Pentium 3 to be exact, but the same problem should exist in Athlon XP and earlier AMD CPU's) Setting the compiler to only use SSE, and not SSE2 instructions didn't help, the same problem continued to exist, but after I set the compiler to not use SSE at all it did work. It seems more people have had this same problem, but it is consistently misinterpreted as a script problem or a database problem, but it is actually an instruction-set problem, set your compiler to not use SSE and SSE2, and it should work fine.

I am quite certain the USA would be one of the very few countries to ban this. DLL injection however is a pretty ugly solution in my opinion, because it needs to be run on the client's machine. It is infinitly nicer than a regular modded client though. I don't know if DLL injection is also considered as modding the client in some juristictions (a lot of judges would probably not distinguish between modding in memory or the traditional modding). I also think the client is probably protected against it, and if not, it will be as soon as we manage to use it, so it would probably only work on older client versions when they protect it in a new patch. Cracking the key however is also probably only going to work on one client version, because they'd be pretty silly if they didn't change the keys with every patch. You'd have to crack the new key all over again with every new patch. It seems to me like the modulus size is rather big (I believe such a large key has not been cracked yet) so this would require a lot of processing power to do. A third option I've mentioned before is using PseuWoW. I think the required models and maps can already be extracted out of the Cataclysm client. So if you could make PseuWoW and MaNGOS use this data instead of of the 3.3.5a data, you could avoid all the Cataclysm client troubles. I'm probably making it sound easier than it is, since I have no idea what this would actually take. I wish I had some C++ experience so I actually knew what I was talking about, but sadly I do not.

I think all items that are bind on pickup should be excluded, I don't know if they already are, but I am assuming this is the case. It would be nice to have an option in the .conf file for other excluded items.

I hope I didn't make anyone think that I was saying multithreading, multiprocessing, and clustering should have a higher priority. There are many other things that are more important, and more complete functionality is far more important than bigger population servers. For me personally multithreading is pointless, I'm running my mangos server on an old single core machine, and quite happily, my internet connection can't handle more than about 30 users at a time anyway, and I don't have that many friends.

Clustering seems like it is still quite far off at this moment, even multithreading and multiprocessing on the same machine is very limited at best if you add the right patch (mtmaps does this, right?) You can only spread the load over several computers by giving the computers different functions. One login server, one world server, one database server (if I'm not mistaken there can in theory be 4 different database servers serving one realm), and if you want a seperate webserver, and maybe a seperate warden server if you want one. There is database server software that will do clustering, but the world server is most likely to be the bottleneck (my own observation is that the world server process produces more load than the other components combined, with the database server process as a distant second, the login server process produces next to no load, and I'm not using webservers or warden. This is an extremely low population server, so with higher population levels this might be different. My point is, scalability is very limited over more cores, or more machines.

The client still needs to recieve a valid key, one we can't generate. Manipulating the client in memory when it's running to make it think it recieved a valid key is probablty possible in theory if given plenty of efford, but would probably be illegal in some countries, just as a modded client is. And of course it's a very ugly and hacky solution.