cs_playerbot_v2.cpp is compiled into the scripts_commands shared lib,
whose body is gated on #if TRINITY_PLAYERBOT_V2. That macro only ever
reached the module sub-libs linked into worldserver, so the command
script compiled to an empty stub and .playerbot was never registered.
Propagate the define to every SCRIPT_MODULE target when
BUILD_PLAYERBOT_V2 is on so GM commands/live PBC listener register.
Connected altbots whose AI was never attached by OnPlayerLogin (stale
core hook or is_bot false at login time) never got has_intents, so the
companion loop skipped them forever. Late-register them idempotently on
the next companion tick so they can follow without a relog.
Throttled (5s) log lines give the exact gate when a spawned altbot does
not follow: different_map / no_intents skip, combat skip, and the
formation decision (formed slot_dist vs owner_dist vs rad) that decides
move_to_slot vs follow_intent vs hold-in-place.
HandleAltCreate submitted the login via SessionMgr().LoginBot immediately
after BotCharacterFactory::Create. SaveToDB is async, so the character
row is not committed yet: BeginLogin's holder loads nothing, the BotSession
never completes and never leaves sessions_ — the bot appears 'stuck in
login' and every later .playerbot login fails with 'login already in
flight'. The .playerbot squad path already avoided this; alt create now
matches it by deferring to DrainAltFinalizes, which submits the login on
the next world tick against the committed row + CharacterCache entry.
Also hardened DrainAltFinalizes: an in-flight session older than 25s is a
wedged zombie — reap it (LogoutBot) and resubmit once so a leftover zombie
from a pre-fix build (or any future race) self-heals instead of wedging
that bot forever.
BotNamePool reads {Playerbot.SharedDatabase}.playerbots_names (default
'playerbot'), but migration 0015 created+seeded an unqualified
playerbots_names which the PlayerbotMigrationMgr executes against the
CHARACTERS DB. On a fresh install (or any server where the shared
playerbot schema was not hand-imported) the shared table stays empty,
so every bot name came from the syllable-generator fallback instead of
the curated pool ('Serpil', 'Ghielstan', ...).
0015 now targets playerbot.playerbots_names like migration 0000 does.
Existing installs must backfill once:
INSERT IGNORE INTO playerbot.playerbots_names (name,gender,race_mask)
SELECT name,gender,race_mask FROM characters.playerbots_names;
Start the next PBV2_NNNN pool index past BOTH the realm-local counter and
any PBV2_* bnet account already present in the shared auth DB, so a fresh
or renamed characters DB no longer restarts numbering at 1 and collides
with the existing fleet (AOR_NAME_ALREADY_EXIST x8 -> pool starvation).
utf8mb4_uca1400_ai_ci (MariaDB-only) breaks bootstrap on MySQL, where
CREATE DATABASE/CREATE TABLE fails outright. Switch the shared playerbot
schema and bootstrapped tables to utf8mb4_general_ci, matching the rest
of the playerbot_v2 migrations.
The LEFT JOIN characters.characters cross-DB qualifier hardcoded the
characters schema name, breaking installs with a renamed characters
database. Read it from CharacterDatabase.GetConnectionInfo() (worldserver.conf
CharacterDatabaseInfo) instead, falling back to 'characters'.
- ConfigReader: add PlayerbotsV2.FleetBots switch (default 0) + fleet_bots() accessor
- Module::Init/OnWorldUpdate: skip population shaper, bot guilds, craft-order
board, BG/LFG queue auto-fill, and AutoResume/AutoSpawn when fleet disabled
- Services: FleetThread is not started in alt-bot-only mode
- conf/playerbot.conf.dist + README document the new key
devbox