Unkle Nuke

You are indeed right! The code base does need refactoring. Antz has been reworking parts as he goes along, but overhauling a decade of work is a mammoth task. There are opcodes that still have the status of 'UNK' in the cores. Some likely have no bearing on a private server, such as Battlenet client interoperability. There are a few that may reveal themselves to be necessary pieces to the puzzle. My hope is the formulas can be fixed correctly by researching archives of sites like Elitist Jerks and even making use of old versions of utilities like Rawr and Simcraft. I'll have to leave that one up to smarter people. Math and I have an uneasy truce, at best.

What I said still applies, even going all the way back to vanilla WoW 1.12. We still don't know everything as fully as we need. Otherwise, MaNGOS would have had 100% retail support for older WoW clients years ago. The development history of WoW private servers goes back a long way, with much of what is known based on the work of mostly hobby coders. They had no formal training and relied on their intuition as much as skill. On top of that, the constant push to get features working by any means, even if it was only "good enough", gave no incentive to get things totally correct. This eventually lead to guesswork somehow becoming gospel. Those who chose to question the status quo had to face the wrath of the developers in charge. Politics cemented this further with certain individuals seeking to protect their status within the community by keeping their knowledge for themselves. It's only grows more complicated by the fact that each new expansion made changes to file formats and data structures that required starting the research all over again.

Even if that were true, the point of kuJay's question was how a WoW server emulator is created from scratch without access to the actual retail server code. You are correct that much of the effort for older clients now is directed toward implementing and fixing features to replicate the game play as it existed at the time a particular client was current on official retail. That doesn't mean no further work is needed on the other areas. A lot of assumptions about the reliability of old research led to the perpetuation of bad information and data. There are still many opcodes whose functions are unknown. Certain file types were incorrectly analyzed in the past. Maps are only just now being correctly understood in their proper context, which has finally allowed transports to function properly after many years. There is still much data mining and reverse-engineering that needs done, especially for more recent expansions.

Well, us curmudgeons have to be poked once in a while, if only to make sure we're still breathing.

How do we do it? The short answer is actually more boring than you think... hours of studying hex code gathered from the client and network traffic with the server. The long answer I'm about to offer would have seen me burned as a heretic for spilling precious secrets, if this were still the old days, but MaNGOS today is about being free in every way. The three pillars of the MaNGOS Open philosophy are Open Source, Open Community, and Open Learning. So we all do our best to make sure the code is free, our door is open to everyone, and knowledge must be shared. A more complete answer must be prefaced with a brief trip to the past. Bear with me, if you please. Game server emulation has been around far longer than WoW itself, beginning in the late 90s with multiplayer games like Quake. Back then, these games often came with an official server you could install from the game disk so players could host their own multiplayer games. People smarter than me got curious and reverse-engineered these servers to create the foundation of knowledge and procedures that are still used to this day. MMOs use a centralized server, accessed over the Internet. One of the earliest examples is Phantasy Star Online, released for the Sega Dreamcast in 1998 and Windows a year later. So how do you create a server for a game when you don't actually have the server itself? The two basic tools used for creating a server emulator from scratch are the debugger and packet sniffer. I'll say more on that a little later. What I do know of the early genesis of WoW private servers is second-hand knowledge gained from the devs who'd been around nearly from the the beginning. It all began when a simple WoW sandbox evolved into a full server called Stormcraft. Early WoW p-servers were primitive by today's standard and closed source. Much of the game's features did not work correctly, if at all, and there was little anyone could do because the various devs kept their program code and knowledge secret. WoWDaemon (usually abbreviated to WoWD) was the beginning of the modern projects you see now, programmed in C++ and using an SQL database. So why the history lesson? Because every WoW server emulator in existence today owes a debt to those who came before. Whether it's MaNGOS or Ascent, or one of their many forks like Trinity, Cmangos, or Arcemu... we've built on over a decade of work by hundreds of developers. MaNGOS was started from a leak of the old WoWD server source. Standing on the shoulders of giants, as it were. The way this was all done involved using those two tools I mentioned earlier. First, a debugger is employed to dig into the heart of the WoW game client, reverse-engineering the client's inner workings to find opcodes and data handlers. Then a packet sniffer was used to save all the packets sent between the client and server during an actual game play session, also called "sniffs". A hex editor was frequently used to analyze file formats and the captured packets, allowing bright fellows to develop specialized tools to more efficiently sift through the client and network traffic for valuable data. Once it was understood how things worked, it then became possible to create compatible program code to make use of the methods and data that makes WoW playable. Since that time, specialized tools have been created to more efficiently get at the precious data needed to improve existing p-servers and keep up with new expansions so they can also be emulated correctly... eventually. It has taken all this time to get this far. I'm certain it will take longer still before anyone can truthfully declare any WoW p-server is 100% complete. That's a broad overview for you. As for the finer details, feel free to ask more questions. Either myself or someone will be happy to provide you the best information we have. I hope I've given you the answer you were seeking. Remember, MaNGOS belongs to you!

