Docs: MC-4 melee anim/VFX/archetype session log; Path_to_Fun MC-4 polish

Polish-pass session log (swing animation, live range slash-arc VFX, archetype-byte spike) + roadmap MC-4 status. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-10 17:45:34 -07:00
parent 0948d49886
commit 7b3c9cc2a5
2 changed files with 47 additions and 1 deletions
@@ -0,0 +1,46 @@
+---
+date: 2026-06-10
+type: session
+tags:
+- session
+- combat
+- mc-4
+- animation
+- vfx
+- rukhanka
+permalink: gamevault/07-sessions/2026/2026-06-10-mc4-melee-anim-vfx-archetype
+---
+
+# MC-4 polish — melee swing ANIMATION + range-clarity VFX + the archetype-byte spike
+
+> Follow-on to [[2026-06-10_MC4_Combo_Melee]] / [[DR-030_MC4_Combo_Melee_Primary_Verb]]. Operator after committing MC-4: *"focus on animation + visual clarity on the melee attack — the range isn't clear and it has no animation. Also do the thing that was deferred."* Three deliverables, all compile-clean + 294/294 EditMode + Play-validated.
+
+## 1. Range-clarity VFX — a live cone slash-arc
+The cleave reach was invisible. Added a procedural **slash-arc mesh** to `CombatFeedbackSystem` that flashes on each swing matching the **LIVE** cone half-angle + range read from `TuningConfig` (so it always tracks the tuned values). A crescent (inner→outer arc, 16-seg triangle strip), oriented along `PlayerFacing`, HDR-tinted (light=cool, finisher=warm + wider via `MeleeFinisherMult`), alpha-fades over ~0.17–0.26 s. The arc IS the range telegraph — the player sees exactly how far + how wide the cleave reaches. Pooled (one mesh, rebuilt per swing); mesh+material disposed in `OnDestroy`.
+
+## 2. Melee swing ANIMATION (Rukhanka)
+The swing had no body motion. Mirrored the proven enemy attack recipe ([[DR-023_Enemy_Animation_MonsterMash]] — there is **no authored Synty Generic melee-swing clip**, so the enemy builds a procedural Root-bone clip; the player now does the same, and the slash-arc VFX carries the blade read):
+- **`PlayerRigTools`** (new editor tool, menu `ProjectM/Animation/Player - Build Melee Swing`, idempotent): builds `PlayerMeleeSwing.anim` — a procedural **Root-bone** clip (yaw wind-back→swing-across→recover + a slight forward pitch, rotation-only so the rig's authored Root-Y feet offset is untouched, 0.32 s, non-looping) — then adds an **`IsAttacking` bool param + a `MeleeSwing` state** to `AC_PlayerTopDown` (AnyState→MeleeSwing on `IsAttacking`, MeleeSwing→exit on `!IsAttacking`), exactly the enemy transition shape.
+- **`PlayerAnimationDriveSystem`**: drives `IsAttacking` from the replicated `MeleeCombo` swing window — `SwingActive = now ∈ [SwingStartTick, SwingStartTick + 13 ticks)` (NetworkTick, wrap-safe). The 13-tick pulse is **< the swing lock (16)** so a CHAINED swing re-pulses the bool false→true and re-triggers the Any-State transition per hit. Added `in MeleeCombo` to both the LOCAL + REMOTE jobs (it replicates → teammates' swings animate too); null-safe via `HasParameter`. Play-confirmed: `AC_PlayerTopDown` re-baked to **5 params** (was 4 — `IsAttacking` added).
+
+## 3. The deferred archetype byte (MC-6 dispatch SPIKE)
+Built the thing DR-030 deferred — minimally + correctly per the MC-4 review's BURST-1 finding (byte on the blob, read at dispatch, **NOT** folded through `EffectiveAbilityStats`/`StatRecomputeSystem` — it is static identity, not a tunable stat):
+- `AbilityArchetype : byte` enum (Projectile=0 / Hitscan / Cone / Aoe) + `byte Archetype` on `AbilityDefBlob`; authored on `AbilityDefinition` (defaults Projectile) + baked in `AbilityDatabaseAuthoring`.
+- `AbilityFireSystem` reads the archetype from the blob (`ref abilityDb.Value.Value` then `TryGetAbility`) and gates the projectile path on `archetype == Projectile`, with the **dispatch point** marked for MC-6's hitscan/cone/aoe. All current abilities are Projectile (0) → zero behaviour change. This is the de-risk SPIKE (the data field + the dispatch read-point); the full non-projectile dispatch is still MC-6.
+
+## Validation
+- **Compile:** clean — 0 errors (Bursted `AbilityFireSystem` blob read OK; Bursted `PlayerAnimationDriveSystem` jobs with the new `MeleeCombo` param + the `SwingActive` static OK). One benign "Leak Detected: Persistent" warning = the `_prevPos` cache across a scripts-only domain reload, not a code bug.
+- **EditMode: 294/294 green** — the `AbilityDefBlob` layout change (default Archetype=0) is non-breaking; `AbilityDatabaseBlobTests` + all others pass.
+- **Play (real netcode session):** zero console errors/exceptions; `AC_PlayerTopDown` re-baked to 5 params (IsAttacking present → the swing anim CAN play); player baked `MeleeCombo` + local owner; firing path intact (AbilityDatabase re-baked with the byte, no regression). The slash-arc + swing-anim VISUAL feel is the operator's gate (left-click to see).
+
+## Notes / deviations (deliberate)
+- The swing animation is a **procedural Root-bone body motion**, not an authored arm-swing — no Synty Generic melee clip exists for this skeleton (same constraint the enemy attack works under). The slash-arc VFX carries the blade visual. A real authored swing clip is a future Synty-import task if wanted. Curves live in `PlayerRigTools` (re-runnable) for easy retuning.
+- New assets: `PlayerMeleeSwing.anim` + the modified `AC_PlayerTopDown.controller` (committed).
+- The archetype byte is a **spike**, not MC-6 — only Projectile is wired; the other cases are the documented extension point.
+
+## Open items (operator)
+- **The MC-4 fun-gate still stands** — now with the swing animation + a clear range arc, run the feel pass (left-click = melee). Tune the swing curves in `PlayerRigTools` (re-run the menu item) + the cone/range live via `DEV ▲`.
+- After MC-4 passes → **EB-1 (machines can die)** is the next committed milestone.
+
+## Links
+[[2026-06-10_MC4_Combo_Melee]] · [[DR-030_MC4_Combo_Melee_Primary_Verb]] · [[DR-022_Animation_Pipeline_Rukhanka_Synty]] · [[DR-023_Enemy_Animation_MonsterMash]] · [[Path_to_Fun]]