Vanilla-MaNGOS is an open-source Vanilla WoW emulation project. It is a continuation of the Nost family of projects, which branched from MaNGOS-Zero several years ago. It was developed privately by the Nost team until late 2016, when the source code was transferred to the Elysium Project who made it open source. Unlike other emulation projects like cMaNGOS and TrinityCore which only seek to recreate the last patch of each expansion, this project aims to provide full content progression through Vanilla WoW.

• Server Repository
• Database Repository
• Script Editor

The emulator has three major components. The first things you'll encounter are the binary files, the programs which make it possible to connect and play. Two there are, no more, no less. A login server (realmd) and a world server (mangosd). As its name implies, the login server handles player login, provides the list of available realms, and connects the client to the world server once he has successfully authenticated and chosen a realm. The world server is what makes the fun parts possible. It controls all in-game interactions and communicates with the player clients. It is what allows you to experience the world. It is the underlying laws of nature that govern how the world works. What the world contains is stored in the database. Without a database, the world would be empty, except for the naked players wandering around in the void. The database is the stuff you see in the world. It is the creatures you fight, the quests you go on, the items you struggle to acquire. The atoms the world is made of are defined in the database. All of this comes together to create the World of Warcraft that you play.

What makes vMaNGOS special is that it aims to recreate all content changes throughout Vanilla WoW, starting all the way back from patch 1.2 to the 1.12 you are most familiar with. It is a project for the people who loved all of Vanilla and realize that 1.12 was only the end of the journey. In order to make this journey possible again, we've redesigned the way database data is stored and loaded. We've embraced the fact that things exist not only in space, but in time as well, so all content needs to have an extra field value indicating when this particular version of it came into existence. These values start from 0 for patch 1.2, and go to 10 for patch 1.12. The world server will automatically load the most appropriate version of the content, based on the current patch value that is set in the configuration file. All it takes to change content patches is this one setting. There are no extra SQL files that you need to run in order to change the patch.

Another big aspect of the progression system is game client progression. That means being able to play with the patch appropriate game clients, not just the 1.12 client which every other project sticks to. This endeavor is much more complicated than content progression, as it requires numerous corrections to the way the client and server communicate. As the game evolved and grew, new features and quality of life improvements were made, which necessitated changes to the way data was stored and handled. In order to support old versions of the client, all changes to the structure of packets exchanged between the server and the client need to be identified and their old implementations reconstructed. Another requirement for supporting old client versions is to make sure all content added after the targeted patch has the correct minimum patch assigned, as encountering a creature with a model added in a later patch for example will cause the client to crash. The upside of doing full client progression however is that you get to experience ALL aspects of that patch, including old talent trees and changes to spells.

You can see which clients are currently supported in the core repository's readme file. Note that only the last version of each major patch is supported.