How to fix bugs? This one is easy! Take up knitting instead. Your sanity will thank you. Still, it's a well-written guide. I give it 10/10.

Last I checked, ike3 abandoned Cmangos and now supports only Trinity and Mangos R2 with his new mangosbot project which seems to be a continuation of Playerbot-AI, but he hasn't made any commits to it in roughly 3 months. Regardless, the entire reason I started this sub-forum was to drum up interest in creating a MaNGOS-compatible fork. Still waiting.

It's been several years, so please forgive the cobwebs and dust as I dredge up lost knowledge, but here's my thought: Since this server crash occurs at shutdown and it involves keys created by ACE, my money is on this error having something to do with the server logging. It seems something has gotten mixed up during the cleanup/shutdown process, possibly an incorrect value being returned to ACE by mangosd. Before ACE 6.3.0 was committed by Foereaper last month, the previous change was 6.1.7 committed in August. With this error not being reported until December, I'd say that points to something having changed with the server code. The other possibility could be the complications and pitfalls that arise when working with submodules in Git leading to source corruption. Has anyone tried compiling ACE with the Dump macros enabled or run MaNGOS in debug mode? Either or both would give more information than the console errors. Assuming the server crash doesn't completely prevent logging, try setting the logging level to verbose in the mangosd config. That would at least give an overview of what's happening during the shutdown process. Valgrind hasn't been used in years, since nearly all of our devs are Windows programmers, and I know of no comparable replacement for Windows that doesn't cost an arm and a leg. Antz may be able to demonstrate how to use Visual Studio to trace and debug MaNGOS with similar results. I agree with Olion's assessment. ACE has been regarded much as a plug-in module you simply add and then forget about it. This library is at the very heart of the server so it is wise for everyone who touches core functions to become familiar with it. By the way... When you're reporting a bug, it's status should not be set to "Confirmed" until there is at least one other user replying with a similar experience.

This is to kick off discussion, debate, and planning for continued development of the playerbot mods for MaNGOS. Once things get rolling, authors and their collaborators can start threads for their work. I would prefer to see a unified Playerbot development, with ports/backports for each version of MaNGOS being overseen by the Playerbot project leader. Let's avoid having completely separate projects for Playerbot-Zero, Playerbot-One, Playerbot-Two, etc. Otherwise, we'd end up with a mess, where code for one version of Playerbot is incompatible with another. Some issues that could be addressed: ------------------------------------ To avoid confusion, rename Playerbot-AI. A new name can be decided upon by a forum Poll, if you like. Otherwise, I'll leave the new name up to whoever takes on the work. While you're at it, could someone please make Playerbot-AI into a real mod? By that, I mean separate the code into a patch that can generated by running a diff against MaNGOS. Right now, the mod is mixed in with a lot of other patches added by Ike because the Playerbot-AI code is only a part of his custom fork of MaNGOS. If possible, let's try merging the best features of Playerbot and Playerbot-AI into a single code base. It would make things a lot easier than having to develop and maintain two separate projects, along with their branches for each version of MaNGOS. Seeing bots for PvP finally implemented! Having bots which you can duel, fight in Outdoor PvP zones, or fill out teams in arenas and battlegrounds are just as important for low-pop servers as having a party for PvE. PvP bots should be designed to use NPCs instead of player characters. Their behaviors can then be scripted through EventAI, similar to the way a dungeon boss can be scripted. The EventAI module might need to be modified to achieve this functionality. More development of sophisticated AI for all of the bots. Instead of having the Class/Spec AIs for the player character bots hard-coded into the Playerbot core, move them into the scripts also, where behaviors can be properly triggered by the EventAI, if this is possible. However, this may require more modifications or additions to the EventAI code. Playerbot-UI Addon was developed for the Playerbot master at the time, which supports WoTLK 3.3.5a. Because of differences in the API between client versions, it might be necessary to develop separate PB-UI Addons for each. That is, unless someone who knows addon development well enough to: 1. Create a modular version, with a main function and version-specific modules the player copies into their client's addons folder. 2. Create a single addon that dynamically detects your client version, then loads only what is needed for a specific client. Playerbot-UI still needs a lot of work. It's current code should be regarded as alpha stage, at best. One last thing... The repositories and branches for the MaNGOS versions of Playerbot, Playerbot AI, and Playerbot-UI Addon can disappear at any moment, since they are no longer maintained by their authors. I will try to fork them into a new repository as soon as I can, but I advise anyone who thinks they might want to join in on a new project for this to clone blueboy's, Ike's, and Gitch's code immediately. Okay, I'll surrender the soapbox to the rest of you. Let's see some good ideas!

