> ## 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.

# Compatibility

> How RCO coexists with legacy resource names, stock integrations and third-party scripts.

Compatibility in RCO has two different goals:

1. let stock/legacy scripts keep **calling familiar exports/events** where a safe equivalent exists;
2. avoid keeping two appearance databases alive as competing sources of truth.

Those goals are not the same thing.

## `provide` does not mean "run both"

RCO Appearance can answer for legacy resource names such as `rsg-appearance` and the supported VORP character compatibility surface. This helps resources whose manifest expects the old name.

You still stop the resource RCO replaces.

## What usually keeps working

<Tabs>
  <Tab title="RSG Core">
    Common compatibility paths include stock-style appearance applies, multicharacter preview helpers and the clothing operations used by resources such as bathing.

    `rsg-bathing` and `rsg-prison` can remain installed; the stock appearance/wardrobe/barber resources should not.
  </Tab>

  <Tab title="VORP Core">
    RCO keeps compatibility for selected `vorp_character`-style component/read/apply paths needed by the ecosystem, including wardrobe and post-death appearance reload behavior where applicable.

    The stock `vorp_character`, barber and clothing-store resources still stay stopped.
  </Tab>
</Tabs>

## Read integrations are easier than write integrations

A script that asks "what is this character wearing?" is usually straightforward.

A script that says "save this entire skin blob as the character now" is much more dangerous. That blob may be stale, incomplete or use a different schema.

For new integrations, prefer the RCO API directly instead of writing legacy SQL.

## Never use old SQL as the new source of truth

Once a character has an RCO snapshot, a query like this is no longer authoritative:

```text theme={"dark"}
SELECT skin FROM playerskins ...
```

The same principle applies to direct writes into old VORP skin/component columns.

A legacy table may still exist because migration intentionally does not delete user data. Existing data does not mean RCO is still saving there.

## External visibility / noclip

Appearance applies can rebuild or refresh MetaPed state. RCO preserves externally controlled visibility/alpha during those operations so admin/noclip resources are not expected to fight Appearance every time a look is reloaded.

If a custom invisibility system uses unusual natives/state, test it with `/reloadskin` and ped replacement flows.

## New integrations should use RCO APIs

Use:

* [Appearance API](/rco-appearance/exports) for editor/persistence access;
* [Quick Clothing](/rco-appearance/quick-clothing) for radial clothing actions;
* [Wardrobe integrations](/rco-appearance/wardrobe-integration) for housing/hotels.

That gives the integration a stable contract without depending on RCO's internal snapshot implementation.