- when GenAI response invalid for starting a bot conversation it should fall back to the static sytem. That was not the case since there was a hardcoded simple fallback. Removed
Signed-off-by: luis <[email protected]>
Completes GrantRenownReward: TransmogID resolves an ItemModifiedAppearance and adds it via CollectionMgr::AddItemAppearance(itemId, appearanceModId); TransmogSetID via AddTransmogSet; GarrFollowerID via Garrison::AddFollower (guarded on the player having a garrison). Only TransmogIllusionID (no add-illusion API) and QuestID (reward-quest semantics) remain documented follow-ups.
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.
TC already has the full pet-specialization machinery — Pet::SetSpecialization
validates the ChrSpecialization, swaps the spec spells, rebuilds the action
bar and echoes SMSG_SET_PET_SPECIALIZATION — but the client request that lets
a player pick the spec was left as Handle_NULL. Wire the handler in:
- New CMSG packet SetPetSpecializationRequest { uint32 SpecID; ObjectGuid
PetGUID } (68275 wire).
- HandleSetPetSpecialization validates the pet is the caller's and that SpecID
is a real pet specialization (ChrSpecialization.ClassID == 0) before applying.
- Opcode registered STATUS_LOGGEDIN / PROCESS_THREADUNSAFE.
The client's SetPetSpecialization binding drives this, so it is a live,
user-triggerable path, not a vestigial opcode.
luis