Skip to main content
You should not need to restart the server every time you want to move a spawn point two meters. Creator seeds initial locations from config, then normal live management happens through the database-backed in-game editor.

/rcospawns

Admins use:
to create, move, rename, enable/disable, reorder or remove spawn locations. Explicit ACE example:
You can replace the default permission logic with CanManageSpawns in config/server.lua.

Config locations are a seed

Config.Spawn.locations is used to create the initial database entries. After that, changing a coordinate in the config file does not magically overwrite a location you already edited in-game. The database is the live source.
If you changed config and “nothing happened,” that is usually expected on an existing installation. Use /rcospawns instead of repeatedly restarting the resource.

What the client chooses

The spawn UI works with a location identifier. The server resolves the actual location and owns the final transition. That means an integration should not treat arbitrary coordinates sent from the NUI/client as the authority for where a character may spawn.

Selector modes

Common behavior modes are: Use the mode that matches your server’s roleplay flow rather than the one with the most UI.

Last Location

When enabled, returning characters can choose the position saved from their previous session. The last-position system is separate from the list of town spawn points. Autosave keeps the stored position fresh while the character is actually in the world.

Jail / forced position

Some character states should not offer a town selector at all. Jail is the obvious example. Use the server-side forced-last-position hook for those cases so the server decides when the selector is bypassed.

Fallback

Always keep a safe fallback spawn. It is the final answer when a character has no valid last position and no other spawn choice applies. Choose an open, reliable world position — not an interior that depends on another resource loading first.