The 12.1 update added '#include <algorithm>' and '#include "MapManager.h"'
between ItemUpgradeMgr.h and the LoginQueryHolder class, breaking the
patch hunk. Adjust the LoginQueryHolder-removal hunk context/lines.
The module's OnTalkToCreature quest-mimic handler was never reachable — the
hook had no call site. 'Use item on NPC' objectives (quest 433, Runes of
Return on Trapped Miners) credit through TalkedToCreature (often via the
NPC's SmartAI), so bots never received the TALKTO objective credit when the
owner used the item. Add the hunk to the ThordekkCore patch.
- Riding (skill 762) granted automatically at modern thresholds (L10
Journeyman 150, L20 Expert 225, L30 Master 375). One tier-appropriate
mount spell learned per tier, data-driven from the Mount DB2.
- Runs on bot login, level-up and alt finalize.
- Owner-mount sync: Unit::Mount/Unit::Dismount hooks push
MountIntent/DismountIntent to owned bots so the party travels together.
- Add Unit.cpp mount/dismount hunks to the core-hooks patch.
- Hearthstone/return-to-inn sync: module teleports every owned bot to its
(owner-synced) homebind when the owner spell-ports to their own homebind.
- Leveling spec for Priest now Holy (257) instead of Shadow (258): the L10
real-spec promotion was forcing Shadow, flipping her role to Dps and
stopping her healing.
- Add the TeleportTo hearthstone hunk to the core-hooks patch.
- OnLootUnit's corpse-open quest-item scan double-granted every creature
quest item (owner opens corpse -> +1, owner takes item -> +1 via
OnLootItem). Remove the redundant scan; OnLootItem is now the single
propagation path (covers creature AND GO loot). Fixes double loot.
- BotGear: add specialization control. New GEAR_SPECS_REQ lists the bot's
specs; GEAR_SET_SPEC switches via Player::ActivateTalentGroup. Addon
renders a spec button row on the panel; active spec is highlighted.
The alt/companion finalize paths used 'bot->GetLevel() != targetLevel' and
called GiveLevel(owner level) — a bot that naturally out-leveled the owner
(e.g. hit 10 while owner was 9) got reset back DOWN to the owner's level,
wiping XP and breaking progression, and jumbling the bot's stats (the
recurring 'bots show the player's 1110/1000 stats' bug). Only level UP:
change the guards to '<' so bots are never reset below where they already
are.
Chests with chestPushLoot auto-store via Loot::AutoStore AND the player also
takes the item via StoreLootItem — both fired the quest-item propagation hook,
double-granting bound quest items (Bundle of Wood). Remove the AutoStore hunk;
the non-gated StoreLootItem hook already covers loot-window takes including
bound items.
The previous edit added two comment lines to the StoreLootItem hook hunk but
the hunk header still said 13 new lines (now 15), so git apply rejected the
patch as corrupt. Correct the count.
Player::StoreLootItem gated the quest-item propagation hook on 'newitem' —
but quest-BOUND items (Bundle of Wood 13872, ground-pickup quest items)
return nullptr from StoreNewItem (the bound-objective guard), so the hook
never fired and owned bots missed those items. Fire it regardless.
OnPlayerLootItem was only wired into Player::StoreLootItem (creature-corpse
loot windows). GameObject loot — ground-pickup quest items like Bundle of
Wood (13872), gathering nodes, chests — routes through Loot::AutoStore and
never fired the hook, so owned bots missed those quest items. Add the
TRINITY_PLAYERBOT_V2 hook in Loot::AutoStore, mirroring the creature path.
The core's party-share credits every grouped bot for BOTH combat kills AND
NPC-click objectives (Fear No Evil click fires OnKillCredit for each grouped
bot once, guid empty or not). The empty-guid special case pushed to all bots
and double-counted. Simplify: skip grouped bots unconditionally (the core
handles them); only ungrouped owned bots need the module push.
Combat kills carry a creature guid and are ALREADY shared to grouped bots by
the core — pushing again double-counts, so skip grouped bots for those (only
ungrouped bots get the push). NPC-click credits (Fear No Evil etc.) pass guid
EMPTY and are single-caster/not reliably shared, so push to ALL owned bots for
those. Distinguishes on guid.IsEmpty(): combat kill (non-empty) -> skip
grouped; click (empty) -> push all.
LogoutBot's LogoutPlayer(true) ran the FULL account-scoped SaveToDB on a
headless bot sharing the owner's account, corrupting player/character data on
logout and server-reset (confirmed: corruption started exactly with this
change; fresh characters then crash the client at world-enter with
CombatLogEntry empty-guid-type). Revert to LogoutPlayer(false) (the safe,
long-standing behaviour).
NPC-click objectives (quest 63447 'Fear No Evil') are single-caster spell-script
credits the core does not reliably share to party members — when the owner
rushed the clicks, an out-of-range/sync bot (Lica) missed a click. Pushing
KilledMonsterCredit to every owned in-world bot regardless of group makes it
robust; it is idempotent (core ignores already-complete objectives) and the
per-bot OnKillCredit re-entry is filtered by IsBot(), so no double count.
The core's party-shared credit fires OnKillCredit for every grouped bot on the
quest for both combat kills and non-combat NPC-click objectives. The module
only skipped grouped bots IN combat, so non-combat credits (quest 63447 'Fear
No Evil' clicking Injured Stormwind Infantry) were pushed again ->
KilledMonsterCredit -> double count. Skip the push for any grouped bot; only
ungrouped bots need the module's credit.
The wedge-remediation blacklists a turn-in the bot can't path to, and the
picker then skips it — but that also strands a bot that HAS reached the NPC:
it stands next to the quest giver with a complete quest, current_quest_id=0
([picker_none]), and never turns in (so the chain stalls). If the bot is
within ~40y of the resolved ender, the turn-in is trivially reachable — let
the picker select it despite the blacklist.
LogoutBot called LogoutPlayer(false), which skips SaveToDB — a quest pushed
and progressed this session was lost on logout unless a 15-min autosave
happened to fire first. Bots then couldn't complete the quest the player
finished, breaking the chain (follow-up quest un-pushable). Use
LogoutPlayer(true), matching the BotSession idle-timeout path.
ResolveOwnerAssistTarget preferred GetSelectedUnit() over the victim, so
merely targeting a neutral/yellow mob made every bot attack it. Now the
victim (real combat target) is preferred, and the selected-unit fallback
only counts when the owner is IN combat and targeting that unit (a cast
in flight) — a selected-but-unattacked mob never pulls the squad.
Bots follow the owner at formation distance (2.5-8y), so when the owner uses
sell-all-junk the bot is usually beyond GetNPCIfCanInteractWith's ~4y range and
sell_trash bailed with InvalidTarget — nothing was ever sold. Bots are
headless, so look the vendor up directly (flag-checked) without the proximity
requirement, and log the sold-item count.
'bag full' was misleading — with free slots AddItem can still return false
via CanStoreNewItem/StoreNewItem rejection (bound-item guard etc). Include the
CanStoreNewItem result (ir), noSpace, actual free backpack slots, and current
item count in the failure log so the rejection reason is visible.
Item-started quests (e.g. item 1307 'Gold Pickup Schedule' -> quest 123 'The
Collector') require the source item in the bag for CanAddQuest to pass, but
the module only copied quest-OBJECTIVE items — so the push was skipped with
'(CanAddQuest)' and the bots never got the quest.
- GiveQuestItem (loot path): when the owner loots an item whose template
starts a quest (GetStartQuest()>0), grant one to each bot.
- TryPushQuestToBot (accept path): backstop — grant the quest's SrcItemId
if the bot lacks it before the CanAddQuest check.
The client only fires CHAT_MSG_ADDON events for prefixes registered via
RegisterAddonMessagePrefix. BotGear never registered 'PBC' (PlayerbotControl
does), so the server's GEAR_BAGS_RESP / GEAR_EQUIP_RESP replies were dropped
client-side and the panel stayed blank even though the round-trip reached the
server. Register the prefix on PLAYER_LOGIN.
The server's addon OnChat hook only fires inside Player::WhisperAddon, which
requires the whisper target to resolve to a real connected player. The fake
'PBCFLEET' name is dropped before the hook, so BotGear requests never reached
the server. Whisper the OWNER's own name instead (self-whisper) — the exact
path PlayerbotControl uses (it re-points its fleet target at UnitName('player')
on PLAYER_LOGIN). The bot identity rides in the payload.
The client's UnitGUID format is unreliable across builds (the parser kept
extracting the realm/sub field), so the request resolved the wrong player and
no GEAR response was ever returned. The bot's NAME is stable, so:
- Server: GEAR_* handlers resolve fields[0] as a name OR numeric guid-low via
ResolveGearBot(), and authorize via the resolved bot's guid.
- Addon: ResolveTarget returns UnitName('target'); all requests send the name;
responses are matched by name; slash handler retries RefreshTarget after
0.25s so the first open still populates when the unit is transiently
unavailable right after targeting.
The UnitGUID parser grabbed the realm/sub field (-(%d+)-%x+$) instead of the
low counter, so the request carried the owner's guid (1) and the server
resolved the owner, not the bot — FindConnectedPlayer + IsOwner both failed
and no GEAR response was ever sent. Parse the LAST '-' group as hex (the
character counter), and reset the title hint when no target resolves.
Whispering the bot's character name routes the server's OnChat hook to the
headless bot's session (pool account), so GEAR responses were never sent to
the owner. Match PlayerbotControl: whisper the magic 'PBCFLEET' target; the
bot guid is carried in the payload and the handlers authorize via Owners().
The server rejects any PBC frame with seq == 0 (AddonControl envelope
check), so GEAR_BAGS_REQ/GEAR_EQUIP_REQ were silently dropped and the panel
rendered with no data. Send uses an incrementing seq like PlayerbotControl.
- BotCommandParser: accept 'role' (addon verb) and 'role_all'/'roleall' as
aliases for 'setrole'/'setrole_all' so the PlayerbotControl roster role menu
works (was refused as unknown verb).
- BotGear.lua: create frames/buttons with 'BackdropTemplate' so SetBackdrop
doesn't throw (retail 11.x+ requirement) — /botgear did nothing because the
frame build errored out. Also fix the goldText/bagScroll/bagContent locals
being declared after first use.
AddonControl.o was never pulled into the worldserver binary: nothing in the
worldserver link referenced its symbols (OnAddonWhisper is only called from the
scripts module, OnSessionLogout was declared but never called), so -rdynamic
could not export OnAddonWhisper and libscripts_commands.so failed to load with
'undefined symbol'. OnPlayerLogout now calls AddonControl::OnSessionLogout for
real players (its documented purpose), anchoring AddonControl.o into the
worldserver link so both symbols are exported.
Server (AddonControl.cpp):
- GEAR_BAGS_REQ now returns gold, the four equipped bag containers (entry+size),
and items from the backpack AND all bags (bagNum 0..4).
- GEAR_EQUIP_ITEM accepts items from any bag slot (not just the backpack).
- New GEAR_DESTROY_ITEM <guid> <bag> <slot> — permanent item destruction.
- New GEAR_MOVE_ITEM <guid> <srcBag> <srcSlot> <dstBag> <dstSlot> — rearrange
items between bag slots (empty destination only).
Addon (BotGear.lua):
- Full 3D character preview (ModelScene) of the targeted bot, live-updating.
- Renders backpack + real bag containers with gold display.
- Left-click pick up / left-click place to move items between slots.
- Right-click bag item to equip; shift+right-click to destroy; right-click
equipped item to unequip.
OnAbandonQuest was checking/removing the owner's raw quest_id on the bots, but
bots hold the class/race VARIANT (ResolveBotQuestId, same as OnAcceptQuest). For
variants like 28767 -> 28763 the status check hit NONE and the bot kept the
quest. Resolve the bot's equivalent before taking source items / removing the
active quest, and use the variant's template for timed/PvP cleanup.
QUEST_OBJECTIVE_FLAG_2_QUEST_BOUND_ITEM objectives (e.g. Westfall 'Collecting
Kelp' item 1256) are never stored in inventory — the objective counter is the
source of truth and the core rejects StoreNewItem/AddItem for them. The module
was calling AddItem anyway, which failed as 'inventory full or unplaceable'
despite free bag space, leaving bots unable to complete the quest and
therefore ineligible for the follow-up (112 -> 114).
EnsureBotQuestItems and GiveQuestItem now detect bound objectives and tick the
counter via SetQuestObjectiveData instead of granting a physical item.
The formation slot block sat inside the per-alt loop and re-iterated every
alt of the account for every alt (O(n²)) every 250ms. Move it before the
per-bot loop so it runs once per owner per tick (O(n)).
- OnAcceptQuest parks class-equivalent quests for companions still mid-login
(connected but not in-world) in g_pending_quests; OnPlayerLogin drains them
once the bot lands. Freshly-added bots no longer miss the owner's quest.
- Tighten AltFollow to match mod-playerbots (followDistance 1.5y): formation
slots at 1.5y, slot tolerance 2y, min recall radius 2y (was 4y).
- Default companion formation Spread (ring 2.5y, surrounds leader) instead of
Line (trailing fan); Spread ring tightened 5y -> 2.5y.
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 ('Do NOT log a
just-created char in on the same call'); 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).
- Gate ambient fleet behind PlayerbotsV2.FleetBots (default 0: alt-bot-only
mode); config plumbed through ConfigReader and documented.
- BotNamePool orphan sweep sources the characters DB name from server
config (CharacterDatabase connection info) instead of hardcoding
characters.characters, so renamed characters schemas keep working.
- Shared playerbot bootstrap uses utf8mb4_general_ci (utf8mb4_uca1400_ai_ci
is MariaDB-only and breaks CREATE DATABASE on MySQL).
devbox