feat(dev-new): version the acore image build, add eight modules #375

Merged
dominik.polakovics merged 1 commit from afk/wow-modules into main 2026-08-21 00:13:03 +02:00

Adding a module to AzerothCore means recompiling the worldserver, so "which modules do we want" was blocked on a build that existed only as bin/build-images.sh on the portable SD card — the card ADR-0027 had already stopped treating as authoritative, and which is not currently attached to anything.

What landed

The build is versioned. build/build-images + build/pins shallow-fetch the core and all eleven modules at pinned revisions, apply the patches, and produce all three images. No card involved.

mod-xp-lock is vendored under modules/. It has no upstream — the card held the only copy, and dev-new's /var/lib/wow/modules copy was the last one in existence. It is rescued into the repo here.

Eight modules added: individual-progression, ah-bot-plus, junk-to-gold, reagent-bank, aoe-loot, challenge-modes, transmog, dungeon-clear.

Images built and pushed

Built on nb, pushed to the Forgejo registry, tag ceeb3116-mods1:

image digest
acore-worldserver sha256:94dbdf6c…7cace
acore-authserver sha256:3a29089d…05125
acore-db-import sha256:6cf19743…6cafe

Verified before committing the digests:

  • All eleven modules present in the shipped binary.
  • Version banner byte-identical to what is running today — AzerothCore rev. ceeb3116ebed+ 2026-07-24 18:11:03 -0700 (Playerbot branch). Same revision, same + dirty marker from the Valithria patch, same branch name. Only the module set differs.
  • All three pull by digest on dev-new (and are now pre-cached there, so the restart does not wait on a download).

Two settings that fail silently

  • EnablePlayerSettings 0 → 1 — without it individual-progression and challenge-modes load and run but never persist per-character state.
  • DBC.EnforceItemAttributes 1 → 0 — without it the DBC files win against individual-progression's vanilla item stats.

Neither errors when wrong.

Corrections to the plan discussed beforehand

StartingProgression stays 0. The plan was to set it to the top tier so everything defaults to fully-progressed, then drop the played character back to 0. The config file says why that fails: "existing players who are at an earlier stage will be set to this stage upon log in" — it would re-promote Freya to max on every login. Left at 0 nothing is earlier than 0, so .ip set 18 on the three idle level-80s sticks instead.

BotOnlyAdjustments = 1. Bots are excluded from progression by the stock BotAccountsRegex = "^RNDBOT.*", which matches this realm's 150 bot accounts exactly. Without this a raid of level-80 randombots walks into vanilla content at full WotLK power.

Auction listings are unfiltered, per request — the item-ID and level restrictions stay off rather than being fenced to the current progression tier.

patches/0002 — fork lag, not a broken checkout

mod-challenge-modes at HEAD declares OnPlayerResurrect(Player*, float, bool); the Playerbot branch still has bool&. Hard compile error, and the exact failure the playerbots install guide warns about.

All 13 hooks it overrides were checked against the core header — that was the only mismatch, and the parameter is unused in both overrides, so the patch is a signature match with no behaviour change. Preferable to pinning the module back to 2022, which is where the last revision predating the divergence sits. This is maintenance debt to recheck on every core bump.

Deploying this is not just a merge

docs/runbooks/wow-module-rollout.md has the full sequence. The parts that do not happen by themselves:

  1. restartIfChanged = false means the new image starts at the 05:00 window, not on deploy.
  2. wow-db-import must be run by hand. The images ship AC_UPDATES_ENABLE_DATABASES=0, and eight modules' worth of new SQL — including individual-progression's large world-DB payload — does not apply itself.
  3. .ip set 18 on Rhuarc, Restoria and Magnon.

Not done

The level-60 bot roster question is still open — whether AddClass bots spawn level-matched, or whether a rndbot init is needed. Unverified, and it does not block this.

