Squash transplant of 433 commits from agatho/TrinityCore feature/housing-system
(c4775862d1d "Re-CREATE HousingPlayerHouseEntity on move so plot icon updates")
onto WowCommunityProject main. Source and target share no git ancestry — this
import is delivered as a single 3-way patch apply with --reject for residual
conflicts.
What's in this commit:
- Full housing subsystem: Housing/, Entities/Housing/, Entities/MeshObject/,
HousingMap, HouseInteriorMap, HousingMgr, NeighborhoodMgr, NeighborhoodHandler.
- New SMSG/CMSG packet families (0x33xxxx, 0x39xxxx, 0x55xxxx, 0x5Cxxxx,
0x5Bxxxx, plus 0x42xxxx initiative & decor opcodes) wired into Opcodes.cpp,
HousingHandler, NeighborhoodHandler, WorldSession.
- DB2 stores for HouseDecor*, HouseRoom*, HouseTheme*, HouseLevel*,
HouseExteriorWmoData, NeighborhoodPlot, NeighborhoodInitiative*, etc.
- Character DB schema for character_housing*, neighborhood_*, including
decor/rooms/fixtures/catalog tables (sql/updates/characters/master/*).
- World DB updates for housing GO templates, AT scripts, NPCs.
- Spell scripts for housing-related spell effects (npc_housing_steward,
spell_housing, at_housing_plot, go_housing_door).
- Project documentation and analysis dumps under docs/.
Files NOT in this commit (5 .rej files left in the working tree for manual
integration — the target's diverged versions of these list/enum files
prevented automatic apply):
src/server/database/Database/Implementation/CharacterDatabase.cpp.rej
src/server/database/Database/Implementation/CharacterDatabase.h.rej
src/server/database/Database/Implementation/HotfixDatabase.h.rej
src/server/game/DataStores/DB2Metadata.h.rej
src/server/game/Server/Protocol/Opcodes.h.rej
Each .rej is a "list insertion" conflict where our patch wants to add new
enum/statement entries between target lines whose neighbours diverged.
Resolution is mechanical (paste the rejected hunks into the right slots in
the target version) but should be done with awareness of the target's local
ordering. Until those are resolved the build will fail on missing opcodes,
DB statements, and DB2 metadata for housing tables.
Rooms now have FloorIndex (0=ground, 1+=upper floors) persisted to DB.
Room Z position is calculated from FloorIndex * RoomWmoData.Height
(typically 7 yards per floor). Stairwell rooms (HasStairs flag) are
placed on FloorIndex+1 of the source room.
Changes:
- Room struct: added FloorIndex field
- DB: added floorIndex column to character_housing_rooms
- SpawnRoomMeshObjects: Z = originZ + FloorIndex * ceilingHeight
- HousingRoomEntity: FloorIndex set from room data (was hardcoded 0)
- HandleHousingRoomAdd: stairwell rooms go to FloorIndex+1
- SELECT/INSERT/UPDATE queries updated for floorIndex column
- Client door filtering uses FloorIndex to show/hide stair connections:
Floor 0: hides downward stairs, Floor >=100: hides upward stairs
Testers need to run sql/housing/characters_housing_grid_migration.sql
on their characters database. Adds gridX/gridY columns and migrates
existing rooms from linear SlotIndex to 2D grid (gridX=slotIndex).
- Add neighborhood_initiative_task_progress table persisting per-task progress
and status (NOT_STARTED/IN_PROGRESS/COMPLETE) across server restarts
- Add neighborhood_initiative_milestones table persisting milestone reached
state with timestamps
- Add neighborhood_initiative_reward_claims table tracking per-player reward
claims to prevent double-claiming
- Implement PersistSingleTaskProgress, PersistMilestoneReached, PersistRewardClaim
with corresponding CHAR_REP/INS prepared statements
- LoadFromDB now restores task progress, milestone state, and reward claims
from DB instead of defaulting to zero/recalculating
- Implement ClaimMilestoneReward with full DB2 reward chain: walks
InitiativeRewardXMilestone → InitiativeReward to grant currency, items,
or favor based on RewardType
- HasUnclaimedRewards now checks per-player claim state, not just milestone reached
- HandleGetInitiativeClaimRewardRequest and HandleGetInitiativeOpenChestRequest
now use ClaimMilestoneReward for actual reward distribution
- PersistTaskProgress stub replaced with full implementation
Add complete blizzlike Chromie Time flow: NPC gossip opens expansion picker,
handler sets ConditionalFlags/FactionGroup for content tuning redirection,
selection persists via new characters.chromieTimeExpansionId column, state
restores on login, and auto-clears at max level. Implement SMSG_SET_CTR_OPTIONS
server packet for mid-session state pushes.
Fix teleport-to-plot using server-side plot resolution instead of trusting
client's PlotIndex (which is a roster index, not the DB2 PlotIndex). Resolve
correct plot via player's Housing object for self-teleport, or OwnerGuid
matching for visiting others.
Additional changes accumulated in this batch:
- Implement housing packet handlers for Phase 5-7-9 opcodes
- Fix neighborhood response wire format to match retail sniffs
- Add housing source tracking and platform cleanup SQL migrations
- Fix AreaTrigger/GameObject/MeshObject housing integration points
- Extend UpdateFields for housing-specific object data
- Add Neighborhood plot management and house finder support
- Fix door script and steward NPC interactions
- Add catalog persistence prepared statement
- Fix HouseInteriorMap Euler-to-quaternion conversion for room components
- Set EditorMode UpdateField via SetHousingEditorModeUpdateField() when
entering/exiting edit mode. The client reads this from
PlayerHouseInfoComponentData to enable ClickTarget (flag 16) for decor
selection. Without it, the housing editor stays in mode 0 and all click
flags are disabled.
- Set UNIT_FLAG_PACIFIED, UNIT_FLAG2_NO_ACTIONS and SilencedSchoolMask=127
during edit mode (sniff-verified retail behavior). Clear on exit.
- Revert ignoreNestedChangesMask from true to false in
HousingStorageData::WriteUpdate. The true flag forced full-map Create
format inside VALUES_UPDATE which crashes the client (BLZ_ALLOC 41GB)
on subsequent Decor map updates after placing decor. The original
partial-serialization issue was actually caused by ContentsChangedMask=0
which is already fixed by the Account::SendUpdateToPlayer override.
- Fix SMSG_HOUSING_UPDATE_HOUSE_INFO to send actual BnetAccountGuid
instead of ObjectGuid::Empty so house owner displays correctly in the
settings/permissions UI.
- Make character_housing position columns SQL update idempotent to avoid
duplicate column errors when schema already includes posX/posY/posZ.
Add instant visual feedback for fixture/room changes, populate licensed
decor quantities from catalog, and implement the decor refund window.
- Fixture handlers (SetCore, Create, Delete) now despawn+respawn house
MeshObjects so changes are visible without relog
- All 8 room handlers refresh interior MeshObjects after success via
shared RefreshInteriorRoomVisuals helper
- Send SMSG_ACCOUNT_*_COLLECTION_UPDATE for room add, theme set, and
material apply operations
- HandleGetAllLicensedDecorQuantities returns catalog + starter decor
- HandleGetDecorRefundList returns recently placed decor within 2-hour
refund window using new PlacementTime field persisted to DB
Add warband_achievement and warband_achievement_progress tables for
account-level achievement storage. On login, merge account-wide
achievements and criteria progress from warband tables. Titles from
account-wide achievements are retroactively granted to all characters.
Existing per-character account-wide achievements are promoted to
warband tables on first login after migration.
Discovered flight paths are now shared across all characters on the same
Battle.net account. On login, each character merges the account-wide taxi
mask into their own. When a new node is discovered, the account mask is
updated immediately. Nodes with TaxiNodeFlags::NotAccountWide are excluded.
- Add warband_taxi_mask table (one row per bnet account)
- Add PlayerTaxi::MergeAccountTaxiMask() and LoadTaxiMaskFromString()
- Merge account taxi mask during Player::LoadFromDB
- Save character's merged mask back to account on Player::SaveToDB
- Update account mask on SendLearnNewTaxiNode/SendDiscoverNewTaxiNode
Add database tables and ObjectMgr infrastructure for account-wide
reputation sharing:
- warband_reputation_faction (world DB): eligible factions config
- warband_reputation (characters DB): per-account highest standings
- Prepared statements for both world and character databases
- ObjectMgr::LoadWarbandReputationFactions() called at startup
- Pre-populate with TWW renown factions (2570, 2590, 2594, 2600)
Load 12 new Garr* DB2 stores (GarrBuildingDoodadSet, GarrFollItemSetMember,
GarrFollowerLevelXP, GarrFollowerQuality, GarrFollowerType,
GarrItemLevelUpgradeData, GarrMissionSet, GarrMissionType,
GarrMissionXFollower, GarrMssnBonusAbility, GarrSpecialization, GarrType)
across the full loading pipeline.
Implement Garrison::Upgrade() for WoD level 1-3 progression with cinematic
playback, building persistence across level transitions, and plot respawning.
Replace hardcoded follower XP formula with DB2-driven progression using
GarrFollowerLevelXP and GarrFollowerQuality stores, including quality
upgrades with ability re-rolling at tier boundaries.
Add follower custom name persistence (customName column) and mission
required follower validation via GarrMissionXFollower index.
Refactor to multi-garrison framework: Player stores map of garrisons keyed
by GarrisonType, GetGarrison() defaults to WoD for backwards compatibility,
GetGarrisonInfo sends data for all garrison types to client.
luis