OlympusCore (Cataclysm 4.3.4) - Wiki Educativa

Descripción general

OlympusCore es un emulador de servidor de World of Warcraft diseñado para la expansión Cataclysm (parche 4.3.4). Basado en TrinityCore, ofrece una plataforma completa de servidor de juego capaz de albergar partidas multijugador con mejoras y modificaciones personalizadas.

El servidor gestiona las conexiones de los clientes, mantiene el estado del mundo, procesa las acciones de los jugadores y guarda datos persistentes de los personajes usando múltiples bases de datos. OlympusCore soporta las mecánicas completas del juego: progresión de personajes, sistema de hechizos, combate, gremios e instancias.

Descripción general de la arquitectura del sistema

OlympusCore sigue una arquitectura en capas, con separación clara entre:

• Configuration & Scripts — administración de configuración y sistema de scripts.
• Persistence Layer — pools de bases de datos y persistencia.
• Core Game Systems — lógica del juego (mundo, sesiones, objetos, hechizos).
• Application Layer — punto de entrada, orquestación y servicios.

Elementos principales:

Application Layer
 ├─ main() Entry Point
 ├─ Command Line Processing
 ├─ Master Class
 └─ Service Orchestration

Core Game Systems
 ├─ World Singleton (Game State Management)
 ├─ WorldSession (Client Connection Handler)
 ├─ ObjectMgr (Game Entity Management)
 └─ SpellMgr (Magic System Management)

Persistence Layer
 ├─ WorldDatabaseWorkerPool (Static Game Content)
 ├─ CharacterDatabaseWorkerPool (Player Data)
 ├─ LoginDatabaseWorkerPool (Authentication)
 └─ BlizzDatabaseWorkerPool (CMS Integration)
        

Arquitectura de la Base de Datos

El servidor utiliza una arquitectura multi-base de datos para segmentar tipos de datos y responsabilidades.

Database Connections
 └─ Database Worker Pools
     ├─ WorldDatabaseWorkerPool (Static Content Management)
     ├─ CharacterDatabaseWorkerPool (Player Persistence)
     ├─ LoginDatabaseWorkerPool (Account Authentication)
     └─ BlizzDatabaseWorkerPool (Vote/Donation Points)

Databases
 ├─ World Database
 │   ├─ Creatures, Quests, Spells
 │   └─ Items, Loot Tables
 ├─ Character Database
 │   ├─ Player Characters
 │   └─ Inventory, Progress
 ├─ Login Database
 │   ├─ Accounts, Realms
 │   └─ Access Control
 └─ BlizzCMS Database
     ├─ VP/DP Currency
     └─ Web Integration
        

Componentes clave

Lista de los componentes más importantes del sistema, con su propósito y clases/clasificaciones principales.

Características del servidor

OlympusCore extiende TrinityCore con varias mejoras propias que uso en mi servidor:

• Sistema de XP dinámico: multiplicadores de experiencia por horarios (CONFIG_XP_BOOST_DAYMASK).
• Progresión de títulos PvP: recompensas automáticas por kills honorables.
• Reset de duelos: restauración de cooldowns y recursos tras duelos.
• Integración con BlizzCMS: gestión de votos (VP) y puntos de donación (DP) mediante base de datos dedicada.
• Configuración avanzada: múltiples opciones y ajustes en worldserver.conf.

Ejemplos de scripts relacionados:

• src/server/scripts/World/boosted_xp.cpp (sistema XP dinámico)
• src/server/scripts/World/system_pvptitles.cpp (títulos PvP)
• src/server/scripts/World/duel_reset.cpp (reset de duelos)

Sistema de construcción y dependencias

OlympusCore utiliza CMake para compilación multiplataforma con dependencias en:

• Bibliotecas Boost: Versión 1.67+ (Linux) o 1.78+ (Windows) para utilidades del sistema
• OpenSSL: Funciones criptográficas y comunicaciones seguras
• MySQL: Conectividad de base de datos y funcionalidad ORM
• ACE Framework: Programación de red y primitivas de multihilo

La integración de Boost está configurada en dep/boost/CMakeLists.txt:12-61 con definiciones de compilación específicas para un rendimiento óptimo.

Entorno de desarrollo

Entorno Windows

• Windows 10/11
• Visual Studio 2017 o superior
• OpenSSL 1.1.1 / 3.x
• MySQL 5.7 / 8.x
• CMake 3.8+
• Boost 1.78

Entorno Linux (Debian 10/11)

• GCC 7.4.0 / 10.2.1 o Clang 6.0.0 / 11.0.1
• OpenSSL 1.1.1 / 3.x
• MySQL 5.7 / 8.x
• CMake 3.8+
• Boost 1.67 / 1.74

Requisitos de datos del juego

El servidor requiere datos extraídos del cliente del juego:

• MMAPS: Datos de mallas de navegación para el pathfinding
• DBC: Archivos de cliente que contienen reglas y constantes del juego
• VMAPS: Mapas de visibilidad para cálculos de línea de visión
• MAPS: Mapas de terreno y alturas para validación de movimiento

Fuentes

Fragmentos y referencias extraídas de mi árbol de código y archivos de configuración:

• src/server/worldserver/Main.cpp (líneas: 74–158)
• src/server/worldserver/Master.cpp (líneas: 114–364, 367–488)
• src/server/game/World/World.h (líneas: 103–433, 649–715)
• src/server/shared/Database/Implementation/BlizzDatabase.h (líneas: 17–37)
• src/server/shared/Database/DatabaseEnv.h (líneas: 42–46)
• src/server/scripts/World/boosted_xp.cpp, system_pvptitles.cpp, duel_reset.cpp
• CMakeLists.txt, README

Arquitectura del servidor

OlympusCore implementa una arquitectura distribuida de servidor privado de World of Warcraft compuesta por dos aplicaciones principales: worldserver y authserver. Este documento ofrece una visión general de la infraestructura del servidor, las relaciones entre componentes y la organización del sistema.

La arquitectura sigue el principio de separación de responsabilidades: authserver maneja la autenticación y la gestión de reinos, mientras que worldserver administra el mundo del juego, las sesiones de jugadores y las mecánicas de jugabilidad. Ambas aplicaciones comparten infraestructura común para la conectividad de base de datos, la gestión de configuración y el manejo de hilos.

Arquitectura general del sistema

OlympusCore implementa una arquitectura de doble servidor donde authserver y worldserver operan como procesos separados con responsabilidades distintas. El sistema utiliza bases de datos MySQL para la persistencia y soporta operación multi-hilo para escalabilidad.

