Wardrobe integrations

A housing or hotel script usually already knows when a player is allowed to use a wardrobe: they own the room, have a key, are inside the right house, passed the interaction check, and so on. RCO does not need to replace that logic. Once your script authorizes the interaction, ask RCO to open the character’s saved outfits.

Use the server export

From server code:

local ok = exports['rco-appearance']:OpenWardrobe(source)

You can also pass an options table if your integration needs one:

local ok = exports['rco-appearance']:OpenWardrobe(source, {
    -- optional context supported by your build
})

OpenWardrobe forces the editor into wardrobe mode. It does not create a physical tailor session and does not give the player access to buy arbitrary clothing. It opens the saved-outfit experience only.

Example: hotel room

RegisterNetEvent('my-hotel:server:openWardrobe', function(roomId)
    local src = source

    if not PlayerCanUseRoomWardrobe(src, roomId) then
        return
    end

    exports['rco-appearance']:OpenWardrobe(src)
end)

Your hotel resource decides ownership/access. RCO handles the wardrobe UI, saved outfits and appearance persistence.

Why it is server-side

Persistent editor sessions are server-authorized. A random client should not be able to grant itself a save-capable wardrobe/editor lease. For that reason, this is the canonical integration:

-- server
exports['rco-appearance']:OpenWardrobe(source)

Calling the client-side OpenWardrobe/persistent OpenEditor path directly is intentionally rejected with:

server_authorization_required

Client-only visual previews are different

There are legitimate cases where a script wants a local visual editor/preview without persistence. That is a different trust model and should use the explicitly local API where appropriate rather than pretending the session can save. For real houses/hotels, use the server export.

One wardrobe database

Do not copy RCO outfits into a separate housing table unless you have a very specific reason. The whole benefit of this integration is that the character sees the same saved outfits everywhere:

Tailor wardrobe
Hotel room
Owned house
Camp tent
Custom property interior
        ↓
Same RCO saved outfits

Recommended interaction flow

Player interacts with wardrobe point
  ↓
Your resource validates access server-side
  ↓
OpenWardrobe(source)
  ↓
RCO opens saved outfits
  ↓
Player previews/wears outfit
  ↓
RCO persists the selected appearance through its normal wardrobe path

Do not use a tailor as a wardrobe shortcut

Opening clothing mode from a hotel room would expose clothing-shop behavior that your housing resource probably did not intend to grant. Use OpenWardrobe when the feature is “change into an outfit I already own/saved.” Use the general server OpenEditor(source, options) only when you intentionally want another editor mode and understand its authorization/persistence behavior.

Getting Started

Guides

Reference

Use the server export

Example: hotel room

Why it is server-side

Client-only visual previews are different

One wardrobe database

Recommended interaction flow

Do not use a tailor as a wardrobe shortcut

​Use the server export

​Example: hotel room

​Why it is server-side

​Client-only visual previews are different

​One wardrobe database

​Recommended interaction flow

​Do not use a tailor as a wardrobe shortcut

Use the server export

Example: hotel room

Why it is server-side

Client-only visual previews are different

One wardrobe database

Recommended interaction flow

Do not use a tailor as a wardrobe shortcut