- let stock/legacy scripts keep calling familiar exports/events where a safe equivalent exists;
- avoid keeping two appearance databases alive as competing sources of truth.
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
- VORP 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.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: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.