Skip to main content
Коротко: игроки сохраняют вид, не нужно массово конвертировать базу при установке, и не нужен ручной SQL на обычном сервере.

​
Что на самом деле происходит

Каждый персонаж мигрирует индивидуально, при первом входе после переключения:
  1. Игрок выбирает персонажа.
  2. Appearance проверяет: есть ли сохранённый вид в rco_appearance?
  3. Да → используем. Готово.
  4. Нет → читаем старые stock-данные фреймворка, конвертируем, одна строка в rco_appearance.
  5. С этого момента RCO — источник истины для этого персонажа. Старые таблицы для геймплея больше не читаются.
Старые таблицы массово не удаляются. Могут лежать в базе как backup — Appearance просто перестаёт их использовать для сохранений.
Читает строку персонажа в playerskins (skin и clothes). Stock rsg-appearance не должен работать.После миграции Appearance не пишет обратно в playerskins. Поэтому rsg-barbers нужно остановить — стрижки там сохранялись бы в таблицу, которую никто не читает.

​
Чем миграция не является

  • Не разовая job, конвертирующая все строки на пустом сервере.
  • Не автоматическая для сторонних appearance, хранивших вид где-то ещё.
  • Не двусторонняя синхронизация. Правки старых таблиц после миграции не обновляют RCO.
Битые или пустые старые данные пропускаются, а не сохраняются как глючная mesh. Игроку может понадобиться пересобрать вид в creator или в магазине.

​
Простой чеклист

  1. Бэкап базы (всегда перед большими изменениями).
  2. Остановить stock appearance (Установка).
  3. Запустить Appearance (+ Creator, если используете).
  4. Пусть игроки зайдут.
Нервничаете с большой базой? Включите Config.Debug ненадолго в первый день — строки миграции в консоли, включая персонажей, которых не удалось конвертировать.

​
Сторонние скрипты

Скрипты, которые только читают вид через compatibility exports, обычно работают дальше. Скрипты, которые пишут старые SQL-таблицы или полные skin blob, нужно обновить — см. Совместимость.