- 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.
Emit customer-provided reagents (and a customerPlayer sub-struct) in the crafting-order
list wire, closing the one part of the flagship that the prior pass parked as
"needs full ItemInstance serialization / server data-model gap".
Both of those blockers were a misattribution. Re-decompiling the reader tree shows the
order's reagents (JamCraftingOrder.reagents) are read by sub_7FF72915FF20 as FLAT
JamCraftingOrderItem records (orderItemID, type, itemGUID, ownerGUID, quantity,
qualityID, flags, reagentBase{itemID,currencyID}, optional slot) - NOT ItemInstances.
The ItemInstance readers (sub_7FF7291CBD40) belong to the JamCliCraftingOrder *recraft*
fields, a different sub-struct. The server's existing OrderReagent {ItemID, CurrencyID,
Quantity, Slot} already holds everything a posting carries; ownerGUID = the customer and
flags = 1 are derived at emit time.
Validated byte-exact against the live 12.0.7 sniff
(C:\sniff\ingame-shop_ordersCrafting_professions.pkt): every order in the 2054-byte
(12 orders) and 1875-byte (11 orders) responses re-encodes to the byte, 0 leftover,
including the reagent blocks and the presence-gated customerNpc sub-struct.
- CraftingOrderPackets.h/.cpp: CraftingOrderReagentData + reagent loop in operator<<
(mirror of sub_7FF72915FF20), presence-byte bit assignment (bit5 customerPlayer,
bit4 customerNpc, bit3 outputOrderItem, bit2 outputItem), customerPlayer emission.
- CraftingOrderHandler.cpp: BuildCraftingOrderData fills reagents from Order::Reagents
(ownerGUID = CustomerGUID) and sets customerPlayer for player orders.
The fulfil wire turned out to be recoverable, not reflection-walled: the client's FULFILL send serializer
(sub_7FF729155000) is BYTE-IDENTICAL to the already-decoded REJECT serializer (sub_7FF7291552B0), so
CraftingOrderFulfill reads the same { u64 OrderID; u8; string note; bit hasContext; [ClientContext] }. No crafted
item rides the wire - the server derives the output from the order's recipe, matching the client's craft-then-fulfil.
Fulfil flow (HandleCraftingOrderFulfill):
- validates the order is Claimed by the sender;
- resolves the recipe output (SkillLineAbility -> spell -> SPELL_EFFECT_CREATE_ITEM) and mails the crafted item
to the customer;
- transitions Claimed -> Fulfilled and releases the escrowed tip to the crafter;
- replies with SMSG_CRAFTING_ORDER_FULFILL_RESULT and broadcasts UPDATE_STATE.
SMSG_CRAFTING_ORDER_FULFILL_RESULT: recovered byte-exact from the client reader sub_7FF7290B9950 (all plain reads -
the "CompressedUInt32" reader 0x7FF72BE6C410 is ReadUInt32): { u8 Result; u64 OrderID; u64; u8; PackedGUID; u32;
u32; u32 }. Result+OrderID are populated; the trailing fields have no offline-resolvable meaning and are sent
0/empty (structurally exact, honest - fulfilment is also signalled via UPDATE_STATE).
Tip escrow (Blizzlike, mirrors the auction deposit; no gold is created or lost):
- CREATE now requires + deducts the tip up front (escrow), failing with MissingCurrency if the customer is short;
- FULFILL pays the escrowed tip to the crafter;
- CANCEL / REJECT / posting-expiry refund the escrowed tip to the customer.
Each order escrows once at create and releases exactly once at its single terminal transition.
Adds the order-state-change notification the client uses to refresh open browse windows in real time.
- CraftingOrderUpdateState packet (SMSG_CRAFTING_ORDER_UPDATE_STATE 0x42033D). Wire is sniff-resolved from
C:\sniff\ingame-shop_ordersCrafting_professions.pkt and cross-checked against the SAME order in the
LIST_ORDERS_RESPONSE capture - OrderID / OrderState / CrafterGUID / SkillLineAbilityID / OrderType all match
byte-exact. Layout: { u64 OrderID; u8(0); u8 OrderState; u16(0); PackedGUID CrafterGUID; u32 SkillLineAbilityID;
u32(0); u8 OrderType; u32 Field30; u32 Field34 }. Field30/Field34 hold small per-order values (~96/~38) that map
to none of the order's known fields; their semantics are not offline-resolvable, so they are sent 0 (honest).
- BroadcastCraftingOrderState(): pushes the update to the online customer and (once assigned) crafter.
- Wired into the claim / release / reject handlers after a successful state change; the freshly-updated order is
re-fetched from the mgr and broadcast. Cancel removes an unclaimed order whose only interested party (the customer)
already receives the CancelResult, so it is intentionally not broadcast.
Turns CMSG_CONTRIBUTION_CONTRIBUTE (was Handle_NULL) into the working war-effort turn-in,
closing the loop over the P1a DB2 stores and the P1 ManagedWorldStateMgr.
ContributionMgr:
- Load(): builds the collector-creature -> contribution index from CreatureXContribution.db2.
- Contribute(player, collectorGuid, contributionId):
1. Validates the collector is an NPC the player can currently interact with
(GetNPCIfCanInteractWith, no flag requirement) and that its creature entry actually
offers this contribution (CreatureXContribution authorization).
2. Resolves Contribution -> ManagedWorldStateInput, gating on the input's
ValidInputConditionID (PlayerCondition).
3. Takes the turn-in cost = the input QuestID's item/currency objectives: a first pass
verifies the player can pay the full cost (nothing is consumed unless everything is
affordable), a second pass consumes items (DestroyItemCount) and currency
(RemoveCurrency, QuestTurnin reason).
4. Feeds the total contributed amount into ManagedWorldStateMgr::AddProgress, which
advances the realm-wide progress world state (and completes an occurrence/stage at the
target). A contribution with no consumable objectives counts as one unit.
Wired: HandleContributionContribute routes the opcode (STATUS_LOGGEDIN, THREADUNSAFE);
sContributionMgr->Load() at startup after the managed world states. Builds clean (game.dll).
Progress increment = total quantity turned in (progress bar == resources contributed);
documented as the modelling choice where a state counts resources rather than turn-ins.
The war-effort Contribution system is now end-to-end: DB2 model -> collector turn-in ->
managed world-state progress. SMSG_CONTRIBUTION_LAST_UPDATE_RESPONSE remains deferred
(factory/thunk reader; no guessed wire).
Adds the realm-wide progress engine TC lacked. For each ManagedWorldState.db2 row the manager
holds a runtime state (progress, stage, occurrences, up/down phase, timers) and:
- Cycles the up/down phase (UpTimeSecs/DownTimeSecs windows); a state with zero windows is
purely contribution-driven and stays in its Up phase.
- Once per elapsed minute, accumulates AccumulationAmountPerMinute toward
AccumulationStateTargetValue during the Up phase, or depletes DepletionAmountPerMinute toward
DepletionStateTargetValue during the Down phase.
- Pushes Progress / CurrentStage / Occurrences through their world states via
WorldStateMgr::SetValueAndSaveInDb (realm-global, persisted), so the client draws the
war-effort/building progress bar and it survives restarts (restored on Load via GetValue).
- Reaching the target completes one occurrence and advances the stage.
- AddProgress(managedWorldStateId, amount) is the seam the Contribute path (P2) feeds into,
clamped to the depletion/target bounds.
Wired into World: Load() after world-state templates load (so persisted progress restores),
Update(diff) in the world tick next to the outdoor-PvP update. Builds clean (game.dll).
Note: values are pushed as realm-global world states, which covers realm-wide managed states;
zone-scoped states would additionally need per-map propagation (documented, future refinement).
Adds the four DB2 stores the Contribution system is built on (TC had the *Meta hotfix
schemas but never loaded these tables): Contribution, CreatureXContribution,
ManagedWorldState, ManagedWorldStateInput.
Field layouts derived from the authoritative TC *Meta structs (DB2Metadata.h) cross-checked
against the 68275 WoWDBDefs layouts (Contribution 167173C3, ManagedWorldState A4E9EA9F,
ManagedWorldStateInput 16683306, CreatureXContribution 29D9C37F). All four have IndexField=-1
(ID first). ManagedWorldState carries the accumulate/deplete progress driver bound to
Current/Progress/Occurrences WorldState IDs; ManagedWorldStateInput carries the QuestID that
is the contribution turn-in cost.
- DB2Structure.h: 4 entry structs.
- DB2LoadInfo.h: 4 load infos (arrays expanded per element, signedness per Meta).
- DB2Stores.h/.cpp: storage globals + LOAD_DB2 registration.
- HotfixDatabase.h/.cpp: hotfix SELECT statements (+ locale for Contribution's two
localized strings) and enum entries.
- sql/updates/hotfixes/master/2026_07_07_00_hotfixes.sql: the five hotfix tables.
Builds clean (game.dll). Next: the ManagedWorldStateMgr runtime (P1) that ticks these
states, then Contribute (P2).
to the client DB2 model (Contribution -> ManagedWorldStateInput -> ManagedWorldState), per
the architecture decision to keep it decoupled from the major-factions branch.
- doc/contribution/CONTRIBUTION_IMPLEMENTATION_PLAN_68275.md: full RE + phased plan.
Wire (CMSG both dirs RE'd byte-exact from client serializers); DB2 model incl. the key
finding that Contribution.db2 has NO FactionID (it feeds a ManagedWorldStateInput, not a
faction) and the cost = the input's QuestID turn-in (no separate cost column).
- ContributionPackets.h/.cpp: readers for CMSG_CONTRIBUTION_CONTRIBUTE
({ObjectGuid CollectorGUID, uint32 ContributionID}) and CMSG_CONTRIBUTION_LAST_UPDATE_REQUEST
({uint32 ContributionID, uint32 Field1}). Included in AllPackets.h.
Opcodes intentionally remain Handle_NULL: routing lands with the real ContributionMgr +
ManagedWorldState runtime (P1/P2) so no stub handler is introduced. SMSG_CONTRIBUTION_LAST_
UPDATE_RESPONSE deferred with a documented reason (reader is a factory/thunk maze; needs a
dispatch decompile or live sniff, no guessed wire).
luis