Adding a module to AzerothCore means recompiling the worldserver, so "which modules do we want" was blocked on a build that existed only as `bin/build-images.sh` on the portable SD card — the card ADR-0027 had already stopped treating as authoritative, and which is not currently attached to anything. ## What landed **The build is versioned.** `build/build-images` + `build/pins` shallow-fetch the core and all eleven modules at pinned revisions, apply the patches, and produce all three images. No card involved. **`mod-xp-lock` is vendored** under `modules/`. It has no upstream — the card held the only copy, and dev-new's `/var/lib/wow/modules` copy was the last one in existence. It is rescued into the repo here. **Eight modules added:** individual-progression, ah-bot-plus, junk-to-gold, reagent-bank, aoe-loot, challenge-modes, transmog, dungeon-clear. ## Images built and pushed Built on nb, pushed to the Forgejo registry, tag `ceeb3116-mods1`: | image | digest | |---|---| | acore-worldserver | `sha256:94dbdf6c…7cace` | | acore-authserver | `sha256:3a29089d…05125` | | acore-db-import | `sha256:6cf19743…6cafe` | Verified before committing the digests: - All eleven modules present in the shipped binary. - Version banner byte-identical to what is running today — `AzerothCore rev. ceeb3116ebed+ 2026-07-24 18:11:03 -0700 (Playerbot branch)`. Same revision, same `+` dirty marker from the Valithria patch, same branch name. Only the module set differs. - All three pull by digest on dev-new (and are now pre-cached there, so the restart does not wait on a download). ## Two settings that fail silently - `EnablePlayerSettings` 0 → 1 — without it individual-progression and challenge-modes load and run but never persist per-character state. - `DBC.EnforceItemAttributes` 1 → 0 — without it the DBC files win against individual-progression's vanilla item stats. Neither errors when wrong. ## Corrections to the plan discussed beforehand **`StartingProgression` stays 0.** The plan was to set it to the top tier so everything defaults to fully-progressed, then drop the played character back to 0. The config file says why that fails: *"existing players who are at an earlier stage will be set to this stage upon log in"* — it would re-promote Freya to max on every login. Left at 0 nothing is earlier than 0, so `.ip set 18` on the three idle level-80s sticks instead. **`BotOnlyAdjustments = 1`.** Bots are excluded from progression by the stock `BotAccountsRegex = "^RNDBOT.*"`, which matches this realm's 150 bot accounts exactly. Without this a raid of level-80 randombots walks into vanilla content at full WotLK power. **Auction listings are unfiltered**, per request — the item-ID and level restrictions stay off rather than being fenced to the current progression tier. ## `patches/0002` — fork lag, not a broken checkout `mod-challenge-modes` at HEAD declares `OnPlayerResurrect(Player*, float, bool)`; the Playerbot branch still has `bool&`. Hard compile error, and the exact failure the playerbots install guide warns about. All 13 hooks it overrides were checked against the core header — that was the only mismatch, and the parameter is unused in both overrides, so the patch is a signature match with no behaviour change. Preferable to pinning the module back to 2022, which is where the last revision predating the divergence sits. This is maintenance debt to recheck on every core bump. ## Deploying this is not just a merge `docs/runbooks/wow-module-rollout.md` has the full sequence. The parts that do not happen by themselves: 1. `restartIfChanged = false` means the new image starts at the 05:00 window, not on deploy. 2. **`wow-db-import` must be run by hand.** The images ship `AC_UPDATES_ENABLE_DATABASES=0`, and eight modules' worth of new SQL — including individual-progression's large world-DB payload — does not apply itself. 3. `.ip set 18` on Rhuarc, Restoria and Magnon. ## Not done The level-60 bot roster question is still open — whether AddClass bots spawn level-matched, or whether a `rndbot init` is needed. Unverified, and it does not block this.
Adding a module to AzerothCore means recompiling the worldserver, and the
only build that could do that was bin/build-images.sh on the portable SD
card. Bring it into the repo as build/build-images + build/pins, which
shallow-fetch the core and every module at a pinned revision and produce
all three images without the card.

mod-xp-lock is vendored under modules/: it has no upstream, and the card
held the only copy.

Adds mod-individual-progression, mod-ah-bot-plus, mod-junk-to-gold,
mod-reagent-bank, mod-aoe-loot, mod-challenge-modes, mod-transmog and
mod-dungeon-clear. The auction house was empty (0 rows against 1504
characters) because mod-playerbots has no auction behaviour at all.

Two worldserver settings flip, and both fail silently when wrong:
EnablePlayerSettings 0 -> 1, without which individual-progression and
challenge-modes never persist per-character state, and
DBC.EnforceItemAttributes 1 -> 0, without which the DBC files win against
individual-progression's vanilla item stats.

IndividualProgression.StartingProgression stays 0 deliberately: a
non-zero value re-promotes any character below it on every login, so the
idle level-80s are lifted with `.ip set 18` instead.

patches/0002 exists because the Playerbot fork trails upstream --
mod-challenge-modes declares OnPlayerResurrect(..., bool) where the core
still has bool&. The parameter is unused in both overrides, so it is a
signature match with no behaviour change.
dominik.polakovics deleted branch afk/wow-modules 2026-08-21 00:13:03 +02:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Cloonar/nixos!375
No description provided.