> ## Documentation Index
> Fetch the complete documentation index at: https://rust-co.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Compatibilidad

> Qué reemplaza RCO Appearance y cómo siguen funcionando tus scripts.

La mayoría de servidores instala Appearance, para el stock y sigue. Esta página es para *"¿Mi script de housing se rompe? ¿Puede quedarse la carpeta antigua? ¿Y esa barbería custom?"*

## Respuesta corta

* **Para** los recursos stock de apariencia en [Instalación](/es/rco-appearance/installation). 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

<Tabs>
  <Tab title="RSG 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

    **Pueden seguir:** `rsg-bathing`, `rsg-prison` — no son tiendas de apariencia.
  </Tab>

  <Tab title="VORP Core">
    **Reemplazados:** `vorp_character`, `vorp_barbershop`, `vorp_clothingstore` → Creator + Appearance.

    **`vorp_stores` se queda** — tiendas generales de ítems.

    **Suele ir bien:**

    * Lectores `GetPlayerComponent` / `GetAllPlayerComponents`
    * Actualizaciones parciales vía `vorpcharacter:savenew`
    * `vorpcharacter:reloadafterdeath` solo para **look**
    * `OpenOutfitsMenu` → guardarropa RCO

    El stock **`vorp_character` debe estar parado** o se saltan los shims de compatibilidad.
  </Tab>
</Tabs>

## Donde suele doler

Estos dejan de ser fiables tras el cambio:

* Scripts que hacen `SELECT ... FROM playerskins` y lo tratan como look guardado
* Scripts que escriben columnas VORP `skinPlayer` / `compPlayer` directamente
* Tiendas de terceros que envían una tabla **completa** de skin cada vez (sobrescribe pelo/cara con caché obsoleta)

La persistencia RCO es **`rco_appearance`**. Las columnas legacy pueden quedarse en tu base — no las borramos — pero Appearance ya no las lee para guardar.

<Note>
  **Niveles de soporte (para devs):** (1) `provide` por nombre de resource ✅ (2) shims export/event conocidos ✅ (3) lectura legacy única al login ✅ (4) scripts de terceros usando SQL legacy como autoridad ❌ — ver [API](/es/rco-appearance/exports) y [Migración](/es/rco-appearance/migration).
</Note>

## 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 usa `SetAppearanceForCharacter` en servidor ([API](/es/rco-appearance/exports)) y espera el callback antes de decir al jugador "guardado".