> ## Documentation Index
> Fetch the complete documentation index at: https://rust-co.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Character lifecycle

> How Creator hands a fully spawned character back to RSG or VORP without inventing a second lifecycle.

This is the page to read when someone says: **"my HUD/medical/inventory worked before Creator but now it initializes at the wrong time."**

The fix is usually not to make every resource listen for a new RCO-specific event. Creator is designed to complete the lifecycle your framework already expects.

## The spawn is a transaction

A character spawn is not just `SetEntityCoords` followed by a fade-in. Several asynchronous things can happen:

```text theme={"dark"}
character selected
  ↓
appearance loaded/applied
  ↓
spawn location resolved
  ↓
player moved into final world position
  ↓
collision/world becomes usable
  ↓
framework lifecycle finalizes
  ↓
normal gameplay scripts take over
```

If the player changes character, logs out or a newer spawn starts, work from the older transaction must not be allowed to finish against the new ped.

## RSG Core

The important compatibility boundary for normal gameplay scripts remains the RSG loaded lifecycle.

Creator performs its appearance/spawn work first, then finalizes the expected RSG loaded sequence once the character is actually ready in the world.

For integrations that previously waited for the standard RSG player-loaded events (HUD, inventory, jobs), keep using the framework contract rather than moving everything to a private Creator event.

### Health / death

On RSG, Creator preserves the character's persisted health/death meaning through the spawn transaction. A dead character must reach the final world state physically dead so the medical ecosystem sees coherent metadata **and** ped health.

If a custom medic needs special presentation logic for a persisted dead character, use the documented custom bridge instead of patching Creator's core lifecycle. See [Custom medical](/rco-creator/custom-medical).

## VORP Core

On VORP, `vorp_core` remains the authority for character data, death/status behavior and its normal spawn lifecycle.

Creator replaces the stock selection UI/resource, but it does not duplicate VORP's core-owned events or become a second death/status system.

The important principle is **exactly once** behavior: character selection and final spawn should not cause duplicate `SelectedCharacter`/init/spawn completions because multiple entry points happened close together.

## HUD / inventory guidance

If your HUD currently starts on the normal framework loaded/spawned event, keep it there first.

Use `IsSelectionSceneActive()` when you specifically need to know whether the player is still inside RCO's selection/creation scene and should keep a UI hidden.

```lua theme={"dark"}
local selecting = exports['rco-creator']:IsSelectionSceneActive()
```

That is usually cleaner than inventing a second "player loaded" concept.

## What not to do

Do not fix lifecycle issues by:

* firing RSG/VORP loaded events a second time from your own script;
* triggering revive commands during character selection;
* forcing health/core values before the final ped/world is ready;
* retrying framework init events blindly after timeouts;
* treating the selection ped as the gameplay ped.

These workarounds tend to solve one resource while creating duplicate state for three others.