Resumen de arquitectura de doble servidor

• Configuración: authserver.conf, worldserver.conf
• Capa de base de datos: LoginDatabase, WorldDatabase, CharacterDatabase, BlizzDatabase
• World Server: main(), Master, WorldServerSignalHandler, sWorld, sWorldSocketMgr
• Auth Server: main(), AuthServerSignalHandler, RealmAcceptor, sRealmList
• Cliente WoW: Conexiones de login/autenticación y tráfico de juego

Puntos de entrada de la aplicación

Componentes de infraestructura clave

• Gestión de configuración: sConfigMgr, authserver.conf, worldserver.conf
• Gestión de red: sWorldSocketMgr, WorldSocket, RealmAcceptor
• Núcleo del juego: Master, sWorld
• Autenticación: sRealmList
• Bases de datos: Worker Pools para World, Characters, Login y BlizzCMS

Responsabilidades de los componentes

Arquitectura de hilos y concurrencia

Ambos servidores implementan arquitecturas multi-hilo para manejar operaciones concurrentes. worldserver utiliza un modelo más complejo debido a sus requisitos de procesamiento en tiempo real.

• WorldRunnable: Prioridad más alta, ejecuta el bucle principal del juego
• CliRunnable: Prioridad normal, procesamiento de comandos de consola
• RARunnable: Prioridad normal, administración remota
• TCSoapRunnable: Prioridad normal, servicios web SOAP
• FreezeDetectorRunnable: Prioridad más alta, detección de bloqueos

Manejo de señales y gestión de servicios

Ambos servidores implementan un sistema completo de manejo de señales para apagados seguros y capacidades de gestión de servicios, especialmente importantes en entornos de producción.

• Señales soportadas: SIGINT, SIGTERM, SIGBREAK (Windows)
• Acciones de apagado: World::StopNow(), limpieza de hilos y salida de procesos
• Soporte de servicios Windows: Instalación, ejecución y desinstalación (solo en worldserver)
• PID Files: Soportados en ambos servidores

Punto de Entrada de la Aplicación y Gestión de Servicios

Archivos fuente relevantes: Esta sección cubre los puntos de entrada principales para los ejecutables worldserver y authserver, su gestión del ciclo de vida de servicios, arquitectura de hilos y manejo de señales. Para más detalles sobre el sistema World y el bucle de juego, ver World System and Configuration. Para la gestión de conexiones de base de datos, ver Database Layer and Object Management.

Visión General

OlympusCore consiste en dos aplicaciones de servidor principales que manejan diferentes aspectos de un servidor privado de World of Warcraft:

• worldserver: Servidor principal del mundo que gestiona sesiones de jugadores, lógica de juego y simulación del mundo.
• authserver: Servidor de autenticación que maneja inicio de sesión, listas de reinos y validación de cuentas.

Ambas aplicaciones siguen patrones similares para inicialización, carga de configuración y gestión de servicios, pero difieren en arquitectura de ejecución e hilos.

Puntos de Entrada de la Aplicación

Worldserver

Se inicia en src/server/worldserver/Main.cpp (líneas 80-170). Secuencia de inicio:

1. main()
2. Analizar argumentos de línea de comandos
3. Cargar worldserver.conf
4. Mostrar banner
5. Crear y ejecutar instancia Master
6. Retornar código de salida

Operaciones de servicio en Windows: instalar/desinstalar servicio, ejecutar como servicio.

Argumentos soportados:

• -c config_file → especificar archivo de configuración
• -s install/uninstall → instalar o eliminar servicio (Windows)
• --service → ejecutar como servicio (Windows)

Authserver

Se inicia en src/server/authserver/Main.cpp (líneas 84-250). Secuencia de inicio:

1. main()
2. Analizar argumentos de línea de comandos
3. Cargar authserver.conf
4. Mostrar banner
5. Inicializar ACE Reactor
6. Inicializar base de datos
7. Cargar lista de reinos
8. Iniciar Network Acceptor
9. Ejecutar Reactor Event Loop
10. Apagado y limpieza

Arquitectura de Gestión de Servicios

Ciclo de Vida de la Clase Master (worldserver)

• Configuración OpenSSL & Crypto
• Crear archivo PID
• Inicializar bases de datos
• Inicializar configuración del mundo
• Configurar manejadores de señales
• Lanzar hilos de servicio
• Iniciar servicios de red
• Marcar servidor como listo
• Esperar señal de apagado
• Limpieza y cierre de bases de datos

Hilos principales: WorldRunnable, CliRunnable, RARunnable, TCSoapRunnable, FreezeDetectorRunnable

Inicialización de Base de Datos

Gestión de Hilos

Modelo Worldserver

• Arquitectura multihilo con cada servicio en su propio hilo
• Prioridad más alta para World y FreezeDetector
• Hilos CLI y SOAP creados según configuración

Modelo Authserver

• Monohilo basado en ACE Reactor
• Hilo principal ejecuta Event Loop
• RealmAcceptor gestiona conexiones entrantes
• Manejo de eventos y ping periódico a base de datos

Manejo de Señales y Apagado

Secuencia de Apagado

Worldserver:

• Señal procesada por WorldServerSignalHandler
• Llamada a World::StopNow()
• Hilo de mundo detiene bucle de juego y limpia
• Master espera cierre de hilos
• Cierre de bases de datos
• Salida con código de estado

Authserver:

• Señal activa stopEvent = true
• Event Loop finaliza
• Cierre de base de datos
• Proceso finaliza normalmente

Configuración y Sistema de Banner

Ambos servidores usan olympus::Banner para mostrar:

• ASCII Art de OlympusCore
• Nombre y versión de la aplicación
• Ruta de configuración
• Versiones de dependencias (OpenSSL, ACE, Boost)

Características Específicas de Plataforma

Soporte de Servicio en Windows

• Service Name: worldserver
• Display Name: TrinityCore world service
• Description: Emulador TrinityCore de World of Warcraft (world service)

Afinidad y Prioridad de Procesos

World System y Configuración

Archivos fuente relevantes: Esta sección explica el sistema singleton World, que actúa como coordinador central de operaciones del servidor, gestión de configuración, manejo de sesiones y temporización del bucle de juego. La clase World administra el estado principal del servidor, sesiones de jugadores y comportamientos definidos por configuración.

Arquitectura Singleton World

La clase World implementa un patrón singleton y sirve como punto central de coordinación para todas las operaciones del servidor:

