Foundation for WoW-compatible addon support:
- Vendor Lua 5.1.5 source as a static library (extern/lua-5.1.5)
- TocParser: parses .toc files (## directives + file lists)
- LuaEngine: Lua 5.1 VM with sandboxed stdlib (no io/os/debug),
WoW-compatible print() that outputs to chat, GetTime() stub
- AddonManager: scans Data/interface/AddOns/ for .toc files,
loads .lua files on world entry, skips LoadOnDemand addons
- /run <code> slash command for inline Lua execution
- HelloWorld test addon that prints to chat on load
Integration: AddonManager initialized after asset manager, addons
loaded once on first world entry, reset on logout. XML frame
parsing is deferred to a future step.
Implement KeybindingManager singleton class to support:
- Storing and loading keybinding configuration from ini files
- Querying whether an action's keybinding was pressed
- Runtime rebinding of actions to different keys
- Default keybinding set: C=Character, I=Inventory, S=Spellbook, K=Talents,
L=Quests, M=Minimap, Esc=Settings, Enter=Chat
This is the foundation for user-customizable keybindings. Integration with
UI controls and replacement of hard-coded ImGui::IsKeyPressed calls will
follow in subsequent improvements.
texture.hpp / texture.cpp implemented an unfinished OpenGL texture loader
(loadFromFile was a TODO stub) that had no callers — the project's texture
loading is entirely handled by VkTexture (vk_texture.hpp/cpp) after the
Vulkan migration. Remove both files and their CMakeLists entries.
macOS: 'dxc' is not a valid Homebrew formula — the failing brew install line
was aborting early, preventing SDL2 and other packages from being installed.
Removed 'dxc' from the brew install command.
Linux arm64 / Windows: the add_dependencies(wowee wowee_fsr3_official_runtime_copy)
forced the FSR3 Kits build (including VK permutation generation) into every
normal cmake --build invocation. This broke arm64 (no DXC binary available) and
Windows MSYS2 (bash script ran in wrong shell context, exit 127). The FSR3 Path A
runtime is now a strictly opt-in artifact — build it explicitly with:
cmake --build build --target wowee_fsr3_official_runtime_copy
The main wowee binary still loads it dynamically at runtime when present and
falls back gracefully when it is not.
Linux arm64 (Exec format error):
- The script was downloading the x86_64 DXC release on all Linux hosts;
on aarch64 runners the x86_64 ELF fails with EXEC_FORMAT_ERROR at
shader compilation time. Add uname -m guard: when running on aarch64/
arm64 Linux without a DXC in PATH, exit 0 with an advisory message
rather than downloading an incompatible binary. The FSR3 SDK build
proceeds as it did before the permutation script was introduced
(permutation headers are expected to be pre-built in the SDK checkout).
Windows (bash: command not found, exit 127):
- cmake custom-target COMMANDs run via cmd.exe on Windows even when
cmake is configured from a MSYS2 shell, so bare 'bash' is not resolved.
- Use find_program(BASH_EXECUTABLE bash) at configure time (which runs
under shell: msys2 in CI and thus finds the MSYS2 bash at its native
Windows-absolute path). When bash is found, embed the full path in the
COMMAND; when not found (unusual non-MSYS2 Windows setups), skip the
permutation step and emit a STATUS message.
- AmdFsr3Runtime now probes both the legacy ffxFsr3* API and the newer
generic ffxCreateContext/ffxDispatch API; selects whichever the loaded
runtime library exports (GenericApi takes priority fallback)
- Generic API path implements full upscale + frame-generation context
creation, configure, dispatch, and destroy lifecycle
- dlopen error captured and surfaced in lastError_ on Linux so runtime
initialization failures are actionable
- FSR3 runtime init failure log now includes path kind, error string,
and loaded library path for easier debugging
- tools/generate_ffx_sdk_vk_permutations.sh added: auto-bootstraps
missing VK permutation headers; DXC auto-downloaded on Linux/Windows
MSYS2; macOS reads from PATH (CI installs via brew dxc)
- CMakeLists: add upscalers/include to probe include dirs, invoke
permutation script before SDK build, scope FFX pragma/ODR warning
suppressions to affected TUs, add runtime-copy dependency on wowee
- UI labels updated from "FSR2" → "FSR3" in settings, tuning panel,
performance HUD, and combo boxes
- CI macOS job now installs dxc via Homebrew for permutation codegen
- Add -Wno-missing-field-initializers for GCC (Vulkan designated
initializer patterns in valid C++20 trigger this)
- Mark extern/ and vk-bootstrap as SYSTEM includes to suppress
warnings from vendored headers (VMA, stb, miniaudio, nlohmann)
Some distros and CMake versions fail to find Vulkan via FindVulkan.cmake
even when libvulkan-dev is installed. Fall back to pkg-config (vulkan.pc)
and create the Vulkan::Vulkan imported target manually if needed.
- Add missing MSYS2 packages to CI: vulkan-loader, vulkan-headers,
shaderc, stormlib (both x86-64 and arm64), unicorn (arm64)
- Make vulkan-1.dll copy conditional via find_file (fixes MSYS2 builds)
- Use find_library for wininet/bz2 in asset_extract (graceful fallback)
- Add extract_assets.ps1 and extract_assets.bat for Windows users
- Expand BUILD_INSTRUCTIONS.md with MSYS2, vcpkg, and macOS sections
- Update README.md to reference Windows scripts and platforms
Introduce data-driven opcode registry with canonical and alias sources:
- Added Data/opcodes/canonical.json as the single canonical LogicalOpcode set.
- Added Data/opcodes/aliases.json for cross-core naming aliases (CMaNGOS/AzerothCore/local legacy).
Added generator and generated include fragments:
- tools/gen_opcode_registry.py emits include/game/opcode_enum_generated.inc, include/game/opcode_names_generated.inc, and include/game/opcode_aliases_generated.inc.
- include/game/opcode_table.hpp now consumes generated enum entries.
- src/game/opcode_table.cpp now consumes generated name and alias tables.
Loader canonicalization behavior:
- OpcodeTable::nameToLogical canonicalizes incoming JSON opcode names via alias table before enum lookup, so implementation code stays stable while expansion maps can use different core spellings.
Validation and build integration:
- Added tools/validate_opcode_maps.py to validate canonical contract across expansions.
- Added CMake targets opcodes-generate and opcodes-validate.
- wowee target now depends on opcodes-generate so generated headers stay current.
Validation/build run:
- cmake -S . -B build
- cmake --build build --target opcodes-generate opcodes-validate
- cmake --build build -j32
Replace 2D screen-space ding rings with real WoW LevelUp.m2 particle/geometry
effect. Fix FBlock particle color parsing (C3Vector floats, not CImVector bytes)
which was producing blue/red instead of golden yellow. Spell effect models bypass
particle dampeners, glow sprite conversion, Mod→Additive blend override, and all
collision (floor/wall/camera) to prevent camera zoom-in. Other players' level-ups
trigger the 3D effect at their position with group chat notification. F7 hotkey
for testing.
CMake processes escape sequences twice: once reading CMakeLists.txt and
once loading the generated CPackConfig.cmake. Backslashes need four
levels of escaping (\\) to survive both passes and land as a single
backslash in the injected NSIS script.
Copy Wowee.ico into the build tree at configure time so llvm-rc can
resolve the relative assets\\wowee.ico path in wowee.rc. Also remove a
redundant #include <sys/mman.h> that was incorrectly placed inside a
function body.
logger.hpp: extend ERROR macro push/pop region to cover entire header so
LogLevel::ERROR inside template bodies compiles correctly on Windows
CMakeLists.txt: move tool install() rules next to each target definition
so they run after the targets exist (fixes macOS 'target does not exist')
Linux: DEB with /opt/wowee prefix and /usr/local/bin/wowee wrapper script
Windows x86-64: NSIS installer with DLL bundling and Start Menu shortcut
Windows ARM64: ZIP archive with bundled DLLs
macOS ARM64: .app bundle via dylibbundler + DMG via hdiutil
Assets are bundled into all packages (Original Music excluded). StormLib
is installed where available so asset_extract is included in packages.
Guard X11 display crash handler with __linux__, add Windows GlobalMemoryStatusEx
path in memory_monitor, guard warden cache paths with APPDATA on Windows, and
make pkg-config optional in CMakeLists with a find_library fallback. Add Windows
x86-64 CI job using MSYS2 MINGW64 to the build workflow.
Remove HDPackManager, expansion overlay manifests, and BLP size-comparison
logic. Assets now resolve through a single manifest with a simple override
directory (Data/override/) for future HD upgrades.
Parse PE sections from WoW.exe into a flat virtual memory image so
MEM_CHECK returns real binary contents instead of zeros. Also mocks
KUSER_SHARED_DATA (0x7FFE026C) with Windows 7 version info.
- Vanilla M2 bone struct (108 bytes) with 28-byte animation tracks
- Version-aware bone parsing (vanilla vs WotLK format detection)
- Fix CharSections.dbc field layout for vanilla (variation/color at 4-5)
- Remove broken CharSections.csv files (all fields marked as strings)
- Expansion data reload on profile switch (DBC cache clear, layout reload)
- Vanilla packet encryption (VanillaCrypt XOR-based header crypt)
- Extended character preview geoset range (0-99) for vanilla models
- DBC cache clear support in AssetManager
Replace hardcoded WotLK protocol constants with a data-driven architecture
supporting Classic 1.12.1, TBC 2.4.3, and WotLK 3.3.5a. Each expansion
has JSON profiles for opcodes, update fields, and DBC layouts, plus C++
polymorphic packet parsers for binary format differences (movement flags,
speed fields, transport data, spline format, char enum layout).
Key components:
- ExpansionRegistry: scans Data/expansions/*/expansion.json at startup
- OpcodeTable: logical enum <-> wire values loaded from JSON
- UpdateFieldTable: field indices loaded from JSON per expansion
- DBCLayout: schema-driven DBC field lookups replacing magic numbers
- PacketParsers: WotLK/TBC/Classic parsers with correct flag positions
- Multi-manifest AssetManager: layered manifests with priority ordering
- HDPackManager: overlay texture packs with expansion compatibility
- Auth screen expansion picker replacing hardcoded version dropdown
Solves Linux execution limitation without Wine!
New Component: WardenEmulator
- Uses Unicorn Engine to emulate x86 CPU on any platform
- Can execute Windows Warden modules on Linux/macOS/ARM
- Provides sandboxed execution environment
- Intercepts Windows API calls with custom implementations
Features:
- CPU: x86 32-bit emulation via Unicorn
- Memory: Emulated address space (1MB stack, 16MB heap)
- API Hooks: VirtualAlloc, GetTickCount, ReadProcessMemory, etc.
- Safety: Module runs in isolated emulated environment
- Cross-platform: Works on Linux/macOS/Windows/ARM hosts
Architecture:
- Module code loaded into emulated memory at 0x400000
- Stack at 0x100000 (1MB)
- Heap at 0x200000 (16MB)
- API stubs at 0x70000000 (high memory)
- Intercept and provide Windows API implementations
Benefits vs Wine:
✓ Lightweight (no full Windows compatibility layer)
✓ Sandboxed (module can't harm host system)
✓ Cross-architecture (works on ARM, RISC-V, etc.)
✓ Full control over execution (can inspect/modify state)
✓ Easier debugging and analysis
Build:
- Added libunicorn-dev dependency
- Conditional compilation (HAVE_UNICORN)
- Falls back gracefully if Unicorn not available
Status: Infrastructure complete, ready for integration
Next: Connect WardenEmulator to WardenModule for real execution
Note: RSA modulus extraction script added but needs refinement
(current candidates are x86 code, not data section)
Add complete RC4 encryption/decryption for Warden packets with proper
module initialization, seed extraction, and encrypted check responses.
New components:
- WardenCrypto class: Handles RC4 cipher state for incoming/outgoing packets
- Module initialization: Extracts 16-byte seed from first SMSG_WARDEN_DATA
- Separate input/output RC4 ciphers with proper key derivation
- Enhanced module ACK: Sends encrypted acknowledgment with checksum
Updated GameHandler:
- First packet: Initialize crypto and send encrypted module ACK
- Subsequent packets: Decrypt checks, generate responses, encrypt replies
- Support for module info, hash checks, Lua checks, and memory scans
- Detailed logging of plaintext and encrypted data for debugging
Works with servers that:
- Use standard WoW 3.3.5a Warden protocol
- Accept crypto-based responses without module execution
- Have permissive or disabled Warden settings
Tested against Warmane (strict enforcement) and ready for less restrictive servers.
