Решили: узлы вращения живут в БАЗОВОМ риге, даже когда рисунок для них есть только у варианта.
Rotation Point (Wrist) заведён в BoneUnit_Standart на обе стороны; вариант несёт поверх только
визуал. Перестройка дерева подана в RigMigrate хуком, а не отдельным инструментом.
Почему: запястье, кисть и два из трёх кусков меча существовали ТОЛЬКО в варианте, дописанные сверху. Переименование по базе их бы не увидело, а удаление узла предплечья под ними унесло бы их с собой — молча, потому что удаление родителя в базе уничтожает добавленных в варианте детей. Хук вместо второго инструмента: перенос путей строится сравнением дерева «до» и «после», и это сравнение одинаково для переименования и для перестройки. Два конвейера миграции — два владельца одного правила, расходящихся без единой ошибки: один чинит клипы, другой маски.
Сказано: «У нас есть тело. У него дочернее - ПЛЕЧО. У плеча - рука от плеча до локтя. … У нас разве так? Ты понимаешь что у нас щас за бардак?» (03.08.2026, сессия d19f7828).
Грабли:
- Узел, заведённый и в базе, и в варианте, даёт ДУБЛЬ с одинаковым именем.
Findвозвращает первый попавшийся, и если это пустой близнец, код падает на пустой ссылке вместо того, чтобы сказать «их двое». Проверять надо перебором детей по имени, а неFind. - Удаление такого дубля легко снимает НЕ ТОТ узел. Пустым оказался унаследованный из базы, и его
удаление превратилось в override «removed» — структура варианта снова разошлась с базой, теперь в
другую сторону. Смотреть
PrefabUtility.GetRemovedGameObjectsперед тем, как поверить, что почищено. - Порядок работ вытекает отсюда: сначала поднять недостающие СУСТАВЫ в базу, потом переименование, и только потом перестройка иерархии. Обратный порядок теряет то, что дописано в варианте.
Владелец правды: BoneUnit_Standart.prefab (структура суставов), RigMigrate.cs (перенос путей).