Prerequisite for the World-row bridge, taken verbatim from the vault half of afd5a4a
(feature/p0-gates-and-defects, already merged into integration/all-systems; the rest of that commit
is unrelated RAF work). Neither feature/mythic-plus nor feature/great-vault ever received it, and
each vault slot's level is defined as the Nth-best run of the week, so the row must keep every run's
level rather than a single bestLevel.
The Great Vault World-row bridge needs both halves and neither branch has both:
feature/mythic-plus owns WeeklyRewardChestThreshold.db2 (the DB2 the row ladder is read from) and
ChallengeModeMgr's vault services; feature/great-vault owns WeeklyRewardsMgr (the three-row
Dungeon/Raid/World model) and WeeklyRewardHandler.cpp, which is the handler an assembly actually
binds to CMSG_REQUEST_WEEKLY_REWARDS / CMSG_CLAIM_WEEKLY_REWARD.
keystoneResetTime columns) into the base characters schema so fresh
installs need no updates.
- Implement the Mythic+ criteria modifiers (keystone level, completed in
time, map challenge mode, display/milestone season, rating >=, run
count >=) - unblocks KSM-style achievements and season gating.
- player can now hire 1 (2v2) or 2 bots (3v3) gameplay in arenas.
- enemy team will have only bots
- the system should support also 2players vs 2 bots or 3 players vs 3 bots.
- not all arenas might be enabled. this is still WIP
- enemy team bots currently just wait at their spawn point - still WIP
The covenant renown LEVEL is already a renown-reputation handled by TC's
ReputationMgr and synced to the client by the standard reputation packets,
so the only covenant-specific gap was granting the per-level rewards.
- Add the RenownRewards.db2 store (Meta 0x30AFBCF8, ParentIndex=CovenantID)
and a DB2Manager (covenantId, level) -> rewards map (GetRenownRewards).
- Track the highest renown level whose rewards were granted, per covenant
(Player::m_renownRewardsGranted), persisted to a new character_covenant_renown
table and loaded at login, so each level's rewards are granted exactly once.
- Player::ReputationChanged now grants rewards for every renown level crossed
when a covenant renown reputation increases; a login catch-up
(UpdateAllRenownRewards, run in-world after SendInitialPacketsAfterAddToMap)
grants anything earned before this feature existed. UpdateRenownRewards is
guarded on IsInWorld() so nothing is granted mid-load.
- GrantRenownReward grants item / spell / title / mount via the existing
Player + CollectionMgr APIs. The cosmetic-collection fields RenownRewards
also carries (TransmogID/TransmogSetID/TransmogIllusionID, GarrFollowerID,
QuestID) are documented as follow-ups rather than half-implemented.
Unblocks covenant P2 by building the conduit sub-system the soulbind
gameplay hangs off of (all garrison-talent opcodes were Handle_NULL).
Data (Phase A): add the SoulbindConduit.db2 store (Meta 0x2632E47D
already present) so conduits can be validated by type/covenant/spec.
Collection (Phase B): the conduit collection is server-authoritative -
Player now tracks owned conduits (conduitId -> RankIndex) and socketed
conduits (GarrTalent node -> conduitId + treeId), both persisted to new
character_soulbind_conduits / character_soulbind_conduit_sockets tables
loaded at login. CollectConduit() grants at the data-driven lowest
RankIndex defined for the conduit (never assumes 0; refuses if there is
no rank row). The "conduit add" GM command is the interim grant trigger;
auto-collection from conduit items needs the item-to-conduit link (TODO).
Socketing (Phase C): CMSG_GARRISON_SOCKET_TALENT now decodes to
{ u32 GarrTalentID, u32 count, count x (SoulbindConduitID, Rank) } - the
pair mirrors this protocol's GarrisonTalentSocketData. The handler routes
to Player::SocketConduit, which validates the conduit exists, is owned,
and its covenant matches, then persists and casts the conduit's
SoulbindConduitRank->SpellID aura. ApplyConduitSpells/RemoveConduitSpells
gate on the active soulbind's tree, re-apply on login (mirrors
_LoadGlyphAuras) and swap on soulbind switch.
Server-authoritative: the client-sent rank is ignored (server uses its
own collection). The socket wire's leading id / pair order carry a
NEEDS-CONFIRM (sniff) flag, but the handler fails closed - an unowned or
invalid id simply no-ops, so a misread can never corrupt state or apply a
wrong spell.
luis