Решили: длина следа за клинком задаётся ВРЕМЕНЕМ, а не углом: виден путь остриёя за последние
SwingArcTrailSeconds (0.15 с). Начало хвоста берётся из кольцевого буфера проб «угол + момент» —
той же конструкции, что точки внутри TrailRenderer. Прежний SwingArcMaxSpanDeg остался
страховкой от сектора длиннее оборота и поднят до 350°.
Почему: градус — не та единица. «Держим 150° пути» ничего не знает о скорости, поэтому укол и
тяжёлый замах оставляли одинаковый след, и вес удара переставал читаться. След клинка — остаточное
изображение, его длина есть скорость × время: быстрый взмах обязан тянуть длинный хвост, медленный
короткий. Так устроены все трейлы, которые мы проверили — TrailRenderer.time, ribbon-трейлы Niagara
и Godot: у точки есть время жизни, а не пройденный путь.
Технологию при этом не меняли. Переход на настоящий ribbon по мировым точкам отвергнут: замер клипа «Атака 1» показал, что остриё идёт вокруг плеча по окружности с разбросом радиуса 6% (1.290 → 1.365 за окно взмаха), то есть хранить полные позиции нечего — достаточно углов. Ribbon понадобится, если появятся анимации НЕ по окружности: уколы, восьмёрки, размашистые выпады.
Заодно радиус сектора перестал запоминать максимум и следует за рукой: после удара локоть сгибается, и кольцо на прежнем радиусе «висело» дальше клинка.
Сказано: «И да, нам надо не сколько градусов пути держим. А сколько секунд. У нас ведь могут быть медленные атаки. Быстрые. Колющие. И т.д. Это вообще не от градусов быть должно. Поэтому вдеь и предлагаю трейл или чет похожее.» (2026-08-07, сессия f0c50476).
Грабли: новое поле ScriptableObject не появляется в ассете, пока редактор не пересоберёт домен,
— SerializedObject.FindProperty до этого молча возвращает null, и правка выглядит как «значение
не сохранилось». Сначала RequestScriptCompilation, потом запись.
Владелец правды: SwingArcVfx.Remember / OldestLiveAngle,
CombatFeelConfig.SwingArcTrailSeconds.