Решили: в стенде вес удара считается из УРОНА и запаса цели (урон 100, HP из
ClassBalanceConfig.BaseHp), а субъектом стоит игровой UnitView_BoneStorybook, а не голый риг.
Почему: обе величины стенд задавал сам, и обе задавал неверно — а выглядело это как поломка
игры. Голый риг BoneUnit_SwordShield мельче игрового юнита в 2.48 раза: масштаб живёт на
обёртке UnitView_*, и без неё мера роста врёт ровно там, где она единственный источник правды о
размере. Фиксированная доля урона 0.25 при HeavyHitFrac = 0.15 означала, что стенд показывал
самый тяжёлый удар в игре и выдавал его за обычный. Вместе — примерно трёхкратное искажение и
вывод «форма удара вшестеро шире юнита», под который чуть не поехали править сами формы.
Доля теперь расчётная, а не вводимая: величина, которую игра вычисляет, вбитая в инструмент руками молча уезжает от игры при первой же правке баланса. Подпись под полями показывает процент и говорит вслух, когда он упёрся в потолок размера, — иначе «поставил побольше» снова превратилось бы в незаметный клампинг.
Сказано: «У нас точно скейлы не похеали7 У нас ведь хит эффект намного меньше. В чем дело? Если что, писал, что мереем то, что средний урон - 100 урона при хите.» и следом «У нас ведь щас основной не старндартный а иной визуал у юнита. Поправишь его в линейке?» (2026-08-06, сессия d760c178). Оба промаха нашёл он, глядя на кадр.
Грабли: инструмент, который сам придумывает вход, врёт убедительнее сломанной игры — картинка выглядит правдоподобно, и первым под подозрение попадает продакшен-код. Признак, который стоило заметить раньше: величина, которую игра ВЫЧИСЛЯЕТ (доля HP), в стенде оказалась константой. Ещё одна мелочь: игровой вид тащит с собой полосы HP и маны — они не часть тела, но светятся исправно и лезут в замер.
Владелец правды: Assets/_Project/Scripts/Presentation/Editor/PostFxLabWindow.cs.