Skip to content

The AzerothCore worldserver for the ToCloud9 cluster, with mod-playerbots compiled in. No published image carries both, so this one is built from 3kynox’s three-repo integration:

PieceSourcePin
Core3kynox/azerothcore-wotlk35a34b6a
Module3kynox/mod-playerbotsd9c80b3b
libsidecar3kynox/ToCloud9f8784657

All three are pinned by commit SHA rather than branch. They are personal integration branches that get rebased and deleted as work lands upstream, so a branch ref would silently change what gets built — or vanish.

Putting mod-playerbots and a cluster-mode core in the same tree does not produce working bots. Upstream mod-playerbots targets a standalone worldserver by design; making bots cluster-aware — per-shard bot pool partitioning, cross-shard handoff, group invite accept, follow-when-grouped — is roughly eighty commits of module work plus matching core changes. That is what these branches carry.

Two couplings are load-bearing and must move together:

  • The module sits on feature/new_rpg_and_nav_5_bash, and the core carries the matching mmaps changes from PR #204. Bumping one ref without the other breaks navigation.
  • The mmaps generator version is a property of the core, not the data. This core expects generator v20; the stock gameserver-ac image expects v19. Deploying this image requires flipping the client-data job to v20 in the same change, or every tile is rejected and nothing moves.

PreloadAllNonInstancedMapGrids is required by the module — bots operate on grids no real player has activated. It costs a lot of memory and a much slower start: a single worldserver with twenty bots measured 6.35 GiB, which is why the Fleet is sized well above the stock limit and its health timings are loosened.

acore_playerbots is created and migrated by worldserver at startup, not by dbimport, and it reads that SQL from the image at runtime. The module config must be mounted at etc/modules/playerbots.conf; AzerothCore silently ignores a module conf placed in etc/ and falls back to compiled-in defaults.