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.
Retail MeshObjects have HasMeshObject=true, Stationary=false. Our
MeshObject constructor had BOTH Stationary=true AND MeshObject=true.
The extra Stationary block (16 bytes: X,Y,Z,O) shifted all subsequent
parsing of the MeshObject block and fragment data, corrupting the
client's entity data and causing NULL+0x20 crashes.
Sniff-verified: retail interior components have Stationary=false and
HasMeshObject=true. Also restored IsRoom=true on components (sniff
confirms ALL retail room components have IsRoom=true).
Replaced 17 synthetic entries with all 587 retail entries from wago.tools.
Fixed the fundamental DB2 linkage: RoomComponentOption links to RoomComponent
via MeshStyleFilterID (not RoomComponentID as we assumed). This means one
option entry covers all components sharing the same MeshStyleFilterID.
Also fixed Alliance default theme from 6 (Folk Medium sub-theme, 0 options)
to 1 (Folk base theme, full option coverage). Fallback chain now uses
Generic(3) and Folk(1) instead of non-existent themes 8/6.
5 base themes now work: Folk(1), Rugged(2), Generic(3), Bel'ameth(4),
Silvermoon(5). Sub-themes (6-28) are texture/dye variants only.
luis