Run on stock Project Epoch: stock-client fix, configurable exe, nameplate distance, MSDF fonts - #3
Merged
thierbig merged 27 commits intoAug 11, 2026
Conversation
…le exe Covers three requested changes plus a README correction: - Configurable game exe via gameExeLocation.txt (default Wow.exe), read by both injector and patcher with built-in fallbacks. - Re-enable nameplateDistance on the base 3.3.5a client (address 0x00ADAA7C). - Selective upstream port from noname08662/awesome_wotlk, with MSDF fonts as a gated sub-phase that can graduate to its own spec. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Tasks: shared gameExeLocation.txt parser (TDD), patcher + injector config integration, re-enable nameplateDistance, README/packaging fixes, and the upstream gap-analysis that seeds the feature-port follow-up plans. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…efault Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Replace fictional AwesomeEpoch.exe auto-launcher description with the real flow (start client, then AwesomeWotlkInjector.exe or AwesomeWotlkPatch.exe) - Retarget README from Ascension.exe to the base WoW 3.3.5a client (Wow.exe), keeping Project-Epoch.exe/Ascension.exe as documented fallbacks - Remove the disabled nameplate distance note and the Nameplate Distance Limitation bullet (now enabled) - Add gameExeLocation.txt template at repo root and ship it in the release zip Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…overgeneralization in gap analysis Fix round 1 per reviewer feedback on 2026-08-07-upstream-gap-analysis.md: - Item 9 (Camera) cited a nonexistent address (0x004F90E2); replaced with the real 3 naked-hook addresses re-verified against upstream Camera.cpp. - Counts summary said 6/7/5 but the table has 6/6/6 (18 rows); fixed to match. - Softened 'Lua functions exposed via luaL_Reg tables' to account for modules that use bare lua_pushcfunction/lua_setglobal instead. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ng include - README: reorder Usage section so the Patching flow (AwesomeWotlkPatch.exe) is primary, matching what windows-release.yml actually ships in the release zip. Injection (AwesomeWotlkInjector.exe) is now a clearly labeled Alternative/Advanced option with a note that it's built separately by build-injector.yml and isn't in the main release zip. - README: remove stale references to AutoInject_Awesome.log and injector_output.log (Features, Troubleshooting, Notes) — no source file writes these files. - Main.cpp: add missing #include <cstring> for _strdup/strcmp/memcpy, currently only transitively included. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The "Project Epoch.exe"/"ascension.exe" fallbacks were stored near-plaintext then run through DecryptString (XOR 0x42), decoding to garbage so they never matched a running process. Replace with plain wide literals (like L"Wow.exe") and remove the now-unused DecryptString helper and the three ENCRYPTED_* constants (ENCRYPTED_DLL_NAME was already dead — the DLL name is hardcoded). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gluexml_postload() called Console::SetCVarValue(cvar, realmname, ...) guarded only by cvar, while the sibling realmList branch guards cvar && realmList. Launching without -realmname passed a NULL value pointer. Add the matching && realmname guard. (Dormant today — CommandLine::initialize() is commented out in Entry.cpp — but correct for when it is re-enabled.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
AwesomeWotlkPatch had its own CMakeLists.txt and Main.cpp but was never added in src/CMakeLists.txt, so it never built — yet windows-release.yml packages AwesomeWotlkPatch.exe (its Test-Path guard would throw) and the README leads with the patcher flow. Wire it into the build. Verified: builds cleanly on MSVC (VS2022, Win32) -> AwesomeWotlkPatch.exe. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…lib) Vendors upstream noname08662/awesome_wotlk's MSDF font pipeline into the fork: - deps/: freetype-2.14.1, msdfgen, unordered_dense (from source) and skia (prebuilt skia.lib + skia.dll), wired via deps/CMakeLists.txt. .gitignore gains an exception so the prebuilt skia binaries are tracked. - src/AwesomeWotlkLib/msdf/: the D3D9 + MSDF modules plus upstream's client headers (GameClient/Hooks/Types/Lua/Utils/Enums), compiled as a separate static library (AwesomeMSDF) with this dir on the include path. This isolates upstream's client-abstraction layer from the fork's own diverged headers of the same name so they never collide in one translation unit. - Bridge (MSDFBridge.h + MSDF::setMode): only primitive-typed entry points cross back into the fork. The fork owns the MSDFMode CVar (its own Hooks/CVar types) and forwards the value to the isolated lib, so AwesomeMSDF needs none of upstream's CVar machinery. Entry.cpp OnAttach calls D3D::initialize() in the detour transaction and registers MSDFMode. - The MSDF target raises the SDK level (_WIN32_WINNT=0x0A00) for VirtualAlloc2/ MapViewOfFile3 and restores /EHsc, without disturbing the Win7-targeted DLL. VERIFIED: all targets compile and link on MSVC (VS2022, Win32) -> a 1.29 MB AwesomeWotlkLib.dll with MSDF linked in; injector and patcher unaffected. NOT verified: runtime behaviour in-game (hardcoded client addresses, D3D-hook coexistence with the anti-detection layer) requires testing on the real client. Runtime dependency: skia.dll must ship alongside AwesomeWotlkLib.dll. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- AwesomeWotlkLib post-build copies deps/skia/skia.dll next to the built DLL, so build/Release (and the injector CI artifact, which globs *.dll) include it. - Patcher copies skia.dll into the game folder alongside AwesomeWotlkLib.dll. - windows-release.yml packages skia.dll in the release zip (with a Test-Path guard). Verified: DLL + patcher rebuild clean; skia.dll present in build/Release. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds chatLogSessionKey / combatLogSessionKey CVars (default on): each launch writes a timestamped Logs\<stamp> WoWChatLog.txt / WoWCombatLog.txt instead of overwriting the single default file. Self-contained pointer patches at 0x00AC7A40 / 0x00AC7A44 (fallback to client defaults when disabled), adapted to the fork's Console::CVar types. Registered from Entry.cpp's OnAttach (the fork's Misc::initialize() is disabled), so they register via the working CVar path. Verified: DLL compiles/links on MSVC. Runtime (hardcoded 3.3.5a addresses) needs in-game verification. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
windows-latest upgraded to Visual Studio 18, so the hardcoded
-G "Visual Studio 17 2022" generator fails at configure ("could not find any
instance of Visual Studio"). Switch to Ninja, which uses the MSVC x86
environment from msvc-dev-cmd and is generator-version-agnostic. The root
CMakeLists pins runtime output to build/Release via $<CONFIG>, so the uploaded
artifact paths are unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…c2 on NTDDI) CI (Windows SDK 10.0.26100) gates VirtualAlloc2 / MapViewOfFile3 behind NTDDI_VERSION >= NTDDI_WIN10_RS4 (0x0A000005), not just _WIN32_WINNT. The MSDF target set NTDDI_VERSION=0x0A000000 (base Win10), which built on the older local SDK (which gates on _WIN32_WINNT) but failed on CI with C3861. Bump to RS5 (0x0A000006). Reverts the /FI experiment (an in-source #define did not override the command-line _WIN32_WINNT reliably; the /U;/D compile options do). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds a small native launcher (src/AwesomeEpochLauncher -> AwesomeEpoch.exe) that replaces the old bat-to-exe launcher. It reuses the shared GameExeConfig helper to read gameExeLocation.txt (default Wow.exe), ensures the client is running, waits for it to initialize, then runs AwesomeWotlkInjector.exe against it, retrying and logging to AutoInject_Awesome.log. Uses GetModuleFileName for its own directory, so it works wherever the folder lives (unlike a bat-to-exe build, which extracts to temp and loses %~dp0). Warns if AwesomeWotlkLib.dll / skia.dll are missing beside the injector. CI (build-injector.yml) now builds it too, so the artifact includes AwesomeEpoch.exe. Verified: builds on MSVC (VS2022, Win32) -> AwesomeEpoch.exe. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… CVars)
Misc::initialize() was commented out in OnAttach ("not required for NamePlate
API"), leaving cameraFov / showPlayer / interactionAngle / interactionMode
unregistered and the interaction-button Lua API (QueueInteract keybind) inactive
- so the AwesomeEpochManager addon's interaction/camera controls did nothing.
Enable it. It only registers CVars/Lua/enter-world callbacks (its camera detour
stays disabled), so it is safe inside the existing attach transaction.
Verified: DLL builds on MSVC. Runtime behavior needs in-game testing.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
MSDFMode defaulted to on and D3D::initialize() attached the D3D9 device + font hooks eagerly at attach. On a client whose addresses differ from base 3.3.5a 12340 (e.g. Project Epoch build 12341) those hooks crash the client with ERROR #134 "Invalid function pointer" at the login screen. Register MSDFMode with default "0" and move D3D::initialize() into MSDF::setMode, guarded so the D3D9/font hooks attach only the first time MSDF is turned on. The whole font subsystem is now dormant unless explicitly enabled, so it cannot crash a client that never opts in; users on a compatible client set MSDFMode 1. Verified: DLL builds on MSVC. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…Epoch/base 12340) Our fork carried someweirdhuman PR #34's OLD-Epoch addresses for the FrameXML hook (site 0x005120e0, detoured as a function) and was missing the stock invalid-function-pointer bypass. On the current stock client (Project Epoch, base 3.3.5a layout) that detour trips the client's function-pointer integrity check -> ERROR #134 "Invalid function pointer" at the login screen, even with a minimal (NamePlates-only) build. Match upstream v37's stock approach: - Hook the CALL SITE 0x0051226D (not the function) with a naked stub that calls the real OpenFrameXMLApi (0x00530F60) then registers our custom Lua libs, so the function itself is never modified and the integrity check is not tripped. - Restore the bypass at attach: *(0x00D415B8)=1; *(0x00D415BC)=0x7FFFFFFF, plus TOS/EULA auto-accept. Also re-enables Misc::initialize (interaction button + cameraFov/showPlayer/ interaction CVars) now that the core loads. Verified in-game: the NamePlates-only build with this fix loads to login/world on the Project Epoch client with no crash. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
CVarHandler_NameplateDistance clamped the value to 100, so the AwesomeEpochManager slider's 200 was silently cut to 100. Raise the upper bound to 200 to match the addon UI. (Actual in-game range is still bounded by the client's unit-visibility range, but the DLL no longer caps it below the requested value.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Confirmed working in-game on the Project Epoch client. The handler fires after the attach detour transaction commits, at the same device state as a manual /console MSDFMode 1, so on-by-default takes the same path. Custom CVars don't persist across sessions, so defaulting to 1 keeps fonts on without re-typing it. Set MSDFMode 0 to disable. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
thierbig
changed the title
… set) windows-latest ships VS18, so the pinned "Visual Studio 17 2022" generator failed at configure (the build-windows-win32-release check). Mirror build-injector.yml: msvc-dev-cmd (x86) + Detours fix + Ninja configure with /DNOWINBASEINTERLOCK /D_WIN32_WINNT=0x0601. Build and package the injection set (AwesomeEpoch.exe launcher + injector + DLL + skia.dll + gameExeLocation template) as AwesomeEpoch.zip plus Addons.zip, matching the 3.0 release layout. Adds workflow_dispatch for manual validation. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
thierbig
deleted the
change-exe-and-sync-from-main-branch-nameplate-distance
branch
August 12, 2026 16:05
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Makes AwesomeEpoch run on the stock Project Epoch client (base 3.3.5a, build 12341) via injection, makes the game executable configurable, re-enables nameplate distance, and ports the MSDF vector-font pipeline from upstream
noname08662/awesome_wotlk. Everything builds on MSVC (VS2022, Win32) and is confirmed working in-game.The key fix — stock-client hooking (
2fe0665)The fork descended from the older someweirdhuman lineage and carried PR #34's old-Epoch addresses for the FrameXML hook, which crashed the current stock client with
ERROR #134 "Invalid function pointer"at login. Matched upstream v37's stock approach:0x0051226D(naked stub →call 0x00530F60→ register libs) instead of detouring the function, so the client's function-pointer integrity check isn't tripped.*(0x00D415B8)=1; *(0x00D415BC)=0x7FFFFFFF+ TOS/EULA auto-accept.What's included
gameExeLocation.txtparser read by the injector, patcher, and launcher; defaultWow.exe.AwesomeEpoch.exelauncher — reads the config, starts the client, injects; replaces the old bat-compiled launcher.0x00ADAA7C), clamp raised to 200 to match the addon slider.MSDFModeon by default (D3D/font hooks confirmed working on Epoch).Misc::initializere-enabled (interaction button,cameraFov,showPlayer,interactionAngle/Mode).CommandLine.cppnull-guard.nameplateOriginPosset to 0.build-injector.ymlswitched to Ninja (windows-latest ships VS18); MSDF SDK level raised to NTDDI RS5.Verified in-game (Project Epoch, build 12341)
Injects and reaches world with no crash; nameplates + API,
nameplateDistance, Misc, per-session logs, and MSDF vector fonts all working. Deployed via injection (the client's upstreamdinput8proxy must stay disabled to avoid a double-load).🤖 Generated with Claude Code