• Estado global: manejo del estado del servidor, incluyendo número de jugadores, estado de apagado y flags operativos
• Gestión de sesiones: administra todas las sesiones activas y colas de espera
• Integración de configuración: carga y proporciona acceso a todas las configuraciones del servidor
• Orquestación de temporizadores: coordina intervalos de actualización de mapas, clima, eventos y sistemas periódicos
• Gestión de rates: aplica multiplicadores configurables de experiencia, drops, reputación y otras mecánicas de juego

Gestión de Configuración

El sistema World implementa un marco completo de configuración que carga ajustes desde worldserver.conf y los hace disponibles globalmente:

Estructura del Archivo de Configuración

• CONNECTIONS AND DIRECTORIES: RealmID, DataDir, conexiones a base de datos
• PERFORMANCE SETTINGS: UseProcessors, Compression, PlayerLimit
• SERVER LOGGING: PidFile, PacketLogFile, ChatLogs
• SERVER SETTINGS: GameType, RealmZone, MaxPlayerLevel
• WARDEN SETTINGS: Warden.Enabled, Warden.NumMemChecks
• PLAYER INTERACTION: AllowTwoSide.*, TalentsInspecting
• CREATURE SETTINGS: ThreatRadius, Rate.Creature.*
• CHAT SETTINGS: ChatFlood.*, Channel.RestrictedLfg

Carga y Validación de Configuración

El método World::LoadConfigSettings() realiza validaciones extensas, incluyendo rango de valores, dependencias y logging de errores, aplicando valores por defecto en caso de configuración inválida.

Categorías Principales de Configuración

Gestión de Sesiones

El sistema World gestiona todas las conexiones de jugadores mediante un marco que controla ciclo de vida de sesiones, límites de capacidad, colas y tolerancia a desconexiones recientes.

Flujo de Procesamiento de Sesiones

• Reciente desconexión → bypass de cola
• Verificación de límite de jugadores
• Cola de espera para exceso de jugadores
• Activación de sesión

Estadísticas de Sesiones

• Sesiones activas: GetActiveSessionCount()
• Sesiones en cola: GetQueuedSessionCount()
• Pico histórico activo: m_maxActiveSessionCount
• Pico histórico en cola: m_maxQueuedSessionCount
• Total de sesiones: GetActiveAndQueuedSessionCount()

Bucle de Juego y Sistema de Temporización

El sistema World coordina temporizadores para todos los subsistemas mediante IntervalTimer y WorldTimers, gestionando actualizaciones de mapas, eventos periódicos y mantenimiento.

Temporizadores Críticos de Rendimiento

• Map Updates: MapUpdateInterval (default 100ms)
• Grid Cleanup: GridCleanUpDelay (default 5 min)
• Weather Changes: ChangeWeatherInterval (10 min)
• Player Saves: PlayerSaveInterval (15 min)
• Database Ping: MaxPingTime (30 min)

Características Configurables de Juego

El sistema permite funcionalidades configurables:

• Boost de Experiencia: Multiplicadores según día y hora (XP.Boost.Daymask, RATE_XP_BOOST)
• Bono PvP: Bonus de experiencia por kills PvP (RATE_BONUS_XP_PVP_VALUE)
• Bono de Mazmorras: Bonus de experiencia por completar dungeons (RATE_BONUS_XP_DUNGEON_VALUE)
• Títulos opcionales: Remoción de requisitos de logros (CONFIG_BONUS_TITLE_REQUIREMENT)

Database Layer y Gestión de Objetos

Archivos fuente relevantes: Esta sección cubre la capa de integración de base de datos y el sistema de gestión de objetos en OlympusCore, proporcionando almacenamiento persistente para entidades del juego, gestión de plantillas y manejo del ciclo de vida de los objetos.

Propósito y Arquitectura del Sistema

La capa de base de datos es la base para todos los datos persistentes del juego, ofreciendo caching, gestión de plantillas y asignación de GUID para entidades del juego. Está construida sobre tres bases de datos principales:

• WorldDatabase: datos estáticos del juego
• CharacterDatabase: datos de jugadores
• LoginDatabase: autenticación

ObjectMgr - Funcionalidad Principal

La clase ObjectMgr es el hub central para la gestión de datos estáticos del juego, proporcionando métodos de acceso, caching y soporte de localización.

• Almacenes de plantillas: CreatureTemplate, CreatureAddon, EquipmentInfo, CreatureModelInfo
• Contadores GUID: _hiCreatureGuid, _hiItemGuid, _hiCharGuid, etc.
• Métodos de carga: LoadCreatureTemplates(), LoadCreatureAddons(), LoadEquipmentTemplates()
• Arreglos de información de jugadores: _playerInfo[race][class]

Carga y Validación de Plantillas

El ObjectMgr carga plantillas de datos estáticos durante el inicio del servidor con validación exhaustiva:

• CreatureTemplate: creature_template → _creatureTemplateStore
• CreatureAddon: creature_template_addon → _creatureTemplateAddonStore
• EquipmentInfo: creature_equip_template → _equipmentInfoStore
• CreatureModelInfo: creature_model_info → _creatureModelStore

Gestión de GUIDs

Se mantienen contadores únicos para todas las entidades del juego, asegurando que no haya conflictos durante la creación de objetos:

• _hiCharGuid, _hiCreatureGuid, _hiItemGuid, _hiGoGuid, _hiPetGuid, _hiVehicleGuid, _hiDoGuid, _hiCorpseGuid, _hiMoTransGuid
• Métodos: GenerateNewGuid(), MAKE_NEW_GUID()

Capa de Abstracción de Base de Datos

Se utilizan Prepared Statements para operaciones seguras y eficientes, manteniendo separación entre datos de mundo y de personajes.

• WorldDatabaseConnection: DoPrepareStatements() para datos de mundo
• CharacterDatabaseConnection: DoPrepareStatements() para datos de personajes
• Tipos de operaciones: Template Loading, Entity Management, Player Data, Guild System, Achievement System

Soporte de Localización

El ObjectMgr soporta múltiples idiomas para el contenido textual visible por el jugador:

• Locales: enUS, deDE, frFR, etc. (hasta 8 idiomas)
• Almacenes: _creatureLocaleStore, _gossipMenuItemsLocaleStore, _pointOfInterestLocaleStore
• Métodos: AddLocaleString(), GetLocaleString()

Creación de Objetos y Resolución de Plantillas

El ObjectMgr proporciona métodos para crear objetos del juego desde plantillas, manejando selección de display, flags y randomización de modelos:

• Métodos principales: GetCreatureTemplate(entry), ChooseCreatureFlags(), ChooseDisplayId(), GetCreatureModelRandomGender()
• Flujo de creación: Creature::Create() → LoadFromDB() → LoadCreatureAddon()
• Soporte de herencia de plantillas y randomización de género en modelos alternativos