Incorrect or missing target flag in the script would be the first thing to examine.

You should also be able to adjust respawn times in the server config file, unless some wingnut removed that feature.

Thank both of you, Nikon and Madmax! The last binary for Quice I had in my archives was v1.29. Impressive job compiling the Quice sources, Nikon. Will you be continuing development of Quice? And you have shown your resourcefulness knows no bounds, Max. :cool:

The Github mirror for the only know official Quice repository is here. The original SVN is at Sourceforge. It appears the committed code is versioned 1.3.0 alpha. So where did 1.3.2 come from? Has someone forked Indomit's work and picked up where he left off? If so, please provide a link to the binary and/or sources as I have been unable to find anything, despite extensive searching. Indomit nuked his site and download mirrors. I'm actually surprised he didn't burn his repos to the ground while he was at it. Given that so many tools and utilities seem geared to Cmangos these days, it sure would be nice if we could carry on development of Quice to fully support MaNGOS. Anyone know Delphi, the language used to code Quice? Pascal would do, I suppose. Taken from Indomit's Readme, to compile Quice you need the following: Delphi XE ZeosDBO - http://zeos.firmos.at/portal.php JEDI - http://jvcl.sourceforge.net/ For compiling older versions Of Quice: Delphi 2007 ZeosDBO - http://zeos.firmos.at/portal.php JEDI - http://jvcl.sourceforge.net/ TMS Unicode Component Pack - http://www.tmssoftware.com/go.asp?tmsuni Alpha Skins - http://www.alphaskins.com/ I wonder if porting it over to C++ would help spur continued development? Given the work of Devs like Antz and others on various editors and utilities, do we even need Quice these days?

AI Playerbot was originally developed for MaNGOS Two (3.3.5a WoTLK), but ike decided to work on it for other projects like R2 and Cmangos. There are branches in his repo for MaNGOS Zero, One, and Two. However, ike never went past 3.3.5a. We would love to see some of you in our community take up this project and develop versions for MaNGOS Three and Four, plus keep the code for Zero, One, and Two updated. So who is up for the challenge?

This document is a work in progress. Expect plenty of rewrites until the final version is stickied.

Git can be a challenge, especially for those who have been brainwashed by other version control methods like CVS or Subversion. Honestly, Git isn't that hard, once you let go of old ideas and embrace the concept that code can exist in an ever-changing state which can then be frozen in a snapshot of time for your review. I was once like you, a lost soul, but I was brought into the light! Even as I was shown the way, let me guide you to the holy texts and free your minds, brothers! If you need an introduction to Git, check out these resources. They're all free!: Try Git lets you learn how Git works by using it in your web browser. No software installation needed! Git's documentation page is where you can find the Git Pro Book, the Git Manual, and some introductory videos. And that's just for starters! The Git Pro Book, is also free to download in PDF, EPUB, or mobi formats. The Git Manual is also included with the Git client, as man pages, plain text, or HTML, depending on which platform you are running Git. While you're there, don't forget to download the cheat sheets, for quick access to Git's most commonly used commands and workflow at a glance. Too much more to list here. Give the entire site a good long look. The Git Reference is an online manual, similar to the Git Manual, but it focuses on actually working with and setting up Git. Kernel.org also has a mirror of the Git Manual Git Immersion is an online training course that promises to teach you the fundamentals in a "learn by doing" style. If you don't already have Git installed, they provide links to the client version you will need as the first step. Git Reference has a similar title to the official Git Reference, but it is meant to be a quick reference for learning and remembering the most important and commonly used Git commands. As you work through each section, every page will also link to more in-depth Git documentation and provide you with an immersive experience that lets you go as deep as you want. Git Magic is an excellent online book that I highly recommend everyone have on their virtual bookshelf. It has a practical, hands-on approach that teaches you how to use Git by the way you should use Git. Also available in PDF, simplified HTML, and as packages for Debian and Ubuntu (Actually a compressed, lightwieght copy of the web site itself for offline browsing. Did I say it was good, or what?). Ry's Git Tutorial is mapped out by subjects, in order from beginner to advanced. This one has to be among the best there is for this type of tutorial. Each lesson covers using Git in an actual project, by working with example code and patches on your very own Git repository! If the all the other books, docs, and tutorials just seem too confusing, I'm sure Ry's Git Tutorial is the one for you! Github Help covers just about every possible question, topic, fact, subject, method, and everything else related to using Github. You definitely want to save this web page in your browser! That should have you working with Git like a seasoned hacker in a very short time! That gives us more opportunity to help with the MaNGOS-specific problems you may encounter.

