Archived on 2026-10-24. The Godot rewrite is cancelled. This handoff is historical evidence, not an active Unity task or verified runtime behavior. See the current documentation.

Audit correction (2026-10-24): material GUID a97c105638bdf8b4a8650670310a4cd3 resolves to URP Runtime/Materials/Sprite-Lit-Default.mat.meta in the installed package cache. The unresolved-material claim below is superseded; the other runtime questions remain unverified.

Import notes: Soldier Frenzy

Confirmed facts

The fixed GUID resolves exactly to Assets/Scriptable Object/Ability/Character/Frenzy.asset. Soldier.asset identifies the character as SOLDIER, points to that GUID as its starting ability, and the selected character's ability is appended to AbilityHolder.abilities during initialization. This makes Frenzy equipped for a Soldier run even though the character asset serializes unlocked: 0; it also serializes available: 1.

Base Frenzy is automatic, not input-driven. The holder attempts activation every frame. A successful attempt starts its 30-second cooldown immediately and starts the active behavior in parallel. The behavior sets its active flag, enables its child visual, waits for 2 + finalMaxStamina * 2 / 100 scaled seconds, disables the visual, then clears the flag. Clean Soldier has final max stamina 100, giving exactly 4 seconds.

There is no stamina eligibility check and no stamina spend; the serialized cost is zero. There are no levels, maximum level, charges, or stacks serialized on the production ability. Those JSON fields remain null.

While active, the continuously derived attack interval is divided by 2 and the continuously derived reload interval is divided by 4. These are multiplicative rate changes expressed as inverse interval operations, not flat stat additions or percentage-point changes. Clean Soldier's gun has attack rate 1.5 and serialized reload rate 0.4, giving intervals of 0.6666667 -> 0.3333333 seconds and 2.5 -> 0.625 seconds respectively. Damage, projectile count/speed, ammo capacity/consumption, movement, and stamina are unchanged.

Localization and presentation

The description table reference resolves key id 18032062464 to Character/Skill_Soldier. The English localized text corroborates a 30-second cadence and +100% attack speed, but runtime code remains authoritative for formulas. No separate display-name localization key was found: Soldier.asset stores the literal abilityName: Frenzy, so display_name_key is null.

The character asset's icon reference points to GUID b67cdf844d626d24d8d0b8a7c9ea6b67 (Icon_Characters-Ability.png). The active visual is an initially inactive Frenzy child in Player.prefab, using sprite GUID e4455ba13d64ed7439fe73bd71c9c8fe and animator-controller GUID f25de0cd40e3d9f4b964b71b6ba8e028. A character animator Frenzy state exists under GUID ca270ce45dbe2894bb828308985081e5, but the runtime coroutine only contains an animation TODO and never triggers it. No base Frenzy audio call was found.

Runtime ownership

• AbilityData: stable type/id, base cooldown, zero cost, automatic classification, formula constants, base multipliers, and presentation provenance.
• AbilityInstance: cooldown flag, visible cooldown counter, remaining cooldown, and owning player. Unity incorrectly serializes isOnCooldown=true and currentCooldownTime=2.699998 on the shared ScriptableObject.
• Frenzy behavior: active flag, snapshotted active duration/remaining time, visual state, and ordered activation/cleanup.
• Player stats/modifier: final max stamina and derived attack/reload intervals.
• Weapon controller: current firing timer, reload coroutine/timer, and reload feedback.
• Generic runner: routes automatic/run-start eligibility, scaled time, per-instance cooldown completion, and owner lifecycle cleanup. It must not contain Soldier/Frenzy conditions or formulas.

Cooldown, pause, and repetition

Cooldown begins before the active coroutine starts, so the 4-second activity overlaps the first 4 seconds of the 30-second cooldown. Both cooldown and duration use scaled WaitForSeconds. Pause, reward selection, and game-over make the game-state service set Time.timeScale to zero, freezing both. Weapon attack/reload timers use scaled Time.deltaTime and freeze as well.

After active cleanup, the per-frame activator keeps attempting activation; attempts silently fail while cooldown remains. At cooldown completion, the next eligible frame starts Frenzy again. Missing ability and cooldown failures have no feedback or cost. SoldierIsFrenzy independently prevents re-entry during activity.

Cleanup and pooling/reset requirements

Normal cleanup order is visual off, then active flag false. Modifier restoration is implicit: subsequent stat calculations see the false flag and use factor 1. A Godot behavior should also force those same states on owner death, disable, scene exit, cancellation, and pool return. Unity has no Frenzy-specific disable/destroy cleanup; Player.Death disables the GameObject. Consequently, stale active flags or visuals on pooled/reused players are a real risk and should not be copied as intended behavior.

The shared Unity ability asset is also a multiplayer/state-leak risk because its cooldown fields are mutable. Every player must receive an independent AbilityInstance, including independent cooldown flag/counter and timer handles.

Excluded upgrade hooks

SoldierFrenzyCDModif (base 1), SoldierFrenzyASBonus (base 0), and SoldierDashReloadPercentage (base 0) are named extension points only. The dash reload branch is not part of base Frenzy; at clean value zero it reloads nothing and emits no sound. Panic Frenzy, ASP1, evolutions, shop bonuses, permanent progression, temporary buffs, and all other abilities are excluded.

Unresolved or conflicting behavior requiring a clean play-mode trace

• Soldier.asset serializes unlocked: 0 and available: 1; the exact progression semantics are not proven here, although selected Soldier definitely receives the ability at runtime.
• Initialization clears isOnCooldown but does not explicitly clear the stale serialized currentCooldownTime; first-frame cooldown UI behavior should be checked.
• ReloadAmmo receives a snapshotted reload duration when the coroutine starts. A Frenzy transition during an already-running reload may not change that reload's completion time. Verify start-mid-reload and end-mid-reload cases.
• Reload UI divides by an additional Frenzy multiplier of 2 while gameplay reload interval is already derived with a factor of 4. Verify the bar's fill direction/rate and decide whether to reproduce or correct it.
• Verify player death during Frenzy, pool reuse, scene exit, and game-over transitions; no explicit cleanup exists.
• Verify the unresolved Player prefab material GUID a97c105638bdf8b4a8650670310a4cd3; no matching .meta was found.

No values in the JSON are estimated. Unknown schema values remain JSON null.