Arrival points

Config.Spawns is the whole feature. Only the location id travels over the wire, and the server refuses anything not in the config.

{
    id = "legion",
    label = "Legion Square",
    district = "Downtown Los Santos",
    blurb = "The middle of everything. Traffic, tourists and trouble.",
    coords = vector4(195.17, -933.77, 30.69, 144.5),
    art = "downtown",
    accent = "#e3c069",
    tags = { "CENTRAL", "BUSY", "STARTER" },
},

Stand where you want it, face the way the character should face, and run /ccspawn <id> <label> — it prints the whole block, camera framing included.

Each location draws a built-in vector scene named by art and tinted with accent. For real screenshots, drop a .jpg named after the location’s id into html/images/spawns/ — legion.jpg, vespucci.jpg and so on. No config edit; the file name is the wiring, and a missing file leaves the artwork showing, so you can add them one at a time. 960×540 is plenty.

The two cards that are not locations take a file the same way: property.jpg for every house and apartment a character owns, and last.jpg for “Last Known Location”. Full list and the order each card searches in: html/images/spawns/README.txt.

Every option — enabled, allowLastPosition, askOnCreate, default, livePreview, previewDelay, remember, lastImage, and the full locations field list — is in Config reference § 6.

Starting at home

A character who owns a house, flat or motel room gets a card for it at the front of the rail. Choosing it lands them at their own front door and asks the housing script to let them in, so the interior, stash, wardrobe and routing bucket are all set up by the resource that owns them.

Read with no configuration at all: qbx_properties, ps-housing, qb-apartments, qb-houses, esx_property and vms_housing.

Ownership is read from the housing script’s own table and checked again on the way in. Nothing here creates, buys, sells or deletes a property, and no housing table is ever written to.

vms_housing

Read through vms_housing’s own exports, so it works on ESX, QBCore and Qbox with nothing to set up beyond vms_housing’s own install.

• Every property a character owns or rents gets a card, with the name, region and description set in vms_housing, plus RENTED and SHARED tags.
• The card lands the character at the property’s door, then vms_housing’s own EnterProperty lets them in. A flat inside a building uses the building’s door, and an MLO property uses its menu point. These are the same doors vms_housing’s own spawn selector uses.
• A character who logged out inside a vms_housing property skips the arrival picker and spawns where they left off. vms_housing then puts them back inside by itself, which is what its Config.TeleportToLastPropertyOnJoin asks a spawn selector to allow. This needs the last_property column from vms_housing’s SQL; without it, the console says so and the picker is shown as normal.
• Starter apartments are given by vms_housing’s AddStarterApartment. To give one to every new character, see INTEGRATION.md → Recipes.

Anything else goes in Config.Housing.custom — naming the table and three columns is usually the whole integration:

Config.Housing = {
    custom = {
        resource = "my_housing",
        table = "my_properties",
        owner = "owner_cid",       -- citizenid on QB/Qbox, identifier on ESX
        key = "id",                -- what gets passed to the entry point
        enterServer = "my_housing:server:enter",
    },
}

The full field list, and what each line of a property card says, is in Config reference § 6.

Turning off the housing script’s own starting-apartment step does not break this — startingApartment on Qbox, Config.StartingApartment on ps-housing, Apartments.Starting on qb-apartments. The housing script keeps running and is still read; what stops is a brand new character being handed a free apartment at login, so their first home card appears once they have somewhere to live.

---