To ensure proper generation of annotated code, please use DoxyGen style comments. This is a bit similar to JavaDoc comments and other automatic code documentation generators. Single-line documentation or comments should be placed following three slashes. ///This is a single line. I only had a brief thing to say regarding some code. Documentation and comments that require more than one line should be enclosed in a comment block, which consists of a slash and two asterisks to show the start while the end is indicated by one asterisk and a slash /** ... ... */. All lines between the comment block markers begin with a single asterisk *. Here's an example that shows most useful keywords you can use in a comment block: /** * This function does something very useful. If used with care, this function * has the potential to make your programs really really useful. * * \arg \c x * The x argument specifies a integer that is transformed into something useful. * \arg \c y * This argument, if not NULL, is a pointer to a free memory area where this * function will put something really really useful. * \return * A useful value, or NULL if error. * * Here is a example that you can paste into your code so that it saves you a * lot of typing: * * \verbatim * for (int x = 0; x < 100; x++) * printf ("DoSomethingUseful%d = %s\n", i, * DoSomethingUseful (i, &ScratchPad)); * \endverbatim * * Paragraphs are split from each other by inserting a empty line. Also some HTML * tags are supported, like <ol> [<li>...] </ol> and <ul> [<li>...] </ul> for * ordered (numbered) and unordered (dotted) lists respectively. */ char *DoSomethingUseful (int x, void *y); /// This is a one-line comment void Something (); For comments and documenting not intended for printing by DoxyGen, use normal comment markers (// and /* ... */). These can be notes to yourself or remarks meant only as part of the work in progress. In addition, when you comment-out a line or more of code to prevent it from being used in the source when compiled, use two slashes ( // )at the beginning of each line of code. This is useful for having code as a placeholder until the full function has been completed, a bug remains unresolved elsewhere that breaks your code, or you wish to place debug routines that are not used for normal execution. Please remember to also add a note that the code has been disabled and the reasons for this. Use the standard outlined above for documentation and comments when doing so. void WorldSession::HandleSetSheathedOpcode( WorldPacket & recv_data ) /* * This should fix the problem with weapons still being seen as sheathed by * the client. Should make players happy to know they can now use their * weapons in combat! * Once this has been reviewed, I can do some proper documenting. */ { uint32 sheathed; recv_data >> sheathed; //Uncomment the following only when debugging the function. //DEBUG_LOG( "WORLD: Recvd CMSG_SETSHEATHED Message guidlow:%u value1:%u", GetPlayer()->GetGUIDLow(), sheathed ); if(sheathed >= MAX_SHEATH_STATE) { sLog.outError("Unknown sheath state %u ??",sheathed); return; } GetPlayer()->SetSheath(SheathState(sheathed)); } Remember, use DoxyGen style markers when you want your comments and documentation to be printed out. Use standard markers for comments and documents you do not want printed by DoxyGen, but need to make notes about the code for yourself and other devs.

