erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

fix #208: keep combat bar hidden in peace mode

Browse source 
Treat combat-window visibility as gameplay-state owned so character layout restoration cannot replay a stale visible bit. Reset combat state to NonCombat at character-session entry, matching retail ClientCombatSystem::Begin.

Co-Authored-By: Codex <codex@openai.com>
This commit is contained in:
Erik 2026-07-12 22:30:55 +02:00
parent 00fe993f6f
commit 8e9c538519
8 changed files with 109 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

28
docs/ISSUES.md
View file

@ -46,9 +46,33 @@ Copy this block when adding a new issue:
---
## #207 — Repeat attack continues after movement begins
## #208 — Combat bar appears after logging in peacefully
**Status:** IN-PROGRESS — fix shipped 2026-07-12, pending live gate
**Severity:** MEDIUM
**Component:** retained UI / combat lifecycle
**Description:** The basic attack bar appeared immediately after login even
though the character always enters the world in peace mode.
**Root cause:** The combat controller mounted the bar hidden and correctly
followed `CombatState`, but the later per-character layout restore reapplied a
previously saved `Visible=true` bit. Window persistence therefore overruled the
mode-owned visibility from retail `gmCombatUI::RecvNotice_SetCombatMode`.
**Resolution:** Retained-window persistence now distinguishes state-managed
visibility from user-managed visibility. The combat window still restores its
position, but ignores and no longer saves show/hide transitions. Character
session entry also resets `CombatState` to retail's initial NonCombat mode.
**Research:** `docs/research/2026-07-11-retail-combat-bar-pseudocode.md`
**Acceptance:** Log in while in peace mode: no attack bar is visible. Enter
melee or missile combat: it appears. Return to peace: it disappears.
## #207 — Repeat attack continues after movement begins
**Status:** DONE — 2026-07-12, user confirmed movement stops repeat attacks
**Severity:** HIGH
**Component:** combat / input
@ -73,7 +97,7 @@ attack loop stops immediately and movement proceeds normally.
## #206 — Relogging into a monster leaves the player stuck
**Status:** IN-PROGRESS — fix shipped 2026-07-12, pending live gate
**Status:** DONE — 2026-07-12, user confirmed occupied-position relog works
**Severity:** HIGH
**Component:** physics / login lifecycle

6
docs/research/2026-07-11-retail-combat-bar-pseudocode.md
View file

@ -65,6 +65,12 @@ The current acdream port binds the basic page because the persisted gameplay
default has `AdvancedCombatUI = false`. The separate advanced-combat surface is
still tracked by divergence row AP-110.
Visibility is combat-state-owned, not a user window preference. Per-character
window persistence may restore the bar's authored position, but must not restore
or save its visible bit: `RecvNotice_SetCombatMode` is the sole visibility
authority. Character-session initialization likewise starts at `NonCombat`, as
shown by `ClientCombatSystem::Begin` (`0x0056A460`).
## Press / charge / release
```text