Skip to content

Health & Combat

Combat is opt-in. Nothing in your world takes damage unless you deal it — there is no automatic combat, no friendly fire, and player-vs-player is off by default (a Weapon can shoot world objects but never another player until you enable PvP). A purely social world never sees a single death. When you do want destructible objects, player death, or checkpoints, this page shows how to add them, mostly with no-code actions.

The two halves of combat are separate:

  • Objects (barrels, crates, vehicles) get health from the SSHealth component.
  • Players don't use SSHealth — they have built-in health, death, and respawn handled for you.

Object health with SSHealth

Give any dynamic object server-authoritative health by adding Add Component ▸ Social Scape/Health (SSHealth). Like a World Trigger, it's pure data: the server owns the HP and drives death, and you pick what happens with the same conditions + actions you already use for world logic. Only one SSHealth is allowed per object.

Field What it does
Max Health The object's starting and maximum HP. Default 100.
Team Team id for friendly-fire rules on incoming damage. 0 = neutral.
Invincible When on, all damage is ignored — but a direct Combat.Kill still destroys it. An indestructible object that still has HP semantics.
Variables Session memory (a hit counter, a state flag) that this object's conditions can read and its actions can write.
Entries The list of responses — one per damage/death rule (below).

Entries: what happens on damage or death

Each Entry is one rule with these parts:

  • Trigger — On Death (HP reached 0, or a script called Combat.Kill) or On Damage (took a hit but survived).
  • Method (optional) — the name of a NexusScript method to also call, server-side and authoritative.
  • Conditions (optional) — all must pass for the actions to run.
  • Actions — the built-in response.

The death/damage response uses the exact same actions as World Triggers — trigger an Animator, spawn debris, toggle an object active, destroy something, play audio, and so on. Anything you can do from a world trigger, you can do when an object is hit or destroyed.

HP is server-authoritative

The game server owns each object's health, so a client can't forge it. Damage can come from a script (Combat.ApplyDamage / Combat.DamageSelf / Combat.ApplyRadiusDamage), a trap, an NPC, or a player firing a Weapon — the server validates the fire rate, range, and aim, and clamps every hit before it lands.

Example — a destructible barrel. Add SSHealth to a barrel, leave Max Health at 100, and add one entry:

  • Trigger: On Death
  • Actions:
    1. Play audio — an explosion sound.
    2. Toggle active — turn a hidden "wreckage" object on.
    3. Destroy — remove the barrel.

Now anything that deals 100 damage to the barrel plays the sound, swaps in the wreck, and removes the intact barrel — with no script. A trap or an NPC can deal that damage, a script can call Combat.ApplyDamage on the barrel's network id, or a player can shoot it with a Weapon.

Delay an action

Every action has an optional Delay (seconds). The engine waits, then runs the action, so you can sequence "on death → wait 2 s → collapse the bridge" with no scripting. 0 runs immediately.

Player death & respawn

Players do not use SSHealth. Every player has built-in, server-authoritative health (default 100). When a player's health reaches 0:

  1. Their avatar ragdolls.
  2. The camera pulls back to third-person.
  3. After about 4 seconds they auto-respawn at their checkpoint.

What can hurt a player: falling out of the world, a trap, an enemy NPC, a script (Combat.DamageSelf / Combat.ApplyDamage), or a Weapon fired by a player — all server-validated. See the Combat API for the scripting side.

The server is in charge

Health, death, and respawn are all decided by the server, and it rate-limits damage and respawn requests. You describe what should happen; the server enforces it.

Player-vs-player (PvP)

By default a Weapon can damage world objects (barrels, targets, breakables) but never another player — so a weapon prop can't grief a social world. To let players damage each other, enable PvP for the world:

  • No-code: tick Allow Pvp on the WorldDescriptor (under Players).
  • From a script: Combat.SetPvpEnabled(true) — handy for turning PvP on only during a match round, an arena, or a timed event; Combat.IsPvpEnabled() reads the current state. See the Combat API.

With PvP on, weapon fire can damage players, and the server still validates fire rate, range, and aim on every shot. With it off, those shots simply don't reach players (world objects still take the hit).

Scripted damage isn't gated by PvP

Combat.ApplyDamage, Combat.Kill, and Combat.ApplyRadiusDamage are authoritative — a creator script that calls them can always affect players (it's your world's rules). The PvP switch specifically gates the weapon path, so a placed weapon can't hurt players unless you opt in.

Checkpoints & respawn point

Every player has a respawn point (checkpoint), which starts at wherever they first spawned. It's server-authoritative, and every respawn — death, a safe fall, or a manual reset — sends the player there.

The Set Respawn Point action reuses the same Destination transform field as Teleport — point it at the spot you want to become the new checkpoint (a room entrance, the top of a level).

These actions act on the triggering player

Respawn and Set Respawn Point affect only the player who set off the entry, so use them from client-local triggers — a zone, a key press, or an interact — not from On player joined / On player left.

Falling out of the world

The WorldDescriptor's respawnHeight is a Y line (default -100) that catches players who fall off the map. It's an always-on safety net — a fall through the floor or off the edge can never drop forever — so with zero setup, a player who crosses below it is returned to their checkpoint.

Building an intentional deep drop? Lower respawnHeight.

Because the net is always on, a skydive, a bottomless-pit gag, or a deep canyon will yank players back at y = -100 unless you set respawnHeight lower on the World Descriptor. It's an editable Y value, not an on/off switch — lower it below your deepest intended fall.

What crossing the line does — a plain reset or a death — is the Height Respawn Mode, set with the Set Height-Respawn action (or Player.SetHeightRespawn):

Mode Crossing the respawn-height line…
Off (default) Resets the player to their checkpoint — no death, no ragdoll. ("Off" does not disable the net — it behaves exactly like Safe respawn; to fall further, lower respawnHeight.)
Safe respawn Resets the player to their checkpoint — no death, no ragdoll (identical to Off).
Death The player dies (ragdoll), then respawns at their checkpoint.

Pick Death when falling off should count as a kill; otherwise the default safe reset is what you want.

  • Enemies — reactive combat NPCs that deal (and take) this damage, no scripting.
  • World Triggers & Logic — the conditions and actions SSHealth reuses.
  • World Objects — placing and networking the objects you give health to.
  • Worlds — the WorldDescriptor and spawn setup.
  • Combat API — dealing damage, healing, and reading health from a script.
  • Player API — Player.Respawn, SetRespawnPoint, and SetHeightRespawn.

Component class names (for scripts and search): SSHealth, SSEnemy (enemies page), weapon components under SDK/Components/Weapons/.