It is highly recommended to use a single coding style for the whole project source code. Exceptions are allowed for independent libraries used in the project, but it is generally advisable all contributors to use the style specified here. Failure to adhere to these standards can result in your submitted work being rejected until it has been brought into compliance. Tab Length All tabs used in code editing consist of four blank spaces. If your editor allows configuration of the <Tab> key, please set it to use four spaces. Otherwise, do not use the <Tab> key! Instead, use the <Space> key and type in four blank spaces manually. Tab lengths other than four blank spaces are unacceptable. The Microsoft Visual Studio C++ code editor has tabs set to four spaces by default. Line Length (or Width) Please use 80-column width, or 80 characters, for line length. This includes spaces and punctuation. If your line is longer than that, please split it into two or more lines. If it's sometimes a little longer, by just a few characters, then it may be permitted at the discretion of the Code Reviewer. If you're splitting text inside brackets { }, the continuing text should be indented to the position after the opening bracket. printf ("This is a example of how we split lines longer than 80 characters\n" "into several so that they won't exceed this limit.\n", max_sourcecode_width); If you have long strings, you can split them as shown above, just remember that C/C++ compilers will glue together several strings that come without any special characters between them into a single string. Brackets When writing C++ code, brackets are placed symmetrically, with the ending bracket lined up to the opening bracket. if (something) { some function ...; } else { some function ...; } switch (x) { case 1: printf ("X is one!\n"); break; case 2: { printf ("X is two!\n"); break; } } Every bracketed block moves its contents by one tab to right. Labels (but not case selectors!) and public:/private:/protected: C++ keywords are placed at the leftmost indented position for the current block, that is, in the same position where enclosing brackets are. Also please don't use brackets around a single statement because it clutters the code; use brackets only when using non-obvious constructs, like: if (foo) { if (foo) some function ...; } else some function ...; Also, please place one space before opening parenthesis. Before, but not after: ( the if( blah ) style is a no-no! ) (the if (blah) style is correct!) Following these few and simple formatting styles with your work for MaNGOS will ensure it is readable and easily understood by every developer on the project.

As far as submitting your work to one of the MaNGOS cores, the work flow here is still being fleshed out. For now there are three accepted methods, listed in order of most to least preferred: [li]Fork the core upon which you wish to work, then use merge requests to indicate the patch you wish to be added to the core.[/li] [li]Create a patch file and then paste the .diff contents into a post in the appropriate forum.[/li] [li]Notify a Core Dev of the URL for your fork and the commit of your patch.[/li] Creating a patch file can be done simply, by using the following Git commands: $ git checkout my_funky_branch $ git rebase origin/master $ git format-patch --stdout origin/master.. > my_funky_patches To keep your fork properly up to date with the official MaNGOS repository, while preserving your own work that has not yet been submitted, use git pull –rebase instead of git pull to merge the latest changes from MaNGOS. Rather than cluttering the history with a merge commit, it reapplies your changes to the latest upstream in the project repository. The only caveat is that you shouldn’t use this method if you’ve already published the changes to another repository. Doing so would cause problems for anyone who has already downloaded the original commits. While Git will accept just about any commit message you feed to it, sticking to best practices makes the log a lot easier to work with. A commit message template is shown below: Short (50 chars or less) summary of changes on this line More detailed explanatory text here, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Further paragraphs come after blank lines. Use a hanging indent. Bullet points are okay, too. Typically a hyphen (-) or asterisk (*) is used for the bullet, preceded by a single space, with blank lines in between. Following these practices helps to ensure we keep a clean and easily understood history, minimizing the problems that can arise from those who make commits from "dirty" repos.

The first thing you do should be to configure a name and email. By default, Git chooses a name based on the GECOS data (which is probably right) and a default email based on your login and hostname (which is almost certainly wrong). Best practices dictate using your real name and email here, not any other aliases you may have, but you may wish to use something other than your real name and personal e-mail if privacy or legal reasons warrant it. These fields will be immortalized in the repository history so make sure you get them right and use the identity by which you wish fame and glory to be heaped upon you. $ git config --global user.name Your Name $ git config --global user.email [email][email protected][/email]ess While you’re configuring, you may want to enable coloring for some commands: $ git config --global color.diff auto $ git config --global color.status auto $ git config --global color.branch auto $ git config --global color.interactive auto If you prefer to use an editor other than the default Vi, such as emacs in the example, specify it like this: $ git config --global core.editor emacs Finally, to properly handle line feeds between Windows and Linux, Windows users can use the following setting: $ git config --global core.autocrlf auto DOES NOT WORK ON CURRENT VERSION OF msysGit. Checking if this is due to a bug or changes to Git's config. It is NOT recommended to set autocrlf to "true" as this forces converting CRLF into LF, which has been known to cause issues. Linux users can set Git to automatically fix CRLF that can sometimes sneak in when a Windows user makes a commit by converting them into standard LF when making a commit: $ git config --global core.autocrlf input

