Design a QBCore multicharacter and spawn handoff with explicit state, secure character selection, routing isolation, integration priorities, and recovery.
Multicharacter and spawn resources sit on the most fragile boundary in a QBCore session: the handoff from connection to identity to world state. If two resources believe they own that handoff, players can appear as the wrong character, load before routing is ready, lose housing context, or retain stale UI. A reliable flow is explicit, ordered, and recoverable.
Use the civic setting as character-onboarding context; verify the selected multicharacter and spawn resources' actual compatibility.
Document connection, authentication, character list load, preview isolation, character selection, server character load, spawn choice, world placement, routing release, player-data broadcast, and UI close. Add character creation and deletion as separate branches. Name the resource or framework event that owns each transition.
Keep preview players isolated until selection is complete. The server must validate that the selected character belongs to the authenticated account. Source IDs are sessions, not character IDs. Never allow a client to submit arbitrary identity data and proceed directly to spawn.
Review QBCore resources and use the script compatibility checklist before combining packages.
Disable competing character and spawn resources in staging. Start from the framework's supported defaults, then install the chosen multicharacter resource and required database changes after review. Test one existing character and one new character before customizing cameras or UI.
Instrument transitions with safe, structured logs containing session and character references but no secrets. Verify route assignment before preview entities appear. On selection, lock the session against another selection, load server data, calculate allowed spawn choices, validate the chosen location, place the player, release the route, and emit the supported loaded event once.
Add integrations individually. A jailed character should not choose a home spawn. A hospitalized character may need a medical destination. Last location needs safe-coordinate validation. New characters may begin at an apartment or civic onboarding point. Housing integration should follow the housing and shell guide.
Test two rapid clicks, Escape during selection, disconnect during load, resource restart, server restart, character deletion, full slots, and malformed spawn input. Use the installation help for resource-order basics.
Write a spawn-precedence table with a reason for every branch. Custody and medical restrictions normally override a user-selected apartment; a first-spawn onboarding location may override last position; an invalid property or deleted map must fall back to a maintained public coordinate. The server should calculate the winning rule and return only eligible choices, including a machine-readable reason that can be logged when a requested spawn is refused.
Add timeouts to each handoff without using them as blind delays. If character data, housing, or collision readiness does not arrive within the defined window, cancel the in-progress selection token, clean preview state, and offer a safe retry. A late response carrying an expired token must not finalize the character. This prevents a slow dependency from spawning a player after they already returned to the selector or chose another slot.
Rehearse failures from fresh connection and warm reconnect. Stop the multicharacter resource during preview, restart the spawn resource after server identity loads, disconnect while the route is changing, and fail the chosen interior. Verify source locks clear, temporary peds and cameras disappear, voice routing resets, and the same character can be selected once afterward. Repeat with two accounts selecting simultaneously to detect shared global state.
For release approval, capture a transition trace for existing, new, jailed, hospitalized, housed, and last-location characters. Each trace must show one character load, one valid placement, one route release, and one player-loaded publication. If an integration cannot meet that contract, disable its spawn option until the adapter is corrected rather than adding another event that races the framework.
The wrong character data appears briefly. Clear client stores before preview and publish data only after authoritative selection. Find listeners using cached previous-session state.
Players spawn invisible or frozen. Audit fade, freeze, collision, ped model, routing, and camera cleanup order. Use a finalization function that can safely run once.
Selection fires twice. Lock server session state and make the callback idempotent; client button debounce alone is insufficient.
Last location places a player inside an invalid map. Validate coordinates and maintain a safe fallback spawn.
Housing or jail rules are bypassed. Calculate eligible spawns server-side from authoritative state rather than trusting the presented client list.
NUI remains after spawn. Release focus and destroy cameras on success, cancel, disconnect, and resource stop.
The best spawn flow is predictable rather than clever. Make identity authoritative before world placement, treat exceptional states as first-class branches, and ensure every interrupted session has a safe exit.
Written by
xFiveM Shop Editorial Team
Questions? Browse our products or contact us