docs: close #297-#299 with SHAs; session handoff

Marks #297 (9b1e6fc6), #298 (bc0077a5) and #299 (88348f67) DONE per the
issue-tracking rule, and adds a handoff covering what landed, what still needs
the user's eyes, and the route 4 decision waiting on them.

Three items are implemented and suite-green but NOT user-verified: collision
with PKLite players (including the equip/unequip case round 1 got wrong),
melee/bow on a PKLite player plus the auto-target guard, and combat-camera
tracking of a PKLite opponent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-03 21:30:17 +02:00
parent bc0077a55f
commit b17f5cee49
2 changed files with 97 additions and 3 deletions

View file

@ -446,7 +446,7 @@ diff: `9966b531` touched none of `CollisionExemption`, `CombatTargetPolicy`,
`0f2d98c5`). `@pklite` made pre-existing behaviour reachable; it did not create
it. Do #297 FIRST — #298 depends on it.
- **#297OPEN — PublicWeenieBitfield is frozen at CreateObject, so a PK
- **#297DONE `9b1e6fc6` (2026-08-03) — PublicWeenieBitfield is frozen at CreateObject, so a PK
status change never reaches the client. HIGH.** User symptom: after `@pklite`,
the local player walks straight through other PKLite players.
ACE's only PK-change message is `GameMessagePublicUpdatePropertyInt` (0x02CE)
@ -483,7 +483,7 @@ it. Do #297 FIRST — #298 depends on it.
Note the vivid target indicator (`WorldSelectionQuery.cs:271-298`) reads the
spawn PWD bits directly and is stale by the same mechanism.
- **#298OPEN — melee/missile attack admission excludes players by
- **#298DONE `bc0077a5` (2026-08-03) — melee/missile attack admission excludes players by
construction. MEDIUM-HIGH. Blocked on #297.** User symptom: selecting a
PKLite player and attacking retargets to the nearest monster (auto-target on)
or does nothing (auto-target off, logging
@ -531,7 +531,7 @@ it. Do #297 FIRST — #298 depends on it.
lets the server arbitrate PK legality (retail
`ClientMagicSystem::ObjectCompatibleWithSpellTargetType` @0x00567230).
- **#299OPEN — CollisionExemption misses retail's mover-side
- **#299DONE `88348f67` (2026-08-03) — CollisionExemption misses retail's mover-side
IsImpenetrable branch, and its doc comment asserts the opposite. LOW.**
`CollisionExemption.cs:103` checks only the TARGET's `IsImpenetrable`, and the
class doc at `:33-39` claims "retail's pseudo-C only checks the target's