# acdream — known bugs

Track visual, gameplay, and protocol bugs here. Close by moving to
the "Fixed" section with the commit hash that resolved it.

---

## Open

### BUG-001: Wrong cloth textures on characters
- **Observed:** 2026-04-13
- **Description:** Character clothing renders with incorrect textures.
  ObjDesc Phase 5 (AnimPartChange + TextureChanges + SubPalettes) is
  shipped but something is off — either a texture-swap ordering issue,
  a missing remapping step, or a palette application bug.
- **Repro:** Connect to ACE server, observe player character or NPCs.
- **Likely area:** `WorldEntity` ObjDesc application, `TextureCache`,
  or the CreaturePalette pipeline in `InstancedMeshRenderer`.
- **Phase:** Unassigned (investigate after rendering rebuild Step 5).

### BUG-002: Jump not visible from retail client
- **Observed:** 2026-04-14
- **Description:** Jump works locally (player rises and falls) but no
  jump packet is sent to the server. Other clients don't see the jump.
- **Repro:** Jump in acdream, observe from retail client — no jump visible.
- **Likely area:** GameWindow.cs jump packet sending (currently a TODO
  Console.WriteLine). Need to research jump packet format from holtburger.
- **Phase:** B.2 (movement completion)

### BUG-003: Facing direction mismatch with server
- **Observed:** 2026-04-14
- **Description:** Character facing direction in acdream doesn't match
  what other clients see. Our quaternion convention for outbound
  MoveToState/AutonomousPosition packets is wrong.
  AC convention: heading 0 = West, 90 = North, 180 = East, 270 = South.
  Our convention: Yaw 0 = +X (East in AC terms). The wireRot quaternion
  needs to use holtburger's `from_heading` formula:
  `theta = (450 - degrees).to_radians()`, `w=cos(theta/2)`, `z=sin(theta/2)`.
- **Repro:** Walk in acdream, observe from retail client — character faces
  wrong direction.
- **Likely area:** GameWindow.cs wireRot computation (line ~1899).
- **Phase:** B.2 (movement completion)

### BUG-004: Run speed not verified working
- **Observed:** 2026-04-14
- **Description:** RunRate wiring exists (Task 1) but user reported no
  speed change. Either the server's UpdateMotion ForwardSpeed isn't being
  received, or it's not propagating to the velocity computation. Need to
  add diagnostic logging to verify the UpdateMotion path fires.
- **Phase:** B.2 (movement completion)

---

## Fixed

_(none yet)_