Player Respawn Scripts

Respawn scripts are global player events that execute after OpenBOR creates a replacement player entity following life loss. Numbered scripts provide slot-specific behavior, while respawnall.c provides one shared listener for every player.

The numbered series consists of:

• data/scripts/respawn1.c
• data/scripts/respawn2.c
• data/scripts/respawn3.c
• data/scripts/respawn4.c

The shared listener is:

• data/scripts/respawnall.c

The replacement entity and its native player setup are available when the Respawn series begins. This makes the event useful for checkpoint placement, recovery rules, temporary protection, player-specific initialization, cooperative reentry, audiovisual effects, statistics, encounter adjustment, and other systems that should act immediately when a defeated player returns to active play.

Usage

Create any desired Respawn-script files in data/scripts. OpenBOR loads them automatically, so no model, level, or project command is required.

respawn#.c is documentation shorthand in which # represents the player number. Literal filenames use 1 through 4.

File	Scope	Player identification
data/scripts/respawn1.c	Player 1	Filename - index 0
data/scripts/respawn2.c	Player 2	Filename - index 1
data/scripts/respawn3.c	Player 3	Filename - index 2
data/scripts/respawn4.c	Player 4	Filename - index 3
data/scripts/respawnall.c	Every player	Local variable playerindex

Projects may use only the numbered files, only respawnall.c, or both layers together.

Respawn Event

The Respawn series belongs specifically to the native player-life sequence. It executes when a player loses a life, still has lives remaining after the Die series, and receives a newly created replacement entity.

This event does not represent every player entity creation. It is distinct from:

• Initial player creation when a level begins.
• Completion of an in-progress join by a vacant player slot.
• Spawning an arbitrary player-type entity through a level entry or script function.
• Creating any other entity from a model that uses Onspawnscript.

No Respawn script executes when the player's remaining lives are exhausted. Changes made to the life count by the Die series affect this decision because OpenBOR checks for remaining lives before creating the replacement entity.

Execution Order

OpenBOR performs the relevant death and respawn sequence in this order:

1. The player's life count is reduced when native life deduction is active.
2. The numbered and shared Die Scripts execute.
3. OpenBOR clears the player slot's old entity reference and removes the old entity or leaves an inert corpse according to the model's death configuration.
4. OpenBOR checks the remaining life count. Processing ends without a respawn when no lives remain.
5. OpenBOR selects a valid player spawn position and creates the replacement entity.
6. Applicable Onspawnscript hooks execute as part of creating the entity.
7. OpenBOR assigns the new entity to the player slot and completes native player setup, including its player index, input state, health, magic, rush state, and weapon handling.
8. The corresponding numbered script, respawn1.c through respawn4.c, executes when present.
9. respawnall.c executes when present and receives playerindex.
10. Native post-respawn behavior continues, including configured enemy-drop, controller-rumble, and level-timer reset behavior.

The player slot references the new entity when either Respawn-script layer begins. Scripts may retrieve it through the player property API and immediately inspect, configure, reposition, or register it.

The numbered script always executes before respawnall.c. Shared logic can consequently consume state established by the slot-specific script during the same respawn event.

Numbered Respawn Scripts

Numbered Respawn scripts are tied to the player slot identified by their filename. They receive no automatic event variables because the player identity is already fixed by that filename.

void main()
{
    // respawn2.c always represents Player 2, player index 1.
    void respawned_entity = getplayerproperty(1, "entity");

    if (respawned_entity)
    {
        setentityvar(respawned_entity, "support_role_ready", 1);
    }
}

Slot-specific files are convenient for asymmetric recovery rules, fixed cooperative roles, unique reentry effects, individual resources, camera responsibilities, or other behavior tied to one player position.

Respawnall

respawnall.c is the shared listener for every player slot. OpenBOR supplies one automatic local variable:

Variable	Type	Description
playerindex	Integer	Zero-based index of the player who respawned. Values range from 0 through 3 for Players 1 through 4.

void main()
{
    setglobalvar("last_respawned_playerindex", playerindex);
    setglobalvar("party_state_changed", 1);
}

The zero-based index matches OpenBOR's player property and scripting conventions:

playerindex	Player label	Corresponding numbered script
0	Player 1	respawn1.c
1	Player 2	respawn2.c
2	Player 3	respawn3.c
3	Player 4	respawn4.c

respawnall.c does not receive an automatic entity reference. The newly created entity is available from the player slot:

void main()
{
    void respawned_entity = getplayerproperty(playerindex, "entity");

    if (respawned_entity)
    {
        setentityvar(respawned_entity, "just_respawned", 1);
        setglobalvar("respawn_effect_playerindex", playerindex);
    }
}

