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

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.

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.

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:

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 for editor/persistence access;
• Quick Clothing for radial clothing actions;
• Wardrobe integrations for housing/hotels.

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