Build System y Dependencias

Archivos fuente relevantes: Esta sección cubre el sistema de compilación basado en CMake de OlympusCore, incluyendo la gestión de dependencias externas, compilación de objetivos y configuraciones específicas por plataforma.

Visión General del Sistema de Compilación

OlympusCore utiliza CMake como sistema principal de construcción (versión mínima requerida 3.8), organizado en múltiples bibliotecas y ejecutables que forman el servidor completo.

Estructura del Proyecto CMake

• CMakeLists.txt: Configuración raíz del proyecto OlympusCore
• cmake/options.cmake: Configuración de opciones de compilación
• cmake/genrev.cmake: Generación de información de revisión
• dep/CMakeLists.txt: Gestión de dependencias externas
• cmake/macros/FindMySQL.cmake: Detección de MySQL/MariaDB
• src/CMakeLists.txt: Raíz de código fuente
• src/server/authserver/CMakeLists.txt: Ejecutable authserver
• src/server/worldserver/CMakeLists.txt: Ejecutable worldserver
• src/server/game/CMakeLists.txt: Librería de lógica de juego
• src/server/scripts/CMakeLists.txt: Librería de scripts
• src/server/shared/CMakeLists.txt: Librería compartida
• src/server/collision/CMakeLists.txt: Librería de colisiones

Dependencias Externas

El sistema de compilación gestiona varias dependencias críticas:

Detección de MySQL/MariaDB

Soporta tanto MySQL como MariaDB en diferentes plataformas:

• Windows: busca MariaDB 10.5-10.9 en rutas estándar de Program Files
• Unix: usa mysql_config si está disponible, o rutas estándar del sistema

Configuración y Opciones de Compilación

• Tipo de compilación por defecto: Release
• Protección contra cambios de código fuente y compilación in-source
• Control de precompiled headers (USE_COREPCH, USE_SCRIPTPCH)

Generación de Información de Revisión

Se genera automáticamente un header revision_data.h con metadatos del build:

• _REVISION, _HASH, _DATE, _BRANCH
• VER_COMPANYNAME_STR y VER_LEGALCOPYRIGHT_STR

Objetivos Principales y Librerías

• Librerías: shared, game, collision, scripts
• Ejecutables: authserver, worldserver

Compilación de Scripts

Macro dinámica que recopila fuentes de múltiples directorios:

