Custom medical / persisted death

Hook a custom RSG medical presentation into Creator without replacing the framework lifecycle.

Most servers do not need to edit anything here.

Use this only when an RSG character logs in already dead and your custom medical resource needs more than the default physical dead state — for example a special hospital UI, animation or internal state restore.

The compatibility goal

When the framework says the character is dead, the final gameplay ped must also reach the world in a state that medical scripts recognize as dead.

Creator should not fake a revive just to make spawning easier.

Custom bridge

The editable bridge lives in the custom bridge files shipped with Creator. During the final RSG spawn step, your build can call:

CustomBridge.RestorePersistedDeath(context)

Return true only when your integration fully handled the custom dead-state restoration. Return false to let Creator use its normal behavior.

Example:

CustomBridge = CustomBridge or {}

function CustomBridge.RestorePersistedDeath(context)
    if context.isDead ~= true then
        return false
    end

    -- Call your medical resource here.
    -- Return true only after your resource owns the restoration.

    return false
end

VORP is different

Do not copy the RSG medical bridge onto VORP. VORP Core owns its normal death/status/spawn behavior and Creator is expected to hand control back through that lifecycle.

Avoid these fixes

Do not solve a persisted-death problem by blindly:

• executing a revive command;
• firing framework death/revive events yourself;
• setting health in the selection scene;
• calling the medical resource twice because the first attempt was slow.

Those approaches create duplicate lifecycle state very quickly.

Related

• Character lifecycle
• Troubleshooting