A Foreword by Unkle Nuke In the interest of continuing to give structure to how we work here at MaNGOS, I have republished our Standards And Practices, with modifications and updates by me as necessary while preserving the instruction and intent of the original. Some parts were scrapped entirely and rewritten by me to be more informative and current with the progress of time and the MaNGOS sources. This document, in another form, was originally published on the old MaNGOS web site. I don't have a bibliography as to whom the original author or authors were, but I strongly suspect TheLuda's involvement, at least. If any of our current members had a hand in this document or know who did, please feel free to message me with the details so I may give credit where it is due. We are all here because we have stood on the shoulders of giants. While it's focus is primarily on server core development with C++, much of what is presented here can be useful for all MaNGOS developers. I now call upon those masters of database and scripting to step forward and offer any recommendations to this document, so it may be as complete as possible. If anyone notices errors or omissions, please message me with any necessary corrections. This is an ever-evolving document, in keeping with changes to how we work and the technology with which we do that work. Somebody may want to mirror this in our wiki, too... Chapter 1, Page 1 "So You Want To Be A MaNGOS Dev?" Introduction While we here at MaNGOS do our utmost to extend a helping hand to those in need, there is never enough precious time to do everything that needs to be done. You can help us with that by making your best effort to help yourself. When you can learn the basics before jumping into things, it allows us more time to answer the really hard questions about MaNGOS development. What follows is one avenue where you can teach yourself some valuable fundamentals in how to be a MaNGOS Developer. The rest, and everything that follows, is built upon what you will now read. This is the official document outlining all the basic methodology for existing and prospective developers. It offers recommendations for everything from correctly configuring and using your Git client, to proper coding style for core patches, to submitting and reviewing code. All developers and patch contributors are strongly encouraged to read and adhere to these guidelines. Of course, you're free to do as you wish, but it would be nice if you could work with us on this, especially if you want to work with us! Herding cats? Been there, done that.

Whew! It's taken a while, bouncing from one URL after another and getting my account lost in the shuffle, but it's great to be back! Antz, my heartfelt thanks for putting up with me and not giving up at even the darkest times. Your dedication and persistence, never giving in when it was far easier to quit, is an inspiration and example to us all. madmax, you've done an awesome job with the nuts-n-bolts technical stuff. Thank you for laying the bricks of our new home and making these forums more interesting with a set of rich features. After the old forum's minimalist layout, you and Antz are spoiling everyone with luxury! Respect! 8) As for me, I rededicate my promise in always striving to promote and support the ideals that have made MaNGOS the standard in private MMO server development. I'll keep helping any way I can! Those who hold onto hate only poison their own hearts. I think many now see the lesson of history still holds true, that you can't kill an idea. MaNGOS will always exist so long as even one person remains that believes in the ideals upon which we began. Still, a good anti-DDoS protection does help. ;D To all of our members: We must never forget MaNGOS exists because of those who believe in the worthiness of this community and its projects, devoting significant portions of their lives to give this gift to you. MaNGOS will always stand by the three pillars of its foundation: Open Source, Open Learning, and Open To All. Let us all honor this gift we have by always being generous and helpful toward each other. We Administrators are not your masters, nor is anyone else. We are only the stewards of the MaNGOS legacy built by each and every one of you. In turn, we only ask that all of you do your best to keep MaNGOS thriving and growing. All of the projects belong to everyone. This means you are free to jump right in and work away at whatever you like for the benefit of all. Have you got the urge to make a patch for WoTLK or do you think you can make a MoP server better than the official project? Not one of us has the right to say you can't do those things. Your ideas just may prove to be exactly what we need! Remember, it's your MaNGOS, too! It will only ever be as good as you all work to make it. So get involved! Tell your friends! Don't stop until our members and developers number into the millions!

