Respuesta corta
- Para los recursos stock de apariencia en Instalación. No corras ambos.
- La mayoría de scripts que solo leen un look (preview housing, establos, mugshots) siguen funcionando — mismos nombres de export que antes.
- Los guardados van a tablas RCO (
rco_appearance). Tras un login, eso es la verdad. - Scripts que escriben SQL antiguo directamente pueden parecer bien hasta el próximo relog. Esos necesitan actualización o retirada.
Qué significa provide (en una frase)
Appearance responde a nombres antiguos (rsg-appearance, vorp_character, …) para que las dependencias no se rompan — pero aun así paras los recursos stock. Dos sistemas guardando el mismo personaje = pelo perdido y caras reseteadas.
Lo que suele funcionar sin cambios
- RSG Core
- VORP Core
Reemplazados:
rsg-appearance, rsg-wardrobe, rsg-barbers → Creator + Appearance.Suele ir bien:- Peds de preview en selección (
ApplySkinMultiChar, maniquíes) rsg-bathing(desvestir / vestir)/loadskin, Fix Character, eventos de recargar skin- Establos / housing que recargan apariencia
rsg-bathing, rsg-prison — no son tiendas de apariencia.Donde suele doler
Estos dejan de ser fiables tras el cambio:- Scripts que hacen
SELECT ... FROM playerskinsy lo tratan como look guardado - Scripts que escriben columnas VORP
skinPlayer/compPlayerdirectamente - Tiendas de terceros que envían una tabla completa de skin cada vez (sobrescribe pelo/cara con caché obsoleta)
rco_appearance. Las columnas legacy pueden quedarse en tu base — no las borramos — pero Appearance ya no las lee para guardar.
Scripts que cambian apariencia
Leer es seguro. Escribir es donde hay que tener cuidado. Prefiere tiendas Appearance, o envía solo lo que cambias. Para guardados programáticos usaSetAppearanceForCharacter en servidor (API) y espera el callback antes de decir al jugador “guardado”.
