* Make TaskContext not copyable - this allowed removing shared `_consumed` state, getting rid of memory allocation per task execution
* Use std::make_shared
* Remove unnceccessary memory alloc/dealloc in TaskContext::Repeat
* Remove std::function wrapping in every TaskContext function
1. Floor material: APPLY_COMPONENT_MATERIALS now directly updates the
specific component MeshObject's textureID instead of going through
room-level WallpaperId (which was overwritten/reset on each change).
2. Stairwell doorway: Reverted HasStairs check — stairwell rooms connect
horizontally through walls like any room. The doorway should open.
3. Added GetRoomComponentOptionID/GetHouseThemeID accessors to MeshObject
for per-component texture updates without room-level state.
Stairwell rooms are tall rooms (geobox Z=-1 to 14) placed ADJACENT to
the source room on the SAME floor, not above it. They extend vertically
through the ceiling. Only rooms connected at the stairwell's ceiling
door should go to floor+1. Was incorrectly using FloorIndex+1.
Interior decor was sent TWICE at login: once by the map visibility system
(AddToMap → UpdateObjectVisibilityOnCreate) and again by the deferred
callback (manual BuildCreateUpdateBlockForPlayer). The double CREATE
corrupted the client's entity state, making decor unselectable.
Session-placed decor only got one CREATE (via AddToMap) and worked fine.
Fix: removed the manual decor CREATE from the deferred callback. The
visibility system already handles decor delivery to the player.
1. APPLY_COMPONENT_MATERIALS handler now passes componentIDs filter to
UpdateRoomComponentVisuals (was updating ALL components including floor).
2. Stairwell room placement no longer destroys the source room's wall
(stairwells are vertical connections, not horizontal doorways).
Decor placed before the room entity system had empty RoomGuid in DB.
Without a valid AttachParentGUID (Housing/2 room entity), the client
can't select the decor for moving/removing. Now auto-assigns decor with
empty RoomGuid to the first non-base room. Also uses FloorIndex for
room Z position in decor world coordinate calculation.
The CMSG sends TextureID=4294967295 (0xFFFFFFFF) to mean "reset to
default". This was stored as WallpaperId and on respawn overrode the
texture lookup (WallpaperId != 0 → use -1 as texture). The client
showed an empty Floor Material dropdown because RoomComponentTextureID=-1.
Fix: treat WallpaperId=0xFFFFFFFF as 0 (no override) in both storage
and the spawn/update texture lookups. Also cleaned up -1 values in DB.
Note: RoomComponentOptionTexture DB2 table is empty in retail — Blizzard
hasn't populated it. Textures work via RoomComponentTexture (19 entries)
which the client reads directly by component type and theme.
1. Stairwell Z: Used room's own Height (14.0 for stairwells) instead of
standard floor height (7.0). Stairwells spawned at Z=14.1 instead of
7.1. Now uses fixed FLOOR_HEIGHT=7.0 for consistent floor spacing.
2. Dye wall/floor crossover: UpdateRoomComponentVisuals applied the theme
to ALL components. Now filters by the CMSG's RoomComponentIDs — only
the specified components are updated. Also uses the CMSG's theme ID
directly instead of room.ThemeId (which is room-level, not per-component).
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
1. Dye: Sub-themes (e.g., 20=Folk Light) had no DB2 option entries.
Added GetBaseThemeID() to convert sub-theme→base theme for lookup.
Entity field gets the selected sub-theme, not the base.
2. Door GO teleport: Used cached _sourcePlotIndex=0. Now reads player's
housing data directly (GetPlotIndex, GetNeighborhoodGuid) to find
the correct exterior plot position.
3. Decor selection: Interior decor attaches to HousingRoomEntity (Housing
GUID) instead of a MeshObject. Selection may require further work.
LoadFromDB migration replaced any non-Room-1 visual room with Room 1,
destroying user-placed rooms (Stairwell, Hallway, etc.) and resetting
gridX/gridY to 0 — causing rooms to overlap. Users can place ANY room
type as their visual room. Migration now only adds a default Room 1 if
the house has NO non-base rooms at all (empty house).
The client's placement state machine needs SMSG_HOUSING_DECOR_PLACE_RESPONSE
to finalize the current placement before receiving the UPDATE_OBJECT with the
new MeshObject. Wrong order (CREATE before RESPONSE) corrupted the state on
repeated placements, causing the preview to snap to camera ("flies to camera").
Packet order now: 1) PLACE_RESPONSE, 2) MeshObject CREATE, 3) Account update.
The interior exit door used entry 586576 (exterior door, displayId=116973)
which is invisible inside the interior. Retail uses entry 575017 with
displayId=113554 (standalone interior door model). Created GO template
with correct display, flags=0x40000, owner=HouseGUID.
1. Interior door GO: The go_housing_door script only handled exterior
(HousingMap) clicks. When clicked from interior (HouseInteriorMap),
dynamic_cast failed → door did nothing. Now detects interior map and
teleports player back to the neighborhood at the plot position.
2. Room rotation: Updates HousingRoomEntity orientation in-place via
SetMirroredPosition() UPDATE_OBJECT instead of RefreshInteriorRoomVisuals.
Room rotation now updates the HousingRoomEntity's FMirroredPositionData_C
orientation via SetMirroredPosition() instead of RefreshInteriorRoomVisuals
(which crashes). The client receives an UPDATE_OBJECT with the new rotation
quaternion and applies it visually without destroy+create.
Also added GetOriginX/Y/Z accessors to HouseInteriorMap.
HousingPlayerHouseEntity and HousingNeighborhoodMirrorEntity are
unique_ptr on WorldSession. Dereferencing them without null checks
crashes on fresh characters or edge cases where the session constructor
failed to initialize them. Added HasHousing*Entity() checks before
AddToWorld/RemoveFromWorld in Player::AddToWorld/RemoveFromWorld.
Interior decor used the first MeshObject GUID from _roomMeshObjects as
AttachParentGUID. After removing the root room MeshObject, this pointed
to a component MeshObject which the client couldn't resolve as a valid
parent (NULL+0x08). Sniff-verified: retail decor attaches to the
HousingRoomEntity (Housing/2 GUID), not a MeshObject.
When a room is added at a door pin, the source room's wall at that
connection was still showing as a solid Cosmetic wall (spawned before
the connection existed). Now ReplaceWallWithDoorway() destroys the
Cosmetic MeshObject and spawns DoorwayWall+Doorway MeshObjects in its
place, creating a visible passage between the rooms immediately.
Stairwell walls have ConnectionType=0, so the door offset lookup found no
opposite wall and defaulted to 0 → room placed at door position instead of
at the correct distance. Now searches for ANY wall in the opposite direction
(the furthest boundary) regardless of ConnectionType.
Also removed RefreshInteriorRoomVisuals from Rotate/Move/DoorType/CeilingType
handlers to prevent same-GUID DESTROY+CREATE crash.
RefreshInteriorRoomVisuals (destroy+create ALL rooms) crashes the client
with same-GUID DESTROY+CREATE in one packet. Removed from Rotate, Move,
SetDoorType, SetCeilingType handlers. These operations change metadata
only — the client handles visual updates from the response packet.
TODO: implement proper in-place UPDATE_OBJECT for room entity changes
(rotation, door type, ceiling type) instead of full visual refresh.
Door adjacency checks used gridKey(GridX+1) which was correct for grid
indices but wrong for yard offsets. Entry at GridX=0 and Room1 at
GridX=15 are 15 yards apart, not 1 grid cell. Now uses findNeighborAtDoor
which searches all rooms in the door's facing direction instead of
looking for exact +1/-1 grid neighbors.
Instead of despawning/recreating all HousingRoomEntities (which crashes
due to same-GUID DESTROY+CREATE), update the adjacent room's door
AttachedRoomGUID via UpdateDoorConnection() which modifies the existing
entity's update field and sends an UPDATE_OBJECT delta. This lets the
client's CanRemove() immediately see the correct connection count.
Despawning and recreating all HousingRoomEntities caused same-GUID
DESTROY+CREATE in one packet batch (NULL+0x08 crash). Now only the
new room's entities are spawned incrementally. Existing rooms' door
connections aren't updated live but are correct after relog.
DoorTypeId/DoorSlot/CeilingTypeId/CeilingSlot were reading from wrong
field indices (8-11 instead of 10-13) after gridX/gridY shifted columns
by 2. Fields 8,9 were also used twice (WallpaperId AND DoorTypeId).
SaveToDB then persisted the corrupt data, overwriting DB fixes.
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).
Added gridX/gridY columns to character_housing_rooms. Room positions
are now persisted as 2D grid coordinates. LoadFromDB reads grid coords
from DB. SaveToDB/PersistRoomToDB writes them. Door adjacency uses all
4 directions (+X/-X/+Y/-Y). Migrated existing data: gridX=slotIndex.
Also: refresh ALL HousingRoomEntities after room add (updates door
connections on adjacent rooms so CanRemove works correctly).
Rooms loaded from DB had GridX=0,GridY=0 (default) because grid coords
aren't persisted yet. Both Entry (slot 0) and Room 1 (slot 1) ended up
at the same world position. Fix: GridX=SlotIndex for backward compat.
After adding a room, adjacent rooms' HousingRoomEntity door connections
were stale — the old room's AttachedRoomGUID wasn't updated to reference
the new neighbor. The client's CanRemove() saw stale data and blocked
removal ("more than one connected door"). Fix: despawn ALL
HousingRoomEntities and recreate them with fresh door connection data.
MeshObjects are untouched (only room entities refresh).
Rooms now use GridX/GridY coordinates instead of linear SlotIndex for
positioning. When a player clicks a door pin to attach a room, the
TargetDoorComponentID identifies the source door. The server finds
the door's offset direction (+X/-X/+Y/-Y) and places the new room
at the adjacent grid cell.
Entry room at (0,0), visual room at (1,0). New rooms placed based on
which door was clicked. Door adjacency checks also use 2D grid for
resolving AttachedRoomGUID connections.
Sniff-verified: retail spawns a door GameObject (type 10 TRANSPORT) in the
Entry room for exiting back to the neighborhood. Alliance uses entry 575017,
Horde 587318 — neither exists in our GO template DB. Using entry 586576
(generic "Front Door", type 10, displayId 116973) at sniff-verified position
(-1002.52, -1000, 0.12) in the Entry room. Spawned in the deferred callback
after AT creation, matching retail packet ordering.
Alliance sniff shows the Z rotation quaternion is OPPOSITE to what the
DB2 OffsetRot value suggests. DB2 comp 27 has RotZ=+90° but the sniff
entity has quat Z=-0.7071 (=-90°). Similarly comp 28: DB2 RotZ=-90°
but sniff quat Z=+0.7071 (=+90°). The left and right walls were
rendering inside-out (showing their back/wooden panel side).
Sniff-verified: ALL interior walls use base theme 2 (Rugged, sub-theme 8)
regardless of faction. The Rugged WMO models are the neutral interior
walls designed to match DB2 rotation values. Folk (theme 1) wall models
have different geometry/facing — they show their back side (wooden panels)
when placed with the standard DB2 OffsetRot values.
Floors/ceilings continue to use the faction theme (Folk=1 for Alliance).
Multiple RoomComponentOption entries exist per (MSFID, theme) with
different Types: 0=Cosmetic (normal wall), 1=DoorwayWall (sealed frame),
2=Doorway (open passage). Our index stored the first match by ID which
was Type=1 (DoorwayWall) — wrong model with doorway cutouts.
Sniff-verified: retail uses Type=0 (Cosmetic) for regular walls.
Type=1/2 are only for doorway-capable walls based on connection state.
Now the index prefers Type=0 entries as the default wall model.
Player::UpdateVisibilityOf(IteratorPair) had no case for TYPEID_HOUSING_ENTITY
in its switch statement. HousingRoomEntities were silently skipped during
UpdateObjectVisibilityOnCreate (called by AddToMap). Only MeshObjects were
sent via this path — room entities were deferred to the VisibleNotifier
which runs LATER. Result: MeshObjects arrived before their parent room
entities, causing NULL+0x20 when resolving RoomGUID.
With the switch case added, HousingRoomEntity AddToMap (Phase 1) triggers
an immediate CREATE to the player, before MeshObject AddToMap (Phase 3).
The VisibleNotifier calls UpdateVisibilityOf<HousingRoomEntity> during
the grid scan, but the template was never instantiated. Without the
explicit instantiation, HousingRoomEntity CREATEs were not included in
the initial UPDATE_OBJECT packet. MeshObject components arrived first
with FHousingRoomComponentMesh_C.RoomGUID pointing to room entities
that the client hadn't received yet → NULL resolution → crash at 0x20.
The grid TypeListContainer order (HousingRoomEntity before MeshObject)
was correct all along — the missing template was silently dropping room
entities from the packet.
Also: sub-theme mapping (base theme 1/2 → entity sub-theme 6/8),
UpdateType=1 for MeshObjects, and MeshObject BuildCreate hex dump.
RoomComponentOption.Theme is the BASE theme (1=Folk, 2=Rugged) used for
DB2 lookups. FHousingRoomComponentMesh_C.HouseThemeID is the APPLIED
SUB-THEME (6=Folk Medium, 8=Rugged Medium). We were writing the base
theme to the entity field where the client expects the sub-theme.
Sniff-verified: option 267 has DB2 Theme=2 (Rugged base), but the
entity field shows HouseThemeID=8 (Rugged Medium sub-theme). New houses
default to "Medium" sub-theme: Folk(1)→Folk Medium(6), Rugged(2)→
Rugged Medium(8).
Added GetDefaultSubThemeID() to map base→sub-theme. Also reverted all
debug changes (Empty parent, skipped InitHousingRoomComponentData).
The grid TypeListContainer iterates types in order: ..., MeshObject,
HousingRoomEntity. Component MeshObjects (type MeshObject) were sent
in UPDATE_OBJECT BEFORE HousingRoomEntity. The client resolves
AttachParentGUID (Housing/2) during CREATE — parent not yet created
→ NULL → crash at 0x20.
Fix: swap HousingRoomEntity before MeshObject in the type list so
room entities are always sent first in the initial UPDATE_OBJECT.
luis