I think it would be a fun technical stunt to create an Android-compatible MaNGOS, so those with capable devices could create an ad hoc server network using the Wi-Fi Hotspot feature. With more and more RPG games being "online only", I would love to lay hands on some server emus so I can enjoy playing them without all the expense or morons that delight in griefing and cheating. SW: Galaxies and EvE are two that top the list. Although I can be content with KOTOR and Homeworld instead for similar action. I agree with your assessment. Elder Scrolls is a series every bit as rich in lore as Warcraft, with at least as large a fanbase. Provided they avoid making the game into an obnoxious moneypit, I would imagine the players will flock to the servers in droves for the chance to adventure in the world of TES with their friends for free. Activision will have to come up with something better than kung-fu pandas and free until level 20 play to stem the hemmorage of lost WoW subscribers. The first time I loaded up Morrowind, it blew my mind! TES III was the first time I had ever played an RPG that was done from a first-person perspective. The world and its inhabitants were so detailed, and not just in a graphical sense, plus the story and quests being so well scripted that I was completely enthralled and totally hooked. The TES Construction Kits released along with them was the cherry on top of what has to be two of the greatest RPGs I've ever played. How cool is that? Worlds to explore and the tools to expand them even further! I have always had the opinion that WoW should have content creation tools and make available servers for the community to share and test their creations. Perhaps the cream of the crop would then be eligible for inclusion in the regular servers. A Minecraft approach to world-building would keep the game thriving for at least another ten years! It will never happen. The devs couldn't take being shamed by a bunch of amateurs releasing stuff that outshines what they produce on a deadline and limited budget. TES III and IV both have permanent homes on my PC. If there's no "online required" DRM, Skyrim will join that lineup as soon as the price drops to $20 or less.

You can count me among those 60 or so users. Even though MaNGOLin may end, it is you that I shall miss. You have always been an example to other devs of gentility, technical skill, and respect. We seem to have lost those qualities around here in the past few years. I intend to use MaNGOLin until WoW and MaNGOS are so dated that they won't run on whatever passes for a PC in the future! Thank you for this most recent bugfix. You have always been conscientious about the quality of your work, which is one reason why MaNGOLin is the standard by which I judge other MaNGOS offerings. I'm very sure the decline you've seen for MaNGOLin on your site is entirely due to an overall decline in interest for WoW by the general public, not just the private server scene. Blizzard is probably scratching its collective head, trying to figure out where things went wrong. My personal opinion is their failure to really deliver an expansion that was at least on par with the addition of Outland in TBC initiated the decline. Each successive release seems to nerf and oversimplify the game to the point of mediocrity while failing to follow through with promising features. Heroic classes began and ended with the Deathknight while Jewelcrafting was dead-ended in favor of much more useless professions. Of course the list of failures is too long to list here, but you get my point. I think Titan will be an enormous disaster. Blizzard is feeling the pressure to adopt the F2P model, paying the bills with a store to sell gear, items, and even levels. Since Activision has taken over, you can bet this will be implemented in the worst way, as if Titan were no different than another Call Of Duty from a business point of view. Perhaps hosting MaNGOLin on Github would be even cheaper still and allow others to collaborate with you, assuming you don't mind making it open source. Perhaps inviting others to help will not only keep the software alive, but expand it to accomodate other server cores (ArcEmu, Ascent, Skyfire, WCell, and Trinity) so your user base may once more increase. Otherwise, you may consider focusing on creating some sort of generic game server admin utility, where the games supported are implemented by scripted plugins. You keep the core proprietary, but release a plugin SDK with the stipulation that any created plugins be open source. This would leverage "crowd sourcing" expansion of the software while leaving you firmly in control. Plugins could add the neccesary commands, alter the gui as needed, or even create modules to expand functionality... like plugging in to Thottbot or WoW Armory to pull data for importing to the database or allowing the admin to chat through the utility with players in the game.

bannor, you have given so much to this community. I find it appalling that not one person has donated, not even as a "thank you". I would have done so many times, because your MaNGOLin admin utility has been on my "must have" list for years. Unfortunately, I can't give you what my heart says you deserve, thanks to my own financial rock-and-a-hard-place. Antz, we should try to show some measure of gratitude to bannor's dedication, as a community. I vote we place a permanent banner and link for MaNGOLin on our website, advertising it as an official "Friend Of MaNGOS " and endorse the use of MaNGOLin, along with a "donate" button that links back to bannor's PayPal (or whatever). I think it would also look nice having it just below our own donate banner in the forums, as well. What do you say, Mr. Webmaster? Ain't it about time we show official support for our devoted friends? Goodness knows we need all of them we can get these days!