Skip to main content
Version courte : les joueurs gardent leur apparence, vous ne convertissez pas toute la base à l’installation, et vous n’avez pas besoin d’importer du SQL sur un serveur normal.

​
Ce qui se passe vraiment

Chaque personnage migre individuellement, la première fois qu’il se connecte après le changement :
  1. Le joueur sélectionne son personnage.
  2. Appearance vérifie : avons-nous déjà un look enregistré dans rco_appearance ?
  3. Oui → on l’utilise. Terminé.
  4. Non → lit ses anciennes données framework stock, convertit, enregistre une ligne dans rco_appearance.
  5. À partir de là, RCO est la source de vérité pour ce personnage. Les anciennes tables ne sont plus lues pour le gameplay.
Rien ne supprime en masse vos anciennes tables. Elles peuvent rester en base comme sauvegarde — Appearance cesse juste de les utiliser pour les enregistrements.
Lit la ligne du personnage dans playerskins (skin et clothes). Le stock rsg-appearance n’a pas besoin de tourner.Après migration, Appearance n’écrit plus dans playerskins. C’est pourquoi rsg-barbers doit être arrêté — une coupe là enregistrerait dans une table que personne ne lit.

​
Ce que la migration n’est pas

  • Pas un job unique qui convertit chaque ligne serveur vide.
  • Pas automatique pour des systèmes d’apparence tiers stockés ailleurs.
  • Pas une sync bidirectionnelle. Éditer les anciennes tables après migration ne met pas RCO à jour.
Des données anciennes invalides ou vides sont ignorées plutôt qu’enregistrées en mesh cassé. Le joueur devra peut-être reconstruire son look au créateur ou en boutique.

​
Checklist simple

  1. Sauvegarde base (toujours avant un gros changement).
  2. Arrêtez les ressources d’apparence stock (Installation).
  3. Démarrez Appearance (+ Creator si vous l’utilisez).
  4. Laissez les joueurs se connecter.
Base de joueurs énorme ? Activez Config.Debug brièvement le premier jour — les lignes de migration apparaissent en console, y compris les personnages non convertis.

​
Scripts tiers

Les scripts qui lisent seulement l’apparence via les exports de compatibilité fonctionnent en général toujours. Les scripts qui écrivent d’anciennes tables SQL ou des blobs skin complets doivent être mis à jour — voir Compatibilité.