Qué ocurre realmente
Cada personaje migra individualmente, la primera vez que entra tras el cambio:- El jugador selecciona su personaje.
- Appearance comprueba: ¿ya tenemos un look guardado en
rco_appearance? - Sí → lo usa. Listo.
- No → lee sus datos stock del framework, convierte, guarda una fila en
rco_appearance. - A partir de ahí, RCO es la fuente de verdad para ese personaje. Las tablas antiguas no se leen de nuevo para gameplay.
- RSG Core
- VORP Core
Lee la fila del personaje en
playerskins (skin y clothes). El stock rsg-appearance no necesita estar activo.Tras la migración, Appearance no escribe de vuelta en playerskins. Por eso rsg-barbers debe pararse — un corte ahí guardaría en una tabla que nadie lee.Qué no es la migración
- No es un trabajo único que convierte cada fila con el servidor vacío.
- No es automática para sistemas de apariencia de terceros que guardaron looks en otro sitio.
- No es sincronización bidireccional. Editar tablas antiguas tras migrar no actualiza RCO.
Datos antiguos rotos o vacíos se omiten en lugar de guardarse como mesh glitcheado. El jugador puede necesitar reconstruir su look en el creador o en una tienda.
Checklist simple
- Copia de seguridad de la base (siempre antes de cambios grandes).
- Para recursos stock de apariencia (Instalación).
- Arranca Appearance (+ Creator si lo usas).
- Deja que los jugadores entren.
Config.Debug brevemente el primer día — las líneas de migración aparecen en consola, incluidos personajes que no pudieron convertirse.