macro(PrepareScripts name out)
  file(GLOB_RECURSE found ${name}/*.h ${name}/*.cpp)
  list(APPEND ${out} ${found})
endmacro()

Rutas de Inclusión

• authserver: Authentication/, Realms/, Server/
• game: Entities/, Spells/, AI/, Handlers/
• scripts: Todas las includes de juego + scripts
• collision: Management/, Maps/, Models/

Configuraciones por Plataforma

El build system maneja diferencias entre Windows y Unix mediante compilación condicional:

• Windows: incluye archivos de recursos, copia post-build de authserver.conf.dist
• Unix: enlaza con librerías externas (MySQL, OpenSSL, ACE, Boost) y define rutas de configuración

Control de Compilación de Dependencias

• Dependencias comunes: ACE, Boost, MySQL/MariaDB
• Linux: readline, zlib, bzip2, threads
• Windows: dependencias integradas
• Opcionales según configuración: jemalloc, g3dlite, recastnavigation, gsoap, StormLib, json, etc.

Core Game Entity System

Archivos fuente relevantes: Esta sección describe la jerarquía de entidades y los sistemas de gestión que sustentan todos los objetos de juego en OlympusCore, incluyendo Object, WorldObject, el sistema de tipos, gestión de ciclo de vida, sincronización de valores y gestión espacial en grids.

Jerarquía de Tipos de Entidad

El sistema de entidades se construye con una estructura de clases jerárquica, donde Object es la clase base de todas las entidades.

• Object: GetGUID(), GetTypeId(), isType(), AddToWorld(), RemoveFromWorld(), Set/GetUInt32Value()
• WorldObject: GetPosition(), Relocate(), GetPhaseMask(), GetMap(), SetPhaseMask()
• Unit: Set/GetHealth(), isAlive(), CastSpell(), GetAI()
• GameObject: GetGoType(), SetGoState(), UseDoorOrButton()
• Player: GetSession(), GetGroup(), TeleportTo()
• Creature: AI(), SetReactState(), isWorldBoss()
• DynamicObject: GetCaster(), GetSpellInfo()

Sistema de Identificación de Tipos

El método isType() utiliza operaciones bitwise para comprobación eficiente en tiempo de ejecución.

Ciclo de Vida de Objetos y Gestión

• Creación: _InitValues() y _Create()
• Entrada en Mundo: AddToWorld() y registro en sistema de grids
• Estado Activo: Participa en actualizaciones e interacciones
• Salida de Mundo: RemoveFromWorld() y limpieza de referencias
• Destrucción: Limpieza de arrays y referencias

Sistema de Valores y Actualizaciones

El sistema de valores sincroniza datos entre servidor y cliente, con detección de cambios y transmisión eficiente:

• Array de Valores: m_uint32Values[]
• UpdateMask: Rastrea campos modificados
• Métodos: Get/Set UInt32, Float, UInt64; ApplyModUInt32Value(); Set/RemoveFlag()
• Bloques de Actualización: _BuildValuesUpdate(), WorldPacket

Sistemas Espaciales y Gestión de Grids

• Particionamiento del mundo en grids y celdas
• Mapas, coordenadas y referencias de grid
• Notificadores:
  • VisibleNotifier: cambios de visibilidad
  • GridUpdater: actualizaciones por tiempo
  • RelocationNotifier: movimiento entre grids
  • MessageDistDeliverer: distribución de paquetes según proximidad

Identificación de Entidades y GUIDs

• GUIDs globalmente únicos
• Formato PackGUID para transmisión de red
• GuidHigh2TypeId() convierte GUIDs a TypeID sin acceder al objeto

Posición e Integración de Movimiento

• Sistema de coordenadas 3D con orientación
• Asociación a mapas específicos
• Gestión de fases para visibilidad por jugador
• Soporte de relocación y consultas espaciales

Object Hierarchy

Archivos fuente relevantes: Esta sección cubre la jerarquía de objetos que representa todas las entidades del juego, desde la clase base Object hasta WorldObject, incluyendo sincronización de campos, gestión de GUID, actualizaciones para clientes e integración en grids.

Arquitectura de la Clase Base Object

La clase Object proporciona servicios esenciales como identificación única, almacenamiento de datos basado en campos y sincronización con clientes.

Sistema de Identificación de Objetos

Cada objeto tiene un GUID de 64 bits compuesto por:

• GUID Low (32-bit): Identificador de instancia
• GUID Mid (16-bit): Entry ID
• GUID High (16-bit): Type Identifier

Tipos de entidad principales:

• TYPEID_ITEM
• TYPEID_UNIT
• TYPEID_PLAYER
• TYPEID_GAMEOBJECT
• TYPEID_DYNAMICOBJECT
• TYPEID_CORPSE
• TYPEID_AREATRIGGER

Arquitectura del Sistema de Campos

Los objetos usan un sistema de campos dinámico para almacenar y sincronizar datos con los clientes:

• m_uint32Values[]: array de campos
• _changesMask: UpdateMask de cambios
• m_valuesCount: cantidad de campos
• Acceso tipo seguro: m_int32Values, m_uint32Values, m_floatValues
• Métodos: Get/Set UInt32, Float

Extensiones Espaciales de WorldObject

WorldObject extiende Object con funcionalidad espacial, integración con mapas y visibilidad:

• Posición: m_positionX, Y, Z, orientación
• Métodos de movimiento: Relocate(), MovePosition()
• Mapas: m_currMap, m_InstanceId, m_phaseMask
• Visibilidad: m_stealth, m_invisibility y arrays de detección

Gestión de Fases y Visibilidad

Soporte para sigilo, invisibilidad y visibilidad basada en fases:

• canSeeOrDetect(), CanNeverSee()
• InSamePhase()?, CanAlwaysSee()
• Detección de sigilo y invisibilidad: m_stealth vs m_stealthDetect, m_invisibility vs m_invisibilityDetect

Sistema de Actualización y Sincronización con Clientes

Los objetos sincronizan su estado con los clientes mediante un sistema eficiente de actualización:

• Bloques de actualización: BuildUpdate(), BuildCreateUpdateBlockForPlayer()
• Determinación de tipo de actualización: UPDATETYPE_CREATE_OBJECT, UPDATETYPE_CREATE_OBJECT2
• Manejo de UpdateMask: _SetUpdateBits(), _SetCreateBits(), _BuildValuesUpdate()
• Serialización: ByteBuffer

Visibilidad y Seguridad de Campos

• Flags base: UF_FLAG_PUBLIC, UF_FLAG_PRIVATE
• Flags por tipo: Items, Units/Players, GameObjects
• Relaciones: UF_FLAG_OWNER, UF_FLAG_PARTY_MEMBER, UF_FLAG_SPECIAL_INFO

Integración con Grids y Consultas Espaciales

• Referencias: GridObject, GridReference, GridRefManager, MapObject
• Celdas y posición: Cell _currentCell, _moveState, _newPosition
• Métodos de búsqueda espacial: VisitNearbyObject(), VisitNearbyGridObject(), VisitNearbyWorldObject()
• Encuentros cercanos: FindNearestCreature(), FindNearestGameObject(), FindNearestPlayer()

Gestión del Ciclo de Vida de Objetos

• Creación: Object(), _InitValues(), _Create(), SetUInt64Value(OBJECT_FIELD_GUID), SetUInt16Value(OBJECT_FIELD_TYPE), AddToWorld()
• Integración en mundo: m_inWorld = true, ClearUpdateMask()
• Salida de mundo: RemoveFromWorld(), m_inWorld = false, ClearUpdateMask()
• Destrucción y limpieza: ~Object(), sObjectAccessor->RemoveUpdateObject(), delete[] m_uint32Values, ~WorldObject(), ResetMap()

Unit System and Combat

Archivos fuente relevantes: Esta sección cubre el sistema Unit, base de todas las entidades de combate en OlympusCore. La clase Unit sirve como base para jugadores y criaturas, proporcionando mecánicas de combate, movimiento, lanzamiento de hechizos y gestión de estados.

Arquitectura Core de Unit

La clase Unit es abstracta y gestiona:

• Movimientos y pathfinding: MotionMaster
• Gestión de amenazas y aggro: ThreatManager
• Hechizos y efectos: Spell System
• Efectos persistentes: Aura System
• Control de comportamiento: AI System
• Control de mascotas/minions: CharmInfo

Jerarquía de clases principales:

• WorldObject > Unit > Player/Creature
• TempSummon, Pet, Totem, Guardian

Mecánicas de Combate y Sistema de Daño

• Tipos de daño: DIRECT_DAMAGE, SPELL_DIRECT_DAMAGE, DOT, NODAMAGE
• Fases de combate: Validación de ataque, Cálculo de daño, Mitigación (armor/resist/absorb), Aplicación final de daño
• Sistema de Procs: Eventos que disparan efectos
• Gestión de amenaza: ThreatManager y cálculo de victim
• Sistema de ataque: BASE_ATTACK, OFF_ATTACK, RANGED_ATTACK
• Alcance de combate: GetCombatReach(), IsWithinMeleeRange(), GetLeewayBonusRange()

Estados de Unidad y Movimiento

• Flags de estado: UNIT_STATE_*
• Estados de muerte: ALIVE, CORPSE, DEAD
• Estados de combate: In/Out of Combat
• Movimiento: UNIT_STATE_MOVING, ROAMING, CHASE, FLEEING, ROOT, STUNNED, CONFUSED, POSSESSED, CASTING
• Movimiento spline: MoveSpline(), UpdateSplineMovement(), UpdateSplinePosition()
• Gestión de velocidad: baseMoveSpeed[], m_speed_rate[], UpdateSpeed()

Integración de Hechizos

• Sistema de interrupción y validación: CanCast(), SPELL_STATE_PREPARING, SPELL_STATE_CASTING
• Estados de hechizos activos: CURRENT_GENERIC_SPELL, CURRENT_CHANNELED_SPELL, CURRENT_AUTOREPEAT_SPELL
• Impacto de movimiento, daño, stun/silence y muerte sobre hechizos
• Sistema de cooldown global: GlobalCooldownMgr, HasGlobalCooldown(), AddGlobalCooldown()

Integración con AI y Comportamiento

• Unidad integrada con AI: UnitAI, CreatureAI
• Eventos AI: UpdateAI(), SelectVictim(), EnterCombat(), JustDied(), SpellHit()
• Gestión de amenaza y target: ThreatManager, AddThreat(), getVictim()
• Habilidades reactivas: m_reactiveTimer[], UpdateReactives()
• Control de mascotas: CharmInfo, GetCharmInfo(), Pet AI

Ciclo de Actualización y Rendimiento

• Ciclo Unit::Update(p_time) optimizado para cientos de unidades
• Actualización condicional: eventos, hechizos activos, cooldowns, threat, timers, reactivas, auras, movimiento, MotionMaster, guardian speed, orientación
• Consideraciones de rendimiento: frecuencia variable por tipo de unidad, actualizaciones time-sliced, optimización para raids grandes
• Validación de estado: ASSERT(!m_procDeep), validación de timers y consistencia de hechizos

Player and Group Management

Archivos fuente relevantes: Esta sección cubre el sistema de entidades Player y la coordinación de grupos en OlympusCore. Incluye arquitectura de la clase Player, formación de grupos, interacción social y coordinación multijugador.

Arquitectura de la Entidad Player

La clase Player representa personajes controlados por humanos y extiende Unit con funcionalidades específicas:

• Seguimiento de logros: AchievementMgr
• Reputación de facciones: ReputationMgr
• Sistema de arqueología: ArcheologyMgr
• Gestión de talentos: PlayerTalentInfo
• Gestión de fases: PhaseMgr
• Sistema social: PlayerSocial
• Intercambios de items: TradeData
• Gestión de grupos y gremios: Group y Guild

Componentes Core del Player

• m_achievementMgr: seguimiento y recompensas de logros
• m_reputationMgr: gestión de reputación
• m_social: amigos y lista de ignorados
• _talentMgr: asignación de puntos de talento
• phaseMgr: sistema de phasing para instancias

Creación e Inicialización del Player

1. ObjectMgr y CharacterDatabase preparan la información del jugador
2. Se inicializan valores base: raza, clase, género
3. InitDisplayIds() establece la apariencia
4. Se guarda la información del personaje en la base de datos

Arquitectura del Sistema de Grupos

• Tipos de grupo: PARTY (5), RAID (40), BG, LFG
• Gestión de miembros: MemberSlotList y GroupRefManager
• Invitaciones pendientes: InvitesList
• Bind de instancias: BoundInstancesMap
• Métodos de loot: LootMethod y Roll

Gestión de Miembros de Grupo

• Agregar miembro: AddMember(Player*)
• Eliminar miembro: RemoveMember(uint64, RemoveMethod)
• Cambiar líder: ChangeLeader(uint64)
• Asignar roles LFG: SetLfgRoles(uint64, uint8)

Sistema Social

• Gestión de amigos y lista de ignorados a través de PlayerSocial
• Operaciones asincrónicas con base de datos

Sistema de Intercambio

• Clase TradeData gestiona items y oro
• Componentes: m_player, m_trader, m_items[7], m_money, m_spell, m_accepted

Sistemas de Recompensas y Progresión

• Clase KillRewarder gestiona XP, honor y reputación
• Factores considerados: tamaño y nivel del grupo, nivel del jugador, tipo de instancia, membresía de guild

Gestión de Instancias y Dificultad

• Bind de grupo a instancias: InstanceGroupBind
• Herencia automática de bind si el líder posee bind permanente
• Escalado de dificultad: Dungeons (Normal/Heroic), Raids (10/25 Normal/Heroic)

Sistema de Loot y Rolls

• Distribución de items mediante sistema de roll
• Tipos de roll: PASS, NEED, GREED, DISENCHANT
• Ciclo de roll: crear objeto, enviar SMSG_LOOT_START_ROLL, recolectar votos, asignar item

Integración de Bots

• Sistema NPC bot que se integra con player y group
• Componentes: BotHelper, NpcBotMap[MAX_NPCBOTS]
• Configuración: maxNpcBots, follow distance, reducción XP
• Efectos: XP distribuido reducido, loot FFA, limitaciones de instancias según configuración

Game Mechanics

Archivos fuente relevantes: Esta sección cubre los sistemas principales de mecánicas de juego en OlympusCore, enfocándose en hechizos, selección de objetivos y ejecución de efectos.

Spell System Overview

El sistema de hechizos proporciona un marco unificado para manejar habilidades de jugadores, hechizos de NPC, efectos de objetos y interacciones ambientales.

Core Spell Architecture

• Data Management
• Spell Execution Pipeline
• Core Spell Classes: Spell, SpellInfo, SpellCastTargets, SpellValue
• Client Request Processing: CMSG_CAST_SPELL, CMSG_USE_ITEM
• SpellMgr: gestor global de hechizos y efectos

Spell Data Management

• SpellEntry (DBC) → SpellInfo
• SpellEffectEntry → SpellEffectInfo
• SpellScalingEntry → SpellMgr
• mSpellChains, mSpellTargetPositions, mSpellBonusMap, mSpellProcMap

Spell Casting Pipeline

1. Procesamiento de solicitud del cliente
2. Creación y preparación del spell: new Spell(), prepare()
3. Selección de objetivos: SelectSpellTargets()
4. Validación: CheckCast()
5. Ejecución: cast(), manejo de efectos

Target Selection System

Soporta objetivos explícitos (seleccionados por el jugador) e implícitos (determinados por los efectos del hechizo).

• Explicit: SelectExplicitTargets()
• Implicit: SelectEffectImplicitTargets()
• Tipos de objetivo: UNIT, GAMEOBJECT, ITEM, DEST_LOCATION, AREA, CONE, NEARBY, CHANNEL

Spell Effect System

Los efectos son las unidades fundamentales de funcionalidad de hechizos, desde daño y curación hasta invocaciones.

• Effect Handler: SpellEffects[TOTAL_SPELL_EFFECTS]
• Acceso a SpellEffectInfo: puntos base, valores misceláneos, info de objetivos

Common Effect Types

Spell Targeting Mechanics

• Tipos de referencia: SpellImplicitTargetInfo → categoría de selección, tipo de objeto, referencia, chequeo de amistad/enemigo
• Tipos de objeto: UNIT, GOBJ, ITEM, DEST
• Categorías de selección: AREA, CONE, NEARBY, DEFAULT

Target Flag System

• Unit Flags: TARGET_FLAG_UNIT, TARGET_FLAG_UNIT_ENEMY, TARGET_FLAG_UNIT_ALLY, TARGET_FLAG_UNIT_PARTY, TARGET_FLAG_UNIT_RAID
• Location Flags: TARGET_FLAG_SOURCE_LOCATION, TARGET_FLAG_DEST_LOCATION
• Object Flags: TARGET_FLAG_GAMEOBJECT, TARGET_FLAG_ITEM
• Special Flags: TARGET_FLAG_CORPSE_ALLY

Aura System Integration

El sistema de hechizos se integra con el sistema de auras para efectos persistentes:

• Aplicación: EffectApplyAura()
• Tipos de aura: SPELL_AURA_MOD_STAT, SPELL_AURA_PERIODIC_DAMAGE, SPELL_AURA_MOD_RESISTANCE, SPELL_AURA_MOD_INCREASE_SPEED
• Reglas de apilamiento y duración gestionadas por SpellMgr

Skill System Integration

Soporte para mecánicas basadas en habilidades, como arqueología:

• Hechizos de arqueología usan castFlags especiales (0x8)
• Procesamiento de fragmentos y keystones
• Validación de proyecto de investigación
• Creación de artefactos

Spell System

Archivos fuente relevantes: Este sistema es el marco principal de habilidades mágicas en OlympusCore, encargado de manejar la preparación, selección de objetivos, ejecución de efectos y gestión de datos de los hechizos.

Purpose and Scope

Procesa solicitudes de hechizos del cliente, valida condiciones, ejecuta efectos y administra auras persistentes.

Core Architecture

• Effect Execution
• Casting Engine
• Spell Management
• Network Layer
• SpellHandler: HandleCastSpellOpcode(), HandleUseItemOpcode(), HandleCancelCastOpcode()
• SpellMgr (Singleton): SpellInfo, Spell Chains & Ranks, DBC Data Loading
• Spell (Active Instance): SpellValue, SpellCastTargets, prepare(), cast()
• SpellEffects Array, SpellEffectInfo
• Target Selection: Unit System, Player System, WorldObject, Aura System

Class Relationships

• SpellMgr: mSpellInfoMap, mSpellChains, GetSpellInfo(spellId), IsSpellValid(), LoadSpellRanks()
• SpellInfo: Id, Effects[MAX_SPELL_EFFECTS], GetExplicitTargetMask(), IsPositive(), CheckExplicitTarget()
• Spell: m_caster, m_targets, m_spellValue, prepare(targets), cast(), SelectSpellTargets()
• SpellCastTargets: m_objectTarget, m_src, m_dst, Read(data, caster), SetUnitTarget()
• SpellEffectInfo: Effect, ApplyAuraName, TargetA/B, CalcValue(), CalcRadius()

Spell Casting Lifecycle

1. Client Request → SpellHandler → SpellMgr → Spell → EffectHandler
2. Preparación: prepare(), validación con CheckCast()
3. Selección de objetivos: SelectSpellTargets(), SelectExplicitTargets()
4. Ejecución: cast(), ExecuteEffects()
5. Feedback al cliente: SMSG_SPELL_GO, SMSG_CAST_FAILED, SMSG_SPELL_FAILURE

Spell State Management

Targeting System

• Componentes: SpellImplicitTargetInfo, SpellCastTargets, SpellDestination
• Métodos: InitExplicitTargets(), SelectExplicitTargets(), SelectEffectImplicitTargets()
• Tipos de objetivos: Unit, Area, Destination, GameObject, Channel

Target Types and Flags

• Special Targets: TARGET_FLAG_CORPSE_ALLY, TARGET_FLAG_CORPSE_ENEMY, TARGET_FLAG_STRING
• Object Targets: TARGET_FLAG_GAMEOBJECT, TARGET_FLAG_GAMEOBJECT_ITEM, TARGET_FLAG_ITEM, TARGET_FLAG_TRADE_ITEM
• Location Targets: TARGET_FLAG_SOURCE_LOCATION, TARGET_FLAG_DEST_LOCATION
• Unit Targets: TARGET_FLAG_UNIT_ALLY, TARGET_FLAG_UNIT_ENEMY, TARGET_FLAG_UNIT_PARTY, TARGET_FLAG_UNIT_RAID

Effect System

Los efectos se ejecutan mediante un array de punteros a funciones, mapeando tipos de efecto a handlers:

• Damage: EffectSchoolDMG
• Healing: EffectHeal
• Aura: EffectApplyAura
• Summon: EffectSummonType
• Teleport: EffectTeleportUnits
• Dummy: EffectDummy
• InstaKill: EffectInstaKill
• Create Item: EffectCreateItem

Data Management

SpellMgr gestiona carga, validación y acceso a datos de hechizos:

• Mapas: mSpellInfoMap, mSpellChains, mSpellReq, mSpellTargetPositions, mSpellBonusMap, mSpellThreatMap, mSpellLinkedMap, mSpellProcEventMap
• Métodos: LoadSpellInfoStore(), LoadSpellRanks(), LoadSpellRequired(), IsSpellValid(), GetSpellInfo(), GetSpellChainNode(), GetSpellBonusData(), GetSpellProcEvent()

Network Integration

• Handlers: HandleCastSpellOpcode(), HandleUseItemOpcode(), HandleCancelCastOpcode(), HandleCancelAuraOpcode()
• Client Packets: CMSG_CAST_SPELL, CMSG_USE_ITEM, CMSG_CANCEL_CAST, CMSG_CANCEL_AURA
• Server Responses: SMSG_SPELL_START, SMSG_SPELL_GO, SMSG_CAST_FAILED, SMSG_SPELL_FAILURE

Aura System

Archivos fuente relevantes: Este sistema gestiona los efectos mágicos persistentes aplicados a unidades, incluyendo buffs, debuffs, daño periódico y modificaciones temporales a propiedades de la unidad.

Core Architecture

• Aura: Contenedor de efecto persistente (m_duration, m_procCharges, m_stackAmount)
• AuraApplication: Instancia aplicada a un objetivo específico (slot, sincronización con cliente)
• AuraEffect: Modificaciones individuales a propiedades de unidad (m_effects array)
• Unit: Entidad objetivo
• SpellInfo: Definición de efecto
• WorldObject: Propietario espacial
• SpellMgr: Gestión de datos
• ObjectMgr: Gestión de entidades
• ScriptMgr: Handlers personalizados

Aura Lifecycle Management

1. Creation: Aura::TryCreate(), BuildEffectMaskForOwner()
2. Application: Aura::Create(), _InitEffects(), _ApplyForTarget(), AuraApplication constructor
3. Update: UpdateOwner(), UpdateTargetMap()
4. Stack & Charge: ModStackAmount(), ModCharges()
5. Removal: Remove(), _UnapplyForTarget(), _HandleEffect(false), _DeleteRemovedApplications()

Client Synchronization

• Visible Aura Slots: SetVisibleAura(), GetVisibleAura()
• Update Packets: BuildUpdatePacket(), ClientUpdate()
• Aura Flags: _InitFlags(), AFLAG_* constants
• Stack/Charge Display: cantidad de stacks, cargas y duración

Stacking and Charge Mechanics

• Gestión de stacks: ModStackAmount(), SetStackAmount(), recalcula efectos con ChangeAmount() y CalculateAmount()
• Sistema de cargas: ModCharges(), IsUsingCharges(), eliminación automática cuando las cargas llegan a cero
• Proc Events: disparos en combate o lanzamiento de hechizo

Integration with Other Systems

• World System Integration
• Unit System Integration
• Aura System Core
• Spell System Integration: Spell Casting, Spell Effects, Spell Modifiers
• Unit Properties, Combat Mechanics, Movement Control
• Area Effects, Zone Auras, Spell Linking

Persistence and State Management

• Save State: CanBeSaved(), exclusión de auras temporales o de vehículos
• Load State: SetLoadedState(), restauración de duración, cargas y stacks
• Recalculation: RecalculateAmountOfEffects()

Map and Spatial Systems

Archivos fuente relevantes: Este sistema gestiona la infraestructura espacial del mundo de juego, la posición de objetos y la visibilidad de jugadores.

Map Architecture Overview

• Map: Clase base que maneja áreas persistentes y funcionalidad espacial central
• InstanceMap: Maneja contenido instanciado como mazmorras y raids, con sistemas de reseteo
• BattlegroundMap: Especializada para instancias PvP
• MapInstanced: Gestiona múltiples instancias de la misma plantilla de mapa

Grid and Cell System

• Grids: 64x64 que cubren todo el mapa
• Cells: Cada grid contiene 8x8 celdas para colocar objetos con precisión
• Contenedores: WorldObjects (objetos activos) y GridObjects (objetos pasivos)
• Coordenadas: GridCoord y CellCoord para indexación espacial
• Constantes: MAX_NUMBER_OF_GRIDS = 64, MAX_NUMBER_OF_CELLS = 8, TOTAL_NUMBER_OF_CELLS_PER_MAP = 512

Map Loading and Data Management

• Archivos Map: Terreno base, altura, líquidos y áreas
• VMap: Colisiones visuales para line-of-sight y detección de colisión
• MMap: Navegación y pathfinding
• Validación de archivos mediante valores magic esperados
• Directorios: maps/, vmaps/, mmaps/

Object Management

• Ciclo de vida completo de objetos: AddToMap(), RemoveFromMap(), Relocate()
• Contenedores: WorldObjects (actualizaciones frecuentes), GridObjects (mínimas)
• Listas de movimiento para cambios de grid/celda
• Relocalización de criaturas y jugadores con CreatureRelocation() y PlayerRelocation()

Visibility and Update System

• Rango de visibilidad: GetVisibilityRange(), DEFAULT_VISIBILITY_DISTANCE
• Marcado de celdas alrededor de jugadores activos para actualizar objetos
• Patrón visitor: TypeContainerVisitor procesa objetos en celdas marcadas
• Actualización de objetos con Trinity::ObjectUpdater
• Notificaciones de relocación: ProcessRelocationNotifies()

Movement and Relocation

• Tipos de movimiento: misma celda (inmediato), celda/grid diferente (diferido)
• Listas de movimiento (MoveList) para cambios diferidos
• Actualización de visibilidad y grid automático para objetos activos
• Funciones clave: ComputeCellCoord(), EnsureGridLoadedForActiveObject(), AddCreatureToMoveList(), UpdateObjectVisibility()

Instance Management

• Tipos de instancias: mazmorra, raid, escenario
• Control de estado: InstanceMap, InstanceScript
• Mecánicas de reseteo: automáticas o manuales, INSTANCE_RESET_ALL, INSTANCE_RESET_GROUP_DISBAND
• Gestión de jugadores: elegibilidad, binding, máximo de jugadores, estados de jefes
• Lógica personalizada para encuentros y progresos de instancia

Scripting Framework

Archivos fuente relevantes: Este framework permite implementar lógica personalizada, NPCs, hechizos, eventos y comportamientos sin modificar el núcleo del motor del juego.

Script Loading Architecture

El sistema centralizado registra todos los scripts durante el arranque del servidor. Se carga de forma modular según categorías:

• AddScripts(), AddSC_SmartScripts(), AddSpellsScripts()
• AddCommandsScripts(), AddCustomScripts(), AddDarkmoonFairScripts()
• AddWorldScripts(), AddEasternKingdomsScripts(), AddKalimdorScripts()
• AddOutlandScripts(), AddNorthrendScripts(), AddMaelstromScripts()
• AddOutdoorPvPScripts(), AddEventsScripts(), AddNPCBotScripts()
• Integración con anticheat: sAnticheatMgr->StartScripts()

Script Type Hierarchy

• CreatureScript → ScriptedAI: NPCs, comportamiento e interacciones
• BossAI: IA de jefes
• SpellScriptLoader → SpellScript: Efectos de hechizos personalizados
• AuraScript: Efectos persistentes de hechizos
• PlayerScript: Eventos de jugador
• InstanceScript: Gestión de instancias
• GameObjectScript: Interacción con objetos del mundo

Script Registration Patterns

Todos los scripts siguen un patrón de registro consistente implementando métodos virtuales y registrándose mediante funciones loader dedicadas:

Example Registration Implementation

// DarkmoonFairScripts.cpp
void AddDarkmoonFairScripts()
{
    new npc_darkmoon_mallet();
    new npc_wack_a_gnoll_barrel();
    new spell_cognez_dummy();
    new spell_magic_wings();
    new darkmoon_fair_playerscript();
}

Event-Driven Script Execution

Los scripts se integran mediante callbacks y ciclos de actualización del juego:

• Interacciones de NPCs: OnGossipHello(), OnGossipSelect()
• Validación de quests y lanzamiento de hechizos: HasItemCount(), CastSpell(), HandleDummy()
• Integración con SpellSystem, Creature, WorldSession y Player

Zone-Specific Script Organization

• AddEasternKingdomsScripts() → zonas de Eastern Kingdoms (Stormwind, Ironforge, Undercity)
• AddKalimdorScripts() → zonas de Kalimdor (Orgrimmar, Thunder Bluff, Darnassus)
• AddNorthrendScripts() → zonas de Northrend (Icecrown Citadel, Ulduar)
• AddMaelstromScripts() → zonas de Cataclysm (Deepholm, The Stonecore)
• AddEventsScripts() → eventos de temporada

Custom Enhancement Integration

Soporta extensiones del servidor mediante scripts personalizados, como:

• AddCustomScripts(), AddLeoDevScripts()
• Características como boost de nivel, teletransportes y quests personalizadas