Creators can use respawned_entity immediately with entity properties, bindings, visual effects, camera systems, custom variables, or other features that operate on an active entity reference.

Replacement Entity State

The Respawn series executes after OpenBOR finishes the native spawnplayer() routine. The entity has already received its player index, restored health and magic handling, weapon selection, rush handling, and reset command-input history.

Respawn scripts may build on or override this completed native setup. For example, a shared listener can move returning players to a custom checkpoint:

void main()
{
    void respawned_entity = getplayerproperty(playerindex, "entity");
    float checkpoint_x = getglobalvar("checkpoint_x");
    float checkpoint_z = getglobalvar("checkpoint_z");
    float checkpoint_y = getglobalvar("checkpoint_y");

    if (respawned_entity && getglobalvar("checkpoint_active"))
    {
        changeentityproperty(
            respawned_entity,
            "position",
            checkpoint_x,
            checkpoint_z,
            checkpoint_y
        );
    }
}

Another project might change the returned entity's resources, assign a temporary reentry state, rebuild a user interface, restore project-specific equipment, reconnect helpers, or register the entity with a cooperative controller.

Onspawnscript and Respawn Scripts

The replacement player's applicable onspawnscript executes during entity creation. The Respawn series follows after the entity has been assigned to its player slot and native player-specific setup is complete.

Property	onspawnscript	Respawn scripts
Owner	Model	Global player event
Coverage	Applicable creations of the model	Replacement players created after life loss
Entity access	self	Player slot entity
Execution point	During entity creation	After native player setup completes
Typical responsibility	Baseline setup for every applicable model instance	Reentry setup specific to the player-life event

This ordering supports a clean division of responsibility. Model initialization can establish what every instance needs, while Respawn scripts add behavior that applies only when a player returns after losing a life.

Combining Numbered and Shared Logic

Both layers may participate in the same respawn. Their fixed execution order supports a useful division of responsibility:

• Numbered respawn#.c performs slot-specific reentry setup.
• Shared respawnall.c performs project-wide reconciliation after that setup.

For example, numbered scripts might restore different cooperative roles while respawnall.c updates a shared defeat counter, reconnects the returned player to team systems, adjusts encounter pressure, and requests a common reentry effect.

void main()
{
    int active_players = 0;
    int index = 0;

    for (index = 0; index < 4; index++)
    {
        if (getplayerproperty(index, "entity"))
        {
            active_players++;
        }
    }

    setglobalvar("active_player_count", active_players);
    setglobalvar("last_respawned_playerindex", playerindex);
    setglobalvar("rebalance_encounter", 1);
}

This compact listener responds to whichever player returned without duplicating party-reconciliation logic across four files.

Choosing a Respawn Script

Need	Recommended hook
Behavior unique to one fixed player slot	Corresponding respawn#.c
The same reentry behavior for every player	respawnall.c
Fixed slot setup followed by common party handling	Numbered respawn#.c and respawnall.c together
Behavior when a player loses a life, before the respawn decision	Die Scripts
Behavior when a vacant player slot completes an in-progress join	Join Scripts
Baseline setup whenever an applicable model instance is created	Onspawnscript

Other Uses

Quick applications include:

• Checkpoint systems - Move the returning player to a saved position, route, room, formation, or safe zone.
• Recovery rules - Set custom health, magic, guard, equipment, score, power, or other resources after native setup.
• Reentry protection - Mark the entity for temporary invulnerability, collision handling, safe placement, or enemy disengagement.
• Cooperative recovery - Reconnect team roles, shared resources, helpers, objectives, bindings, camera targets, or formation logic.
• Encounter adjustment - Recalculate pressure, aggression, hazards, targeting, reinforcements, or difficulty when the party regains a member.
• Respawn presentation - Trigger flashes, sounds, announcements, portraits, transitions, controller feedback, or camera effects.
• State restoration - Reapply project-specific equipment, upgrades, modes, companions, transformations, or checkpoint data.
• Statistics and achievements - Record respawn counts, timing, player order, resource use, challenge conditions, or recovery milestones.
• Development tools - Log the new entity, verify native spawn state, inspect life counts, or test multiplayer reentry behavior.

Related Scripts

Script	Relationship
Die Scripts	Execute during player life loss before OpenBOR decides whether to create a replacement entity.
Join Scripts	Execute when a player enters through an in-progress join rather than returning from death.
Onspawnscript	Model-level creation hook that executes during creation of the replacement entity and before the Respawn series.
Ondeathscript	Model-level hook for entity death processing.
Onkillscript	Model-level hook that executes immediately before entity removal.

See Also

• Die Scripts
• Join Scripts
• Onspawnscript
• Ondeathscript
• Onkillscript
• Player Properties
• Death
• Script Overview