Every node, explained

Fires on the server whenever an infected or an animal dies. It rides EEKilled on the two gameplay base classes every creature in DayZ inherits from — ZombieBase for all infected, AnimalBase for all animals — because the shared engine class underneath them cannot be modded at all. A creature is only ever one or the other, so the event fires exactly once per kill.

Killer resolution works the same way as it does for players: the engine hands over the source of the death, which for a shooting is the weapon rather than the shooter, and the node walks up to the player holding it. Anything that is not a player — a bear mauling a wolf, a car, a landmine, fall damage — leaves Killer empty.

When to use it

Bounties, hunting rewards, horde-clearing objectives, loot drops on death, kill counters for a leaderboard. This node never fires for players; use On Player Died for those.

Pins

Creature — the dead body as an entity, not a player. Feed it to Get Entity Position to spawn something where it fell, or to Delete Entity to clean it up.

Killer — the player responsible, or empty. Test with Is Valid before paying out, or environmental deaths quietly reward nobody.

Type — the creature's classname, for example ZmbM_CitizenASkinny or Animal_UrsusArctos. This is how you tell a chicken from a bear.

Example

A bounty that pays more for the dangerous ones: On Creature Killed → Is Valid (Killer) → Branch. The True arm runs Switch On Text on the Type with Match 1 set to Animal_UrsusArctos. Case 1 adds 50 to the Killer's saved bounty with Add To Saved Player Number and the Default path adds 5, and each of those two paths ends in its own Send Notification built from Get Saved Player Number (bounty) → Join Text ("Bounty: " + total). Keep the two paths separate rather than wiring them back into one shared notification — converging exec wires make the compiler copy everything downstream under both.

To drop loot where it fell, wire the Creature into Get Entity Position and that into Spawn Item (Ammo_762x39) on the same arm.

Watch out

• Classnames are exact and case-sensitive, and infected classnames are long and

fiddly (ZmbM_CitizenASkinny, ZmbF_JournalistNormal). Get one wrong and the test never matches. When you only need "was it an animal", it is safer to check the Killer and the position than to guess at name spellings.

• Killer is empty for every death a player did not cause — infected fighting

each other, animals, vehicles, the environment. Always guard the reward with Is Valid.

• The Creature pin is an entity, not a player. Player-only nodes will not

accept it; use the entity nodes (Get Entity Position, Get Entity Type, Get Entity Health) on it.

• Infected die constantly on a busy server. Keep the chain short, and avoid

broadcasting to everyone on every kill.

• Server-side only. A kill counter drawn on the killer's own screen has to

travel through Send Client Message into On Client Message in a Server + Client project.

Fires whenever what a player is holding changes. Drawing a rifle, swapping to a bandage, putting a can down, emptying the hands entirely — all of them come through here, with the player and whatever is in their hands *now*.

That last word matters. The Item pin is the new contents of the hands, not the thing that left them, so putting your hands away fires the event with an empty Item. One event covers both "picked something up" and "put it away", and telling them apart is a Is Valid check on Item.

It runs on the server, so a mod using it needs no install on players' machines.

When to use it

Reacting to what someone is holding: warning when a weapon comes out in a safe zone, showing a hint the first time a special item reaches the hands, logging weapon draws. It is not a pickup event — moving an item from a backpack into a vest never touches the hands, and never fires this. For gear being worn, On Item Attached and On Item Detached. To read the hands on demand instead of reacting, Get Item In Hands.

Pins

Item — what is held now, or empty when the hands were just cleared. Always test with Is Valid before using it. It is a live item, not a classname — use Get Entity Type for that.

Example

Telling a player what they just drew: On Held Item Changed → Is Valid (Item) → Branch. True → Get Display Name (Item) → Join Text with "Now holding: " → Send Chat Message to the event's Player. False is left unwired, because empty hands need no announcement.

For a rule rather than a hint, replace the tail: Get Entity Type (Item) → Switch On Text (Match 1 "M4A1") → Case 1 → Send Notification ("Safe Zone", "Weapons are not allowed here.").

Watch out

• Empty hands are normal, not an error. Wire Is Valid on Item before anything reads it, or the chain quietly runs on nothing every time somebody holsters.
• This fires a lot — every swap, every draw, every holster, for every player. Keep the work under it small. A big loop or a chain of Delay waits hung off it multiplies fast on a busy server.
• Your own graph triggers it. Anything Give Weapon or Give Item To Player puts into the hands fires this event, so a chain that reacts by giving something else can chase itself. Guard it.
• It fires as a character spawns in and their starting gear settles, so "held something" is not the same as "chose to hold something".
• Classnames are case-sensitive when you compare them: "M4A1", not "m4a1".

Fires when a player puts something on. It rides the player's own attachment hook — the same notification the game itself uses to react to gear appearing in a slot — so you get the player, the item that arrived, and the name of the slot it went into.

Attachment is a specific idea in DayZ, and it is narrower than "picked up". A jacket going onto the body, a backpack onto the back, a plate into a vest: those are attachments and they fire this. A can of beans dropped into that backpack is cargo, not an attachment, and never touches this event.

Everything here runs on the server, so a mod built from it works without players installing anything.

When to use it

Reacting the moment gear changes: sealing a suit when the mask goes on, banning a piece of clothing in a safe zone, logging who equipped what. To react to it coming off again, On Item Detached. For what is in the hands rather than worn, On Held Item Changed. And when you want to *ask* what is worn right now rather than be told when it changes, Get Attachment In Slot reads a slot on demand.

Pins

Item — the live item, not its classname. Read the classname with Get Entity Type, or a readable label with Get Display Name.

Slot — the engine's own name for the attachment point, as text. Slot names are exact and case-sensitive.

Example

Confirming a mask went on: On Item Attached → Get Entity Type (Item) → Switch On Text (Match 1 "GasMask") → Case 1 → Send Notification ("Filter Engaged", "Your mask is sealed.") with the event's Player wired in so only that person sees it. Default is left unwired, so every other piece of gear passes through silently.

Watch out

• Slot names are exact and case-sensitive, and an unrecognised one simply never matches — nothing warns you. If you are unsure of a name, wire Slot straight into Log Message once, put the item on in game, and read it out of the server log.
• Worn is not the same as carried. This event only fires when something lands in a slot, so a gasmask stuffed in a backpack never trips it — and never protects anyone either. To search the whole inventory instead, use Has Item In Inventory or Find Item On Player.
• Your own graph trips it too. Anything equipped by Equip Item On Player, Attach New Item or Give Weapon fires this event exactly like a player's own action, so a chain that reacts by equipping something else can chase its own tail. Guard it with a check, or with Do Once.
• Classnames are case-sensitive when you compare them: "GasMask", not "Gasmask".
• It fires during spawn-in as the character's starting gear is put on, so "on attach" is not the same as "the player chose to wear this".

The mirror of On Item Attached: it fires when something leaves one of the player's attachment slots. You get the player, the item that came off, and the name of the slot it left. As with attaching, this is about slots only — pulling a can of beans out of a backpack is a cargo move and does not fire it.

It runs on the server, so nothing needs installing on players' machines.

When to use it

Undoing whatever you granted when the gear went on, and catching people taking off something your rules require. Pair it with On Item Attached and match on the same Slot name from both. To read what is worn at a given moment instead of reacting to a change, use Get Attachment In Slot.

Pins

Item — the live item that was removed. It still exists; it just is not in that slot any more. Read its classname with Get Entity Type.

Slot — the attachment point it left, exact and case-sensitive.

Example

Warning a player who takes their mask off in a bad place: On Item Detached → Get Entity Type (Item) → Text Equals ("GasMask") → Branch → True → Send Notification ("Mask Off", "You are breathing the air here.") with the event's Player, and Give Disease if you want teeth behind the warning.

Watch out

• Where the item went next is not reported, and is not settled at the moment this fires. Do not assume it landed in hands, in a bag, or on the ground — if that matters, check later with Get Item Container rather than reading it here.
• Your own graph fires it as well. Clear Inventory, Remove Items Of Type and Delete Entity all pull gear out of slots, so a chain that reacts to a removal by handing the item back can loop endlessly. Gate it.
• Slot names are exact and case-sensitive; a typo matches nothing and reports nothing. Log the Slot once in game to confirm the spelling.
• Classnames are case-sensitive too: "GasMask", not "Gasmask".
• Removing something is not the same as losing it. A player swapping one jacket for another fires this and then On Item Attached within the same breath, so "took their armour off" and "changed armour" look identical unless you check what went on afterwards.

The same generated "F" prompt as On Press Interaction, but the player has to hold the key down. A progress bar fills for the number of seconds you set, and only when it fills does the flow below run — this is the shape vanilla uses for searching a wreck or dismantling a fence. Let go early, walk away, or take a hit, and the action cancels with nothing run at all.

The prompt lives on the player's machine, so this event needs a "Server + Client" project and players who have the mod. The flow underneath still runs on the server, so server nodes work under it normally.

When to use it

Anything that should feel like work: searching a stash, looting a special container, activating a beacon. The wait is also the balance knob — five seconds standing still in the open is a real cost. For an instant press, use On Press Interaction. To act on the item in the player's hands instead, use On Hold Item Action.

Pins

Show When — optional true/false that decides whether the prompt is offered at all. Checked while the player is looking at the object, so it can only read the Player, the Target and value nodes.

Target — the object they searched, as a plain world object. Feed it through As Item before wiring it into anything that wants an item or entity; that is empty for objects that are not items.

Hold Seconds — how long the bar takes. The player is locked in a full-body animation for the whole time, so keep it in the seconds, not the minutes.

Example

A searchable sea chest that restocks itself: On Hold Interaction (Object Class SeaChest, Prompt Text "Search", Hold Seconds 5) → As Item on Target → Spawn Item In Cargo (Container = that item, Item Class Rag) → Send Notification ("Search", "You found a rag").

Feeding the chest through As Item is the part people miss: Target is a world object, and the Container pin wants an entity. Add a Show When of Get Item In Hands → Is Item Of Type (Item Class Screwdriver) and the prompt only offers itself to players carrying a tool in hand.

Watch out

• The object class must match exactly — the world variants compare the object's own type, so Barrel_Green does not cover Barrel_Red. Only the held-item versions match subtypes.
• Classnames are case-sensitive.
• Cancelling runs nothing. There is no "started" path, so a graph cannot charge a fee up front and refund it.
• Players need the mod; a "Server only" project rejects this node and players without the client half never see the prompt.
• The prompt appears only while standing or crouching and looking at the object from normal use range. Prone players get nothing.
• Show When is evaluated on the player's machine, where server memory does not exist — Get Global Number, Get Saved Number and Get Player Number read as their starting value there. Use it to hide the prompt from people who obviously cannot use it, and enforce the real rule below with Branch.
• A long hold on a container players can also open normally is a race: they can open the chest by hand while your bar is filling.

The held-item action with a timer on it. While the player holds an item of the class you name, your prompt appears; holding the key fills a progress bar for the seconds you set, and only a completed bar runs the flow below. Releasing early, moving off, or being interrupted cancels it and nothing happens.

Like On Press Item Action it works on the item in their hands, and the Item output is that item, item-typed and ready for the item nodes. Like every interaction node it draws a prompt on the player's screen, so it needs a "Server + Client" project and players who have the mod; the flow underneath still runs on the server.

When to use it

Anything that should read as effort or craft: field-stripping a weapon, brewing something, converting one item into another. The hold time is your balance knob, and the cancel-on-interrupt behaviour means it cannot be done mid-fight. For an instant use, On Press Item Action. For a prompt on a placed object instead of a held item, On Hold Interaction.

Pins

Show When — optional true/false that decides whether the prompt is offered at all. Checked while the item is in hand, so it can read the Player, the Item and value nodes on them.

Item — the held item, item-typed.

Hold Seconds — how long the bar takes. The player is locked in the animation for the whole time; a few seconds reads as work, half a minute reads as a bug.

Example

Tearing a rag into a proper bandage: On Hold Item Action (Item Class Rag, Prompt Text "Make bandage", Hold Seconds 3) → Remove Items Of Type (Container = Player, Item Class Rag, How Many 1) → Give Item To Player (BandageDressing, Player) → Send Notification ("Crafted", "You made a bandage").

The Player pin takes the event's Player straight into the Container pin — a player is an entity, and Remove Items Of Type searches their whole inventory. Take the ingredient first and hand out the result second, so a full inventory cannot leave the player with both.

Watch out

• Subtypes match. The class you name catches everything descended from it, so choose the leaf class when only one variant should qualify.
• Classnames are case-sensitive.
• Cancelling runs nothing at all — there is no "started" path, so you cannot take payment up front.
• Hands only: an item in a bag or a pocket offers no prompt.
• Players need the mod; a "Server only" project rejects this node.
• Show When is checked on the player's machine, where server-side memory does not exist — Get Global Number, Get Saved Number and Get Player Number read as their starting value there. Hide the prompt with client-visible facts, then re-check the real rule below with Branch.
• The held item is not consumed for you. Remove or change it in the flow if the action is meant to use it up.

Adds a brand-new "press F" prompt to a world object. NodeZ writes a real DayZ user action for it and registers it on every player — the same mechanism vanilla uses for opening a door. When a player looks at an object of the class you name, your prompt appears; one press and the flow below runs.

The prompt has to be drawn on the player's own machine, so this event only exists in a "Server + Client" project: players must have the mod. The work underneath still runs on the server, so anything you wire below — giving items, spawning, saving numbers — behaves exactly as it does under an ordinary server event.

When to use it

Instant use of something placed in the world: a supply barrel, a shrine, a wall panel. When the action should take time and show a progress bar, use On Hold Interaction. When you want to act on the item in the player's hands rather than on something in the world, use On Press Item Action or On Hold Item Action. If all you need is "a player reached this place", Player Entered Zone does that with no client install at all.

Pins

Show When — optional. Wire any true/false value and the prompt only appears while it is true. It is re-checked while the player looks at the object, so it can only use what exists at that moment: the Player, the Target, and value nodes reading them.

Target — the object they used, as a plain world object. Item and container nodes want an item or an entity, so pass it through As Item first. That comes back empty for anything that is not an item — a building or a fence never is.

Object Class — the exact class of the object, from the panel picker. Prompt Text — the words shown beside the key.

Example

A resupply barrel: On Press Interaction (Object Class Barrel_Green, Prompt Text "Take supplies") → Give Item To Player (BandageDressing, Player wired from the event) → Send Notification ("Supplies", "You took a bandage").

To show the prompt only to players holding a Rag, wire Get Item In Hands (Player) → Is Item Of Type (Item Class Rag) into Show When. That only hides the prompt, so repeat the same check below with Branch when the rule must actually be enforced.

Watch out

• The object class must match exactly. Unlike the held-item versions, the world ones compare the object's own type, so subtypes do not count: a graph aimed at Barrel_Green ignores Barrel_Red.
• Classnames are case-sensitive, here as everywhere.
• Players need the mod installed. A "Server only" project rejects this node, and players without the client half simply never see the prompt.
• The prompt appears only while standing or crouching and looking at the object from normal use range. A prone player gets nothing.
• Show When is evaluated on the player's machine, where server-side memory does not exist. Get Global Number, Get Saved Number and Get Player Number read as their starting value there, so a condition built on them will not do what you expect. Test what the player's own machine can see and enforce the rest in the flow below.
• Several interaction nodes aimed at the same class each add their own prompt; they stack in the list rather than replacing one another.

Gives an item a new use. While the player is holding an item of the class you name, your prompt appears with the other action prompts; one press and the flow below runs. This is the shape vanilla uses for the small in-hands actions — emptying a seed pack, breaking a stick — and NodeZ generates one of those actions per node.

It fires on the item in their hands, not on anything in the world and not on what is in their pockets. The Item output is that held item, ready to wire straight into item nodes.

When to use it

Turning an ordinary item into a tool of your own: a radio that calls a heli, a can that trades for a reward, a map piece that reveals a location. When the use should take time and show a progress bar, use On Hold Item Action. When the prompt belongs on something placed in the world instead, use On Press Interaction. To react to an item being consumed the normal way, On Player Consumed already exists — you do not need an action for that.

Pins

Show When — optional true/false deciding whether the prompt is offered. Checked while the item is in hand, so it can read the Player, the Item, and value nodes on them.

Item — the held item. This one is item-typed, so it feeds Set Item Quantity, Set Item Health and the rest directly, with no conversion.

Item Class — the class the prompt attaches to. Prompt Text — the words shown beside the key.

Example

A canteen you can purify by hand: On Press Item Action (Item Class Canteen, Prompt Text "Purify") → Set Container Liquid (Container = the event's Item, Liquid "Clean Water") → Send Notification ("Purified", "The water is safe to drink").

Add a Show When of Get Container Liquid on the Item → Text Equals ("Water") and the prompt only appears when there is dirty water in there to clean.

Watch out

• Subtypes match here. The held-item versions accept anything descended from the class you name, so a base class catches every variant. Pick the exact leaf class when you want only one.
• Classnames are case-sensitive.
• Players need the mod. The node is rejected in a "Server only" project, and players without the client half never see the prompt.
• Hands only. An item in a backpack or a pocket has no prompt — that is the same worn-versus-carried split you meet with Find Item On Player.
• The prompt shows while standing or crouching; a prone player gets nothing.
• Show When runs on the player's machine, where server-side memory is not filled in: Get Global Number, Get Saved Number and Get Player Number all read as their starting value there. Hide the prompt with what the client can see, then re-check the real rule below with Branch.
• The prompt does not consume anything by itself. If the item is meant to be used up, delete it yourself with Remove Items Of Type or Delete Entity in the flow.

The receiving half of NodeZ's server-to-client radio. The server raises a named message with Broadcast Client Message (everyone) or Send Client Message (one player), and every On Client Message node listening for that exact name fires on the player's own machine with the payload on its pins.

This is what makes a HUD possible. Almost everything worth showing — who just died, the score, how long the round has left — is known only to the server, while every HUD node draws on the player's client. The payload is a fixed envelope: three texts, two numbers, one on/off flag. Wire the slots you need and the rest arrive blank. Only plain values cross the wire, so when the client needs to know about a player, send their name or Steam ID as text.

When to use it

Every client-side reaction to something the server decided: killfeeds, scoreboards, round timers, warning banners, showing and hiding an overlay. Under it you can use the whole HUD family — Show HUD Overlay, Add Widget From Layout, Set Text — which is client-only and cannot run under a server event at all. To put a line of text in front of a player without building UI, Send Notification does that from the server with no client half.

Pins

Message — the name to listen for, matched exactly against the name the sender used. Case and spacing matter and a mismatch is silent, so the editor warns when a Broadcast or Send names something nothing listens for.

Text 1-3 / Number 1-2 / On / Off — the envelope. Give each slot a job and keep sender and receiver in step; nothing labels them for you.

There is no Player pin and none is needed: the handler runs on the receiving player's own machine, so "the player" is always whoever is looking at the screen.

Example

A killfeed. On the server: On Player Died → Is Valid (Killer) → Branch; on True, Broadcast Client Message named "kill", with Text 1 = Get Player Name (Killer) and Text 2 = Get Player Name (Victim).

On the client: On Client Message ("kill") → Show HUD Overlay (your killfeed layout) → Scale For Screen on the Root → Add Widget From Layout (a row layout) into that Root → Find Child Widget ("line") → Set Text with Join Text of Text 1, " killed ", Text 2 → Auto-Destroy Widget After (8 seconds). Every client builds its own copy of the line from the strings it received.

Watch out

• This is a client node: the project must be set to "Server + Client" in Project Settings and players must have the mod installed. A server-only install runs the server half happily and the HUD is simply never there — no error, no clue.
• Sender and receiver are matched by name only, so renaming one side quietly kills the feature. The editor's "nothing listens for this" warning is the safety net.
• Every listener with a matching name fires, on every client that received the message. Use Send Client Message when only one player should react.
• Server-side values cannot be read here. Saved numbers (Get Saved Number, Get Saved Player Number) live in a file on the server and read back 0 on a client — put the number in the envelope instead.
• HUD sizes are real screen pixels and layouts are drawn for 1080p, so run Scale For Screen immediately after showing an overlay or adding a widget, and set text before measuring with Fit Widget To Text.

Fires on the server when someone finishes injecting an item — into themselves or into another player. It rides OnApply on ItemBase, the call vanilla's inject actions make once the needle has gone in, so it covers Morphine, Epinephrine and AntiChemInjector, plus any modded item that uses the same injectable action.

Read the Player pin as "who received the dose". For a self-injection that is the person holding the syringe; for a rescue injection it is the patient, not the medic. The node does not tell you who administered it.

When to use it

Custom medical effects — an epinephrine shot that also stops bleeding, morphine that costs stamina, an anti-chem injector that clears a stack of your own status flags. Eating and drinking do not come through here; that is On Player Consumed. Bandages, splints and other applied-but-not-injected items are not on this hook either.

Pins

Item — the injector that was used. One event covers every injectable, so this is how you tell them apart: Get Entity Type gives the classname, or Is Item Of Type tests it directly.

Player — who received it.

Example

Make epinephrine do more: On Item Injected → Is Item Of Type (Item, "Epinephrine") → Branch. The True arm runs Stop All Bleeding on the Player, Set Player Stamina (100), and Send Notification ("Adrenaline", "Your heart is racing.", 6 seconds) aimed at the Player.

Charging for the shot is the same shape with Branch reversed: check Get Player Number for a cooldown you set with Set Player Number, and only apply the bonus when it has expired.

Watch out

• Classnames are exact and case-sensitive — "Epinephrine", not "epinephrine",

"AntiChemInjector" with that capitalisation. A wrong-case compare simply never matches, silently and forever.

• The event fires after the vanilla effect has been applied, so your changes sit

on top of what the injection already did. Setting health or stamina here overwrites the engine's own result rather than adding to it.

• Server-side. To put something on the injected player's screen, send it with

Send Client Message and draw it under On Client Message in a Server + Client project.

• The injector is generally used up by the action, so the Item is not a handle

worth keeping. Read what you need from it inside this chain rather than stashing it with Remember Item, which reads back empty once the item is gone.

Fires on the server the moment a player's character has been created and loaded into the world. It rides the same vanilla hook the server uses to announce a finished connection (InvokeOnConnect in MissionServer), so it covers both a brand-new character and a returning one — and it fires again right after a respawn creates the new character.

Think of it as "a character just arrived", not "a person just clicked Join". The character exists and the Player pin is live, but the client may still be on the loading screen.

When to use it

Connect logging, welcome messages, and per-player bookkeeping that should run as early as possible. For anything that physically touches the character — giving items, teleporting, healing — prefer On Player Ready, which fires a little later at the guaranteed-safe point, or put a short Delay after this event. Use On Player Respawned when you care about the respawn *decision* itself, and On Player Left / On Player Disconnecting for the way out.

Pins

Player — the character that just arrived. Everything downstream hangs off this.

Identity — the engine's network identity record for the connection. Almost every graph only needs Player; values like name and Steam ID come from Get Player Name and Get Player Steam ID on the Player pin.

Example

The simplest form is two nodes: On Player Connected → Send Notification ("Welcome!", "This server runs NodeZ", 10 seconds), with the event's Player wired into the notification so only the arriving player sees it. The server-log version is the same shape — On Player Connected → Get Player Name → Join Text ("joined: " + name) → Log Message.

The full treatment splits the work: On Player Connected → Sequence. Then 0 compares the player's saved round_id against the server's saved current_round_id and, when they differ, zeroes their round_kills and round_deaths — so stats reset once per round, not on every reconnect. Then 1 runs Delay (2 seconds, carrying the Player) → the loadout hand-out, which is only safe once the client has finished loading. The bookkeeping lands instantly, the kit waits.

Watch out

• This event fires again after every respawn, because a respawn creates a new

character. Anything meant to happen once per visit needs its own gate — the saved round id above is one way; a per-player flag via Set Player Number also works.

• Don't equip or teleport the character directly under this event. The client

can still be loading; wait with Delay (about 2 seconds) or use On Player Ready instead.

• After a Delay, only the carried Player survives into the Then path.

Re-derive everything else from it.

Fires on the server when a player eats or drinks. It rides Consume on PlayerBase — the single call every vanilla eat and drink action funnels through — so canned food, fruit, cooked steak, a canteen, a soda and a mouthful of pond water all arrive here.

The node runs after the engine has already applied the food or water, and it hands the original result straight back, so vanilla nutrition is untouched. Your chain is an addition on top, not a replacement.

When to use it

Custom food effects — a can of beans that also warms you up, alcohol that blurs a stat, poisoned water in one region. Injections are a different hook: use On Item Injected for Morphine, Epinephrine and AntiChemInjector.

Pins

Item — what was consumed. Empty when the player drank straight from a pond, a well or snow, because there is no item involved — check with Is Valid before reading it. Otherwise Get Entity Type or Is Item Of Type tells you which food it was.

Amount — how much the engine took in that consume step, in the item's own quantity units. A long drink reports its own amount; it is not a percentage and not the item's remaining quantity (Get Item Quantity gives that).

Example

Unsafe pond water: On Player Consumed → Is Valid (Item) → Not → Branch. The True arm — nothing consumed, so it was a pond, a well or snow — runs Random Chance (25 %) → a second Branch → Give Disease (Cholera, Strength 150) on the Player and Send Notification ("That tasted wrong", "You should have boiled it.", 6 seconds).

A warming meal is the mirror image: Is Item Of Type (Item, "BakedBeansCan") → Branch → Give Energy on the Player.

Watch out

• Classnames are exact and case-sensitive: "BakedBeansCan", not

"bakedbeanscan". A wrong-case test never matches and never complains.

• Item is empty for drinking from the world, and that is a normal case, not an

error. Always guard with Is Valid before feeding it into Get Entity Type or an item node.

• Eating and drinking is a repeating action, so expect this event more than once

per item rather than once per meal. Keep the chain cheap, and if something should happen only once, latch it with Do Once or a marker set by Set Player Number.

• Server-side. Anything that has to appear on the eater's own screen goes

through Send Client Message into On Client Message in a Server + Client project.

Fires on the server the moment a player's character is killed. It rides EEKilled on PlayerBase — the engine's own death notification, the same one vanilla's admin log listens to — so it covers every death: shot, beaten, mauled, starved, fallen.

The Killer pin does real work for you. What the engine hands over is the *source object*, and for a shooting that object is the weapon, not the person. The node walks up from the source to whoever is holding it, falls back to the source itself when there is no weapon in the way (fists, a vehicle), and then blanks the result if it turns out to be the victim. So Killer is only ever another player — never the gun, never the victim themselves.

When to use it

Killfeeds, kill rewards, death penalties, scoreboards, drop-on-death rules. For infected and animals use On Creature Killed; that is a separate hook and this node never fires for them. For the hits leading up to the death — or to build a last-attacker record — use On Player Took Damage. To react to the player coming back, use On Player Respawned.

Pins

Victim — the character that just died. Always valid.

Killer — the other player responsible, or empty. Always test it with Is Valid before you read a name or hand out a reward.

Example

Reward the killer and tell them who they got: On Player Died → Is Valid (Killer) → Branch. The True arm runs Give Item To Player (Rag) aimed at the Killer, while Get Player Name on the Victim goes through Join Text ("You killed " + the name) into the detail of a Send Notification sent to the Killer. That wiring is the Kill reward template (File → New from template) if you would rather start from it than build it.

For a persistent scoreboard, add Add To Saved Player Number on the Killer ("kills" + 1) in the same True arm, and Add To Saved Player Number on the Victim ("deaths" + 1) outside the branch, so deaths count even when nobody killed them.

Watch out

• Plenty of deaths have no killer: bleeding out, falls, starvation, infected,

animals, and respawning from the menu. The Killer pin is also deliberately emptied for self-inflicted deaths. Guard the reward arm with Is Valid, or you hand items to nobody.

• If credit still matters for those deaths, keep your own record — under

On Player Took Damage stamp the attacker's Steam ID onto the victim with Set Player Text, and read it back here with Get Player Text.

• Headshot flair belongs to Was Killed By Headshot on the Victim, and the engine

only sets that flag for the "Brain" damage zone — a graze across the head model does not count.

• Values stamped on a character with Set Player Number /

Set Player Text live on that character object. The respawn builds a new one, so a kill streak kept that way resets on death by design; use Add To Saved Player Number when it must survive death and restarts.

• The corpse stays in the world for a while and still counts as a player, so

For Each Player and For Each Player Near will visit it. Gate those loops with Is Player Alive when a body must not take part.

Fires on the server the instant a logout begins — the player has hit Disconnect, the countdown has started, and the character is still standing in the world. It rides OnClientDisconnectedEvent in MissionServer, which vanilla raises before the character is saved.

That is the difference between this node and On Player Left. Here the body is still real: you can damage it, move it, strip it, or note exactly where it stood. By the time On Player Left runs, the player is gone and only bookkeeping is left.

When to use it

Combat-logging rules (kill or punish a player who quits during a fight), saving a logout position, dropping quest items back on the ground, clearing a "player is in the arena" slot while the character can still be found. Use On Player Left for plain leave logging and totals.

Pins

Player — the character, still in the world and still safe to act on.

Identity — the connection's network record. Names and Steam IDs are easier from Get Player Name / Get Player Steam ID on the Player pin.

Example

Punish a combat log: On Player Disconnecting → Get Player Number (Player, in_combat) → Greater Than (B = 0) → Branch, and on the True arm Kill Entity on the Player plus Get Player Name → Join Text ("combat logged: " + name) → Log Message. The in_combat marker is set over in the damage graph — On Player Took Damage → Set Player Number (Victim, in_combat = 1).

Watch out

• Fires at the START of the logout, so the player may still cancel and stay. If

your reaction is destructive, be sure that is what you want — vanilla gives them a countdown, this event does not wait for it.

• Do not park a Delay here hoping to act later. The wait outlives the

connection, and the continuation stops on its own once the carried player is gone.

• Messages aimed at the leaving client (Send Notification,

Send Client Message) may never be seen — the connection is closing. Log it instead with Log Message or Write To Log File.

• Session values on the character (Set Player Number /

Set Player Text) die with it. Copy anything worth keeping into a saved value here with Set Saved Player Number.

Fires on the server the moment a player drops unconscious. It rides OnUnconsciousStart on PlayerBase, so it covers every cause the engine recognises — a blow to the head, blood loss, shock, overdose — and fires once per blackout, not repeatedly while they are down.

When to use it

Rescue mechanics, downed-player markers, an admin log of who went down where, or a rule that a knocked-out player drops what they were holding. Pair it with On Player Woke Up for anything that has to be undone on recovery. To knock someone out from a graph rather than react to it, use Knock Out Player; to ask whether a player is down right now, use Is Player Unconscious.

Example

Call for help: On Player Knocked Out → Get Player Name → Join Text ("Player down: " + name) → Broadcast Notification ("Medic!", the joined text, 10 seconds), with Get Player Position → Join Text into Log Message on a second wire so admins can find the body.

Watch out

• Unconscious is not dead. Players wake up on their own, and this event fires

again the next time they go down — anything meant to happen once needs a latch such as Do Once or a marker set with Set Player Number.

• A knockout often runs straight into a death. Work started here with a

Delay may find the carried player gone; the continuation stops quietly when that happens.

• Server-side, so HUD nodes cannot hang off it. A blackout overlay on the

player's own screen has to travel through Send Client Message into On Client Message in a Server + Client project.

Fires on the server at the very end of a logout, when the player has finished leaving. It rides InvokeOnDisconnect in MissionServer — the vanilla point just before the character is written to storage — and it is the last moment your graph ever sees that player.

There are two ways out of a server and NodeZ gives you both. On Player Disconnecting fires at the *start* of the logout, while the player is still standing in the world; this one fires at the end, once they are gone. Pick by whether you need to touch the character (use the other one) or just to record that they left (use this one).

When to use it

Leave logging, session bookkeeping, writing a play-time total to a saved value, clearing a global that tracked "who is in the arena". For combat-logging rules — killing or punishing someone who quits mid-fight — use On Player Disconnecting instead; by the time this event runs it is too late to act on the body.

Pins

Player — the departing character. Still readable, but on its way out: read what you need immediately rather than after a Delay.

Example

Record the session: On Player Left → Get Player Name → Join Text ("left: " + name) → Log Message, with a second wire from the event into Add To Saved Player Number ("sessions" + 1) so the count survives a restart.

Watch out

• The connection is already tearing down, so anything that needs the player's

network identity can come up empty here. Nodes that message a client — Send Notification, Send Chat Message, Send Client Message — have nobody left to talk to.

• Do not put a Delay between this event and your work. The continuation

checks that the carried player still exists and quietly stops when they do not, which after a logout is exactly what happens.

• Session values written with Set Player Number /

Set Player Text vanish with the character. If a running total should survive the logout, write it here with Add To Saved Player Number.

Fires on the server once a player's client has finished loading and the character is actually in the game. It rides OnClientReadyEvent in MissionServer — vanilla's own "this player is now playing" signal — which comes a little later than On Player Connected.

That later timing is the whole point of the node. Under On Player Connected the character exists but the client can still be sitting on the loading screen, so gear handed over then may never reach it. Here the client is caught up, and it is safe to touch the character directly: give items, teleport, heal.

When to use it

Spawn kits, starting loadouts, moving arrivals to a lobby — anything the player must actually see on their body or their screen. Use On Player Connected instead for bookkeeping you want as early as possible (logging a join, reading saved stats), and On Player Respawned when you care about the respawn decision rather than the arrival.

Pins

Player — the loaded character. Everything downstream hangs off this pin.

Identity — the engine's network record for the connection. Most graphs never touch it; a name or Steam ID is easier from Get Player Name and Get Player Steam ID on the Player pin.

Example

A starter kit in one chain: On Player Ready → Clear Inventory → Give Weapon (M4A1 with Mag_STANAG_30Rnd) → Give Item To Player (BandageDressing) → Delay (2 seconds, carrying the Player) → Set Quick Bar Slot with the rifle found again by Find Item On Player ("M4A1") into slot 1. The wait is there because the quick bar points at an item on the player's own machine, and the client needs a moment to receive what you just created.

Watch out

• This event runs on the server, so client-only nodes — everything hud* —

cannot hang off it. To paint something on the arriving player's screen, send them a message with Send Client Message and build the HUD under On Client Message; that also means the project must be set to Server + Client and players must have the mod.

• Teleporting and equipping in the same instant desyncs: the player looks naked

to everyone else. Put roughly 2 seconds of Delay between Teleport Player and the gear, and finish with Resync Player Gear.

• After a Delay only the carried Player survives into the continuation.

Re-derive anything else from it, or stamp it on the player first with Set Player Number / Set Player Text and read it back.

Fires on the server when a player clicks Respawn on the death screen and the engine builds them a fresh character. It rides OnClientRespawnEvent in MissionServer, so it is the respawn *decision* — the old body is already dead and the new one has just been created.

The Player pin is the new character, not the corpse. That matters more than it sounds: anything you stamped on the old character with Set Player Number or Set Player Text lived on that object and is gone. Only Set Saved Player Number and Set Global Number carry across.

When to use it

Fresh-spawn kits, moving new lives to a spawn point, resetting per-life counters, counting how many times someone has respawned. On Player Ready is the better home for gear on a normal join; On Player Connected fires here too, because a respawn creates a character, so put "once per life" work in one of these two events and not both.

Pins

Player — the newly created character.

Identity — the connection's network record. Rarely needed; names and Steam IDs come from Get Player Name / Get Player Steam ID on the Player pin.

Example

A respawn kit that lands where you want it: On Player Respawned → Add To Saved Player Number ("lives" + 1) → Delay (2 seconds, carrying the Player) → Teleport Player (7500 0 7500) → Delay (2 seconds) → Give Item To Player (BandageDressing) → Resync Player Gear. The first wait lets the new character settle, the second keeps the teleport and the gear apart.

Watch out

• The character has only just been created. Equipping or teleporting in the

same instant can leave the player looking naked to everyone else — wait about 2 seconds with Delay and finish with Resync Player Gear.

• Per-player session values do not survive respawn: they live on the character

object, and this is a new one. Use Set Saved Player Number for anything that must outlast a death.

• On Player Connected also fires just after this, so a graph that greets

players on connect will greet them again on every respawn unless you gate it.

• After a Delay only the carried Player survives — re-derive everything

else from it rather than trusting a global, which another player's respawn can overwrite while you wait.

Fires on the server every time damage lands on a player. It rides EEHitBy on PlayerBase, the engine's per-hit notification, so it covers bullets, melee, infected claws, animal bites, falls, fire and gas alike — one firing per hit, not one per fight.

Attacker resolution mirrors what the node does on death: the engine passes the *source* of the damage, which for a shooting is the weapon rather than the person, so the node takes the source when it is itself a player and otherwise walks up to whoever is carrying it. A source that resolves back to the victim is blanked, so self-inflicted damage leaves Attacker empty.

One hit drains three separate pools and the node reports all of them for the zone that was struck: Damage is health, Shock is the concussive load that puts people on the floor, and Blood Loss is what bleeds out. They move independently — a round stopped by a plate carrier can cost almost no health and still knock the wearer out on shock alone.

When to use it

Last-attacker records, safe-zone enforcement, armour or resistance effects, combat-logging timers, "you are being shot" warnings. Use On Player Died for the killing blow only — this node fires for every hit, including the fatal one.

Pins

Attacker — the other player who dealt it, or empty for infected, animals, the environment and anything self-inflicted. Check with Is Valid.

Damage — the health taken off by this one hit. It is not the player's remaining health; read that with Get Player Health. Hits that cost only shock or blood report 0 here.

Shock — the unconsciousness load from this hit. This is what body armour usually fails to stop, so a target that survives on health can still be dropped by it. Read the running level with Get Player Shock.

Blood Loss — blood taken by this hit, separate from the bleeding wound it may also open. Get Bleeding Wounds counts the wounds; this is the direct loss. Judge it against the pool a living player actually has: full is 5000 and the fatal line is 2500, so there are only 2500 points between healthy and dead — a few hundred per hit is a lot.

Ammo Type — the round or damage source that landed, spelled as the game names it: Bullet_762x39, Bullet_556x45, MeleeSoft, FallDamage. Exact casing, so compare with Text Equals. This is what tells one calibre from another when you are measuring what actually got through.

Hit Zone — the engine's name for the body part, such as "Head", "Brain", "Torso" or "LeftLeg". Exact spelling and casing, so compare it with Text Equals, not by eye.

Example

A last-attacker record, so a bleed-out can still be credited: On Player Took Damage → Is Valid (Attacker) → Branch, and on the True arm Get Player Steam ID (Attacker) → Set Player Text on the Victim under the name last_attacker. Over in the death graph, On Player Died reads it back with Get Player Text whenever its own Killer pin comes up empty.

A ballistics readout, for working out what a loadout actually stops: wire Hit Zone, Damage, Shock and Ammo Type through Join Text into Send Chat Message aimed at the Attacker. Every shot then prints what it hit, what it cost across all three pools, and which round did it — the four numbers you need to compare two sets of armour honestly.

A head-armour rule is the same shape: Text Equals (Hit Zone, "Head") → Branch → Get Attachment In Slot (Victim, "Headgear") → Is Valid → heal part of the hit back with Set Player Health.

Watch out

• This is the busiest event in the library. In a firefight it fires many times

a second, per player — a chain that loops over everyone online or sends a notification on every hit will drag the server down. Filter early with Branch and keep the work small.

• Attacker is empty far more often than people expect: infected, animals, falls

and gas all arrive with no attacker. Never wire it straight into a reward.

• Damage of 0 does not mean the hit did nothing. Check Shock and Blood Loss

before concluding armour stopped a round — very often it stopped the health damage and passed the shock straight through.

• Hit Zone strings are case-sensitive and are not the same list as the headshot

flag: the engine only counts "Brain" as a headshot (Was Killed By Headshot), so a "Head" hit here is not automatically a headshot.

• Server-side only. To flash something on the victim's screen, send a message

with Send Client Message and draw it under On Client Message in a Server + Client project.

Fires on the server when a player comes round after being unconscious. It rides OnUnconsciousStop on PlayerBase, the counterpart to the hook behind On Player Knocked Out, and it only fires for players who actually wake up — someone who dies while down never reaches it.

When to use it

Undoing whatever you did on the way down: clearing a downed marker, ending a rescue timer, giving a grace period of invulnerability, telling the player how long they were out. To wake someone up from a graph instead of reacting to it, use Wake Up Player.

Example

A short grace period on recovery: On Player Woke Up → Set Player Invulnerable (Invulnerable ticked) → Send Notification ("You are back", "Ten seconds to get to cover.", 8 seconds) → Delay (10 seconds, carrying the Player) → Set Player Invulnerable (unticked).

Watch out

• Pair it carefully with On Player Knocked Out: a player who is knocked out

and killed never wakes, so anything switched on down there must also be cleared under On Player Died or it stays on for that character's whole life.

• After a Delay only the carried Player survives into the continuation.

Re-derive anything else from it rather than reading a global, which another player's blackout can overwrite while you wait.

• Server-side, so a "you passed out" overlay must be sent to the client with

Send Client Message and drawn under On Client Message in a Server + Client project.

Fires exactly once, this many seconds after the server's mission starts, and then never again. It is the same scheduler the repeating timers use, set to run a single time.

The delay is the whole point. "The server started" is not the same as "the world is ready" — zones have to spawn, config has to load, the map has to settle. Giving your one-off setup twenty or thirty seconds of head start avoids a whole family of "it works when I trigger it by hand but not on boot" problems.

When to use it

One-time setup shortly after startup: placing props and stashes, seeding a counter, announcing a wipe. On Server Started is the instant version and runs while the mission is still being built — better for pure bookkeeping, worse for anything that touches the world. For work that repeats, Every N Seconds; for a particular time on the in-game clock, Daily At Time.

Pins

Delay (seconds) — read once when the timer is created, so it takes a typed number or a config value (Get Config Number) and nothing else. Anything computed at runtime is rejected by the generator with a message saying so.

Example

Laying out a stash the server should always have: After Delay On Start (30) → Spawn Item (SeaChest, Position "7500 0 7500") → Tag Item ("stash") → Remember Item ("stash"). Thirty seconds is ample for the world to be up. The tag is how a later sweep tells this crate from any other SeaChest (Get Item Tag); the remembered handle is how a timer graph finds it again without searching (Get Remembered Item).

A wipe announcement that actually gets read: After Delay On Start (120) → Broadcast Notification ("Fresh wipe — all stashes cleared"). At two minutes there are people online to see it; at zero seconds there are none.

Watch out

• Nobody is online at server start. A chain that expects a player finds none — For Each Player simply does nothing — so welcome messages belong on On Player Ready instead.
• It fires once per server *start*, which means once per restart. Something that must only ever happen once in the server's life needs a saved flag: check Get Saved Number first and write it after.
• The delay is measured from mission start, not from when the first player joins.

Fires once each in-game day, when the server's day/night clock reaches the hour and minute you set. In-game, not real-world: this is the same clock that decides whether it is dark outside, and it moves at whatever pace your server's time acceleration sets.

Underneath, the generated mod checks the clock once a minute. When the time is at or past your target and the event has not yet fired for that in-game day, the chain runs and the day is marked done. Two consequences are worth knowing. The fire lands within about a minute of the target rather than on the second. And if the server starts *after* the target time, the very first check fires it — roughly a minute after startup — and it then settles into once a day.

When to use it

Scheduled world events pinned to the game's day: a noon airdrop, a dusk horde, a 4 AM cleanup while nobody is around. When you want a fixed spacing in real time instead, use Every N Seconds — an in-game day can pass in an hour of real time on an accelerated server. For a single run after boot, After Delay On Start.

Hour and Minute are panel settings rather than pins: they are baked in when the mod is generated, so they cannot be driven from config or worked out at runtime. Hour is held to 0-23 and Minute to 0-59.

Example

A midday airdrop, announced before it lands: Daily At Time (Hour 12, Minute 0) → Broadcast Notification ("Airdrop inbound") → Random Config Position (your "dropSites" list) → Set Global Position ("drop") → Delay (60 seconds) → Get Global Position ("drop") → Spawn Item (SeaChest) → Tag Item ("drop").

Storing the rolled site before the wait is what makes it work: Random Config Position gives a different answer at every wired use, so reading it again after the delay would drop the crate somewhere other than the place just announced.

An overnight tidy-up is simpler: Daily At Time (Hour 4) → Delete Items In Radius around the arena.

Watch out

• The clock is the in-game one. Speed it up with Set Time Acceleration and this fires more often in real terms — a 16x server sees "daily" roughly every ninety minutes.
• Jumping the clock forward with Set Time Of Day past the target time triggers it, because the check only asks whether the clock is at or past the target on a day it has not yet handled.
• A server that restarts after the target time fires it again shortly after startup. On a server restarting every four hours, a "daily" reward pays out several times a day. Guard it with a saved value: run Get Server Date & Time, compare its Day against Get Saved Number ("last_day"), and only act when they differ.
• Nobody may be online at 4 AM. That is usually the point, but a notification with no one to read it goes nowhere.

A metronome for the server. The generated mod builds a small scheduler that starts when the mission starts and calls this event's chain over and over, forever, at the interval you set. It all runs on the server, so a mod built around it needs nothing installed on players' machines.

Two things about the shape. The first tick lands one full interval *after* server start, not immediately — a 300-second timer does nothing at all for the first five minutes. And there is no player attached: the chain begins with nobody in hand, so it usually starts by finding who it cares about with For Each Player or For Each Player Near.

When to use it

Anything that has to keep happening on a fixed rhythm: sweeping an area, ticking damage in a hazard, restart warnings, periodic announcements. For a single run shortly after boot, use After Delay On Start. For a particular time on the in-game clock, Daily At Time. For something that should follow a player standing somewhere, While Player In Zone is the zone-shaped version and hands you the player already.

Pins

Every (seconds) — read once, when the timer is built at mission start. It takes a typed number or a config value (Get Config Number) and nothing else; a runtime source is rejected by the generator with a message saying exactly that, because there is no runtime yet when the timer is created.

Example

An arena tick that punishes stragglers: Every N Seconds (10) → For Each Player → Is Player Alive → Branch; on True, Get Player Position → Distance Between (that and "7500 0 7500") → Greater Than (400) → a second Branch → Send Notification ("Return to the arena") and Damage Entity (10).

The alive check earns its place: bodies stay in the engine's player list until they despawn, so without it a corpse lying outside the ring is "punished" on every tick for minutes.

The tunable form drops the literal. Add a config number called "tickSeconds" and wire Get Config Number into the interval — server owners then change the pace in config.json without ever opening the editor.

Watch out

• Keep the interval sensible. Everything under the event runs inside one tick, and a heavy chain — a loop over every player that does real work — on a one-second timer costs the server that work every second, forever. A few seconds is the sane floor, and the editor will not accept less than 1.
• The interval is fixed for the life of the server. Changing it means changing the config and restarting.
• Timers keep running whether or not anyone is online. An empty player loop is cheap; a Spawn Item on a timer quietly fills an empty server with loot.
• A corpse is still a player. Gate loops on Is Player Alive whenever a body must not count.
• Nothing carries between ticks. To remember something from last time, store it with Set Global Number and read it back with Get Global Number.

The workhorse of a NodeZ menu. Draw a layout, put a named button in it, attach the layout to the project, and this node fires on the player who clicks that button. Everything around it is generated: a real DayZ scripted menu holding your layout, a mouse cursor while it is open, ESC to close, and the wiring that turns a click on that one widget into this event. The graph only has to say what the button *does*.

It runs on the player's own machine, because that is where the menu is. Anything the button then does to the world — handing over an item, teleporting, writing a score — cannot happen there, so NodeZ splits the chain: the client part runs, then it sends the server a message and the rest runs there with the clicking player attached, carrying any widget values the client read. You wire none of that; you only have to keep the halves in the right order.

When to use it

Any menu that *does* something: a spawn selector, a shop, an admin panel. For a key that only flips a HUD panel on and off, use On Key Pressed — a menu takes the controls away from the player while it is open, which is fine for a shop and wrong for a scoreboard. Text boxes and checkboxes have their own events (On Text Box Changed, On Checkbox Changed) but you rarely need them: one click can read every widget in the menu with Get Text Box Text, Is Checkbox Checked and Get Slider Value.

Pins

Menu Layout / Button — panel pickers, not wires. The layout must be attached to the project; the Button dropdown then lists the named widgets in it. A widget left unnamed in the layout editor cannot be picked at all.

Player — the person who clicked, on both halves of the split.

Example

A "starter kit" button. The layout holds a button named btn_kit, a label named lbl_status and a checkbox named chk_ammo.

On Button Clicked (that layout, btn_kit) → Set Widget Text (lbl_status, "Kit sent") → Give Weapon (M4A1 with Mag_STANAG_30Rnd). The first node touches the menu and runs on the player's machine; Give Weapon is server work, so everything from there down is handed to the server automatically.

To make the magazine optional, wire Is Checkbox Checked (chk_ammo) into a Branch after the label update — the client reads the tick and the answer rides across with the hand-off. Put a client-only node such as Close Menu *after* Give Weapon and the editor stops you: by then the chain is on the server, where there is no menu to close.

Watch out

• Client-side, so players need the mod. Set the project to Server + Client; a server-only install never builds the menu and the button can never be clicked.
• Client nodes before server nodes, always. Set Widget Text and Close Menu only work while the chain is still on the player's machine, and the editor errors if one lands after a server action.
• Widget names are exact and come from the layout editor. Rename one there and every node pointing at it fails validation until you re-pick it.
• A menu with no way to open it never fires. Set the layout's open mode in the layout panel — a keybind, or a hold-interaction on a world object. Only one menu shows at a time, so an open is ignored while another is on screen.
• Treat what reaches the server as a request, not a fact: cooldowns, permissions and costs belong after the hand-off, not in a branch before it. One click can carry at most ten values across, and the generator refuses to build past that.

Fires on the player's own machine when they tick or untick a checkbox in one of your menus, and tells you which way it went. Like the other menu events it runs client-side, because that is where the menu is.

When to use it

Immediate reaction to a tick: changing a label, showing what the option will cost, updating a preview. When the tick is simply an *option* that a button will act on later — "include a magazine", "spawn with a backpack" — do not use this event. Leave the box alone and read it at the moment the button is clicked, with Is Checkbox Checked under On Button Clicked. The player can then change their mind before committing, which is what a checkbox is for.

Pins

Checked — the box's new state: true when it is now ticked.

Menu Layout / Checkbox — panel pickers. The layout must be attached to the project, and the Checkbox dropdown lists the named widgets in it.

Example

A mode switch that explains itself. The layout holds a checkbox named chk_hardcore and a label named lbl_mode. On Checkbox Changed (chk_hardcore) → Branch with the event's Checked wired into the condition. The True path runs Set Widget Text (lbl_mode, "Hardcore: you drop everything on death"); the False path runs the same node with "Normal: you keep your gear". Both arms stay on the player's machine, so the label updates the instant the box is clicked.

To remember the choice server-side, continue past the branch: put Set Saved Player Number in each arm writing 1 and 0. Those are server nodes, so NodeZ hands off automatically once the chain reaches them.

Watch out

• It fires on every change, including the player un-ticking a box they just ticked. Anything expensive under it happens twice as often as you expect.
• Client-side, so players need the mod: the project must be Server + Client, and a server-only install never builds the menu.
• Client-only nodes have to come before server ones. Once a chain reaches a server action it stays on the server, and Set Widget Text placed after that point is an error — so put the label updates first and the saving afterwards, exactly as in the example.
• Nothing about the tick is remembered. The state you get is the widget's state right then; close the menu and it is gone unless you stored it yourself. Set Player Number keeps it for the session, Set Saved Player Number keeps it across restarts.

Fires on one player's own machine the moment they press your key in-game — no menu, no mouse cursor, no interruption to whatever they were doing. That is the whole reason it exists: opening a menu takes the controls away from the player, while a key press can flip a scoreboard on and off while they keep running.

The key in the panel is only a DEFAULT. NodeZ declares it as a real DayZ action in the mod's own inputs file, so it turns up in the game's Controls menu under whatever you typed in "Name In Controls", grouped under your mod, and every player can move it wherever they like. Nothing compares raw key codes; the generated mod asks DayZ once a frame whether your action fired. That is also why the game's own manners come for free — DayZ keeps these actions quiet while a player is typing in chat or has a menu open.

When to use it

Toggling something on the player's own screen: a scoreboard, a stats panel, a legend. It is the light-touch alternative to a full menu — for buttons, text boxes and checkboxes, attach a layout to the project and use On Button Clicked and its siblings instead. For something the server decides on its own, use Every N Seconds or On Server Started.

Pins

Player — the person who pressed the key. This runs on their machine, so it is always the player at the keyboard.

Example

A scoreboard on F5 that toggles. On Key Pressed (Name In Controls "Scoreboard", Default Key KC_F5) → Flip Flop. The A path runs Show HUD Overlay on your scoreboard layout and then Scale For Screen, so the panel is the right size on a 1440p monitor; the B path runs Destroy HUD Overlay on the same layout. Press once to show, again to hide.

A key that does server work looks the same in the graph but is split behind the scenes: On Key Pressed → Teleport Player to a fixed position. The press happens on the client, then NodeZ sends the server a message and runs the teleport there with the pressing player attached.

Watch out

• Client-side, so the mod has to be on players' machines as well as the server. Set the project to Server + Client — a server-only install runs its half happily and the key simply does nothing, with no error anywhere.
• The key still does whatever DayZ already does with it; a mod cannot take TAB away from the inventory. F5 to F8 are free in both the normal game and the diagnostic build you test with. K, L, INSERT and HOME are free in the retail game but taken in the diagnostic build, so a key that "doesn't work" in testing may be fine for players.
• Give every On Key Pressed node a *different* Name In Controls. That name becomes the action's internal id, so two nodes sharing a name share one binding and both fire together. Renaming it later changes the id, which puts players who had rebound the key back on the default.
• Client-only nodes must come BEFORE server ones. As soon as the chain reaches a server action, everything below runs on the server — an Set Text placed after it would be reaching for a screen it can no longer see, and the editor flags that as an error.
• Only the player crosses the hand-off. Anything else the client half worked out has to be re-derived on the server side.

Fires while the player is editing a text box in one of your menus, and hands you what is in the box at that moment. The engine raises a change event on an edit box as it is being typed into, so read this as "the text is now this" rather than "the player has finished typing" — it can fire on every keystroke.

Like every menu node it runs on the player's own machine, because that is where the menu lives.

When to use it

Live feedback while someone types: echoing a value into a label, warning about a bad character, previewing what will be sent. When you only care about the *final* text — which is the usual case — do not use this event at all. Put a button in the menu and read the box with Get Text Box Text when it is clicked, under On Button Clicked. That fires once, deliberately, instead of once per letter.

Pins

Text — the box's contents at that moment, exactly as typed, spaces and case included. It is the same value Get Text Box Text would give you for that box.

Menu Layout / Text Box — panel pickers. The layout must be attached to the project, and the Text Box dropdown lists the named widgets inside it.

Example

A live preview beside a message box. The layout holds an edit box named msg_box and a text widget named msg_preview. On Text Box Changed (msg_box) → Set Widget Text (msg_preview), with Join Text ("Sending: " plus the event's Text) feeding its Text pin. Every keystroke updates the preview, and nothing leaves the player's machine.

Acting on the message is a separate job: add a Send button and read the same box with Get Text Box Text under On Button Clicked.

Watch out

• It fires again and again as the player types. Never hang a server action off it — an Give Item To Player, a payment, a Write To Log File — or one twelve-letter message becomes twelve of them. Use a button for anything that commits.
• Client-side, so players need the mod: the project has to be Server + Client, and a server-only install never builds the menu.
• Client-only nodes must come before any server node in the chain. Once the chain reaches server work it stays there, and Set Widget Text placed after that point is an error.
• The text arrives exactly as typed. Comparisons with Text Equals are case-sensitive, and a classname a player typed by hand will not match unless the case is right — "gasmask" is not GasMask.

Fires on the server the moment a player settles into a vehicle's driver seat. It rides the vanilla hook the game itself uses to notice a driver has sat down, so it is exact — not a proximity guess — and it hands you both the person and the vehicle they just got into.

Driver seat only. Vanilla gives modders no equivalent for passengers, so someone climbing into the back does not fire this. If you need to know about everyone aboard, sweep with For Each Player Near and test each with Is Player In Vehicle instead.

When to use it

Anything that should react to somebody taking the wheel: logging who drove what and from where, blocking a vehicle a player has not earned, handing the driver a key item, starting a timer for a delivery run, or arming a safezone rule.

For the engine turning over rather than the seat filling, use On Vehicle Engine Started — a player can sit in a car for a long time without starting it. For getting out, On Player Left Vehicle.

Pins

Player — the driver. Live and in the world, so gear, health and variable nodes all work on them straight away.

Vehicle — what they got into, resolved from the seat they occupy. It can come back empty in the rare case where the engine has not finished attaching them yet, so check with Is Valid before acting on it. Feed it to Get Vehicle Fuel, Refuel Vehicle or Vehicle Engine.

Example

A driving-time tracker, paired with On Player Left Vehicle. On Player Entered Vehicle → Sequence.

Then 0 logs the trip: Get Player Name on the Player and Get Entity Type on the Vehicle → Join Text → Log Message. Then 1 starts the clock: Get Server Uptime → Set Player Number (the Player, Name "driveStart").

The other half is a second graph: On Player Left Vehicle → Get Server Uptime → Subtract (B = Get Player Number of that player's "driveStart") → Add To Saved Player Number (Name "driveSeconds").

Note where the start time is kept. Stamping it on the player rather than in a global is what lets two people drive at once — a global would be overwritten by whoever sat down last, and both trips would then be measured from the same moment.

Watch out

• Only the driver's seat fires this. Passengers are invisible to it.
• The Vehicle pin is a live handle. It does not survive a Delay —

stash it with Remember Item before the wait if a later step needs it, and check it with Is Valid when you read it back.

• This is a server event. HUD nodes cannot run under it — to put something on

the driver's screen you need the client half of your mod and a message sent to them.

• This tells you a player just sat down, not that they are sitting there now.

For the current state, ask Is Player In Vehicle.

• Tag Item does not work on vehicles. Tags are stored on inventory

items, and a car is not one, so tagging it does nothing and Get Item Tag on it always reads back empty. To mark one particular vehicle, remember it with Remember Item instead.

Fires on the server when a player gets out of a vehicle's driver seat. It is the exact counterpart to On Player Entered Vehicle and rides the matching vanilla hook, so it is precise about the moment rather than guessing from distance.

There is no Vehicle pin here, and that is not an oversight: by the time this runs the player is no longer attached to anything, so there is nothing to hand you. If your work needs the car, do it in On Player Entered Vehicle instead, or find it again around the player with For Each Object Near.

When to use it

Closing off whatever the entry event opened: stopping a delivery timer, clearing a "currently driving" flag, logging where a trip ended, giving back something you took away at the wheel. Driver seat only — a passenger climbing out does not fire it.

Pins

Player — the person who just got out. Their position is where they left the vehicle, so Get Player Position is a good stand-in for "where the car is" if you need it roughly.

Example

The closing half of a driving-time tracker. In On Player Entered Vehicle you stamp the start time on the player with Set Player Number (Name "driveStart", Value from Get Server Uptime). Here you cash it in:

On Player Left Vehicle → Get Server Uptime → Subtract (B = Get Player Number of that player's "driveStart") → Greater Than (B = 0) → Branch → True path → Add To Saved Player Number (Name "driveSeconds") with the difference as the Amount.

The Greater Than guard covers the case where this event fires without a matching entry — a player who was already seated when the server started has no "driveStart", which reads as 0, and would otherwise be credited with the server's entire uptime.

Watch out

• No Vehicle pin. Capture anything about the car during

On Player Entered Vehicle and stash it — for numbers, Set Player Number on the driver; for the car itself, Remember Item.

• Driver seat only. Passengers are invisible to this event, as they are to the

entry one.

• Do not count on it firing when somebody disconnects while still in the seat.

Anything that must be closed off either way belongs in On Player Disconnecting as well.

• A server event: HUD nodes cannot run under it.

Fires on the server every time any vehicle's engine starts, anywhere on the map. It hangs off the vehicle rather than off a player — the hook is the car's own "my engine just started" — so one copy of this event covers every car on the server at once, whether a player is nearby or not.

That also means there is no Player pin. The event knows which vehicle started; it does not know who turned the key. If you need the driver, pair this with On Player Entered Vehicle (which does give you both) or find the nearest person to the car with Get Nearest Player.

When to use it

Reacting to the engine specifically, rather than to somebody sitting down. A player can sit in a car for ten minutes without starting it, and can start a car they have been in all along — the two events fire at genuinely different moments.

Good fits: a noise or particle effect on ignition, a fuel warning, a log of every engine start, or a rule that certain vehicles cannot run in certain places. For the seat rather than the ignition, use On Player Entered Vehicle. To check whether an engine is running right now, Is Engine Running.

Pins

Vehicle — the car whose engine just started. Feed it to Get Vehicle Fuel, Get Entity Position, Vehicle Engine or Get Entity Type.

Example

A low-fuel warning that reaches whoever is driving. On Vehicle Engine Started → Get Vehicle Fuel on the Vehicle → Less Than (B = 0.15) → Branch → True path → Get Entity Position on the Vehicle → Get Nearest Player → Is Valid → Branch → True path → Send Notification ("Low fuel", "Under 15% left in the tank", 8 seconds).

Fuel is reported as 0 to 1 here, so 0.15 is fifteen percent — not the 0-100 scale Spawn Vehicle uses. The nearest-player step is standing in for a driver pin the event does not have; it is a good guess for someone sitting in the car, and the Is Valid check covers an engine that started with nobody around.

Watch out

• Every vehicle on the server shares this one event. On a busy map that is a

lot of firings — keep the work under it small, and filter early with Get Entity Type if you only care about one model.

• No Player pin exists, and the nearest player is a guess, not a fact.

On Player Entered Vehicle is the only event that reliably ties a person to a vehicle.

• Vehicle Engine set to Start also triggers this event. Wiring one

into the other makes them feed each other — put a Branch on something that will be false the second time round, or do not do it.

• A server event, so no HUD nodes under it. Anything that has to appear on the

driver's screen goes through a notification or a message to their client.

Fires once, on the server, the moment the mission finishes loading — before anybody has connected. It rides vanilla's own mission-start hook, the same point where the game brings the world up.

A useful thing to know is what has already happened by the time your chain runs. The mod's config.json has been read (and created from your defaults if it was not there), so every config node gives real values. The zones behind your zone events exist. The timers behind Every N Seconds and After Delay On Start are running. Your chain is the last thing to happen at boot, which makes it the right place to put the world into a known state before players arrive.

When to use it

One-time setup that is about the server rather than about a person: seeding globals so their first read is not 0, setting the weather (Set Weather) or clock (Set Time Of Day), building props with Spawn Static Object, writing a "we are up" line with Log Message.

For work that should happen a while after boot, After Delay On Start says so more clearly than this node plus a Delay. For work that repeats, Every N Seconds; for something on the in-game clock, Daily At Time. For setup that belongs to a player, On Player Ready is the one that fires when a character is actually there.

Example

Getting a scoreboard ready and keeping a restart count: On Server Started → Log Message ("arena mod loaded") → Set Global Number ("kills", 0) → Add To Saved Number ("restarts", 1) → Set Time Of Day to a fixed hour so every session starts in daylight.

Note the two different memories in that chain. The global starts at 0 because globals are wiped by the restart that just happened, which is exactly why seeding them here is worth doing. The saved number was loaded back off disk before the chain ran, so adding 1 continues a count that started weeks ago.

Watch out

• Nobody is online. For Each Player visits nothing, and anything player-shaped has no one to talk to — put that work under On Player Ready instead.
• HUD nodes cannot run here. They run on a player's machine, and at mission start there is no player and no screen. The same goes for anything else that needs the client half.
• It runs on every restart, including crashes and scheduled ones. A counter you increment here counts restarts, not days, and anything you spawn here is spawned again each boot.
• Globals (Set Global Number) are empty at this point by definition — they live only until the next restart. Saved numbers (Get Saved Number) are already loaded and keep their values across restarts; per-player values are neither, since no player exists yet.

An invisible circle you place on the map. When the server mission starts, NodeZ spawns a trigger there — the same trigger tech vanilla uses for its contaminated areas — and this node fires the moment a player steps inside. Only players trip it; infected and animals walk through unnoticed.

Everything runs on the server, so a mod built from this works without players installing anything.

When to use it

One-shot reactions at the boundary: a welcome message at a trader, a warning at a minefield, logging who reaches a landmark. For something that keeps happening while players stand inside, use While Player In Zone. To react when they walk out again, use Player Left Zone. If you just want to know how many players are near a point right now, without a standing zone, reach for Count Players Near instead.

Pins

Center Position — map coordinates of the middle. A height (the middle number) of 0 snaps the zone to the ground at that spot.

Radius (m) — how far the zone reaches from the center, in meters.

Both are read once, when the zone is created at mission start. Type fixed values, or wire them from config values (Get Config Position, Get Config Number) so server owners can tune them without opening the editor.

Example

A zone at 7500 0 7500 with radius 30 — Player Entered Zone → Send Notification (title "Toxic Zone", detail "You entered a toxic area!"), with the event's Player wired into the notification's Player pin so only the person entering sees it. Leave that Player pin unwired and the message goes to everyone on the server instead.

That wiring is the Toxic zone template (File → New from template) if you would rather start from it than build it.

Watch out

• Center and radius are fixed at mission start. Anything computed at runtime (a player's position, a random point) is rejected by the generator with a clear message — use fixed or config values.
• The zone is a sphere, not a column: it reaches as far up and down as it does sideways. A radius-10 zone at street level does not cover the fourth floor — grow the radius or raise the center.
• Pairing with Player Left Zone only works if both use exactly the same center and radius; otherwise players can be "inside" one zone and not the other.

The other half of a zone. NodeZ spawns an invisible sphere trigger at the position you give — the same trigger tech vanilla uses for its contaminated areas — and this node fires the moment a player crosses back out of it. Only players trip it; infected and animals pass through unnoticed. Everything runs on the server, so a mod built from this works whether or not players have it installed.

It also fires when a player *dies* inside. The trigger keeps a list of who is inside and drops anyone no longer alive, and being dropped counts as leaving. That is usually welcome — a safe-zone flag gets cleared even when the player never walks out — but the leave path can run for a corpse.

When to use it

Undoing whatever entry did: clearing a flag, taking back protection, stopping a timer, logging an exit. It is the natural partner of Player Entered Zone, and the two only behave as a pair when both nodes use exactly the same center and radius. For work that repeats while a player stands inside, use While Player In Zone.

Pins

Center Position — map coordinates of the middle. A height (the middle number) of 0 snaps the zone to the ground there.

Position and radius are read once, when the zone is created at mission start. Type them in, or wire them from Get Config Position and Get Config Number so an owner can move the zone without opening the editor.

Example

A safe zone that turns off again. One Player Entered Zone node at 4600 0 10300 with radius 100 → Set Player Invulnerable (ticked) → Send Notification "Safe zone — weapons are useless here". A second node, Player Left Zone, with the identical center and radius → Set Player Invulnerable (unticked) → Send Notification "You are no longer protected".

Invulnerability does not wear off on its own, so without the leave half your players walk away immortal.

Watch out

• Death inside the zone fires this too. If the leave path gives something back — unfreezing, restoring gear, paying out — gate it with Is Player Alive so a corpse does not collect.
• A player who disconnects inside is not guaranteed to fire this. Do session cleanup on On Player Disconnecting as well.
• The paired enter and leave nodes must match exactly. Different numbers make two differently sized spheres, and a player ends up inside one and outside the other with the flag stuck on.
• One node is one zone, fixed at mission start. You cannot loop a config list into a single node to get five zones — place five nodes — and a value computed at runtime is rejected by the generator with a clear message.
• The zone is a sphere, not a column: it reaches as far up and down as it does sideways.
• Server event: everything under it runs on the server, so client-only HUD nodes cannot go here. Use Send Notification to reach the player's screen.

The ticking zone. NodeZ spawns an invisible sphere trigger at mission start — the same trigger tech vanilla uses for its contaminated areas — and while players stand inside it, this node fires again and again on the interval you set. It fires once per player per tick: with four people inside, your chain runs four times, each with a different Player. When nobody is inside, nothing runs at all.

Only players are counted, and anyone who dies inside is dropped from the zone, so a corpse stops ticking on its own. Everything runs on the server, so a mod built from this needs nothing installed on players' machines.

When to use it

Anything continuous and place-based: radiation damage, a healing spring, income for holding a point, policing a trader. Use Player Entered Zone and Player Left Zone for one-shot work at the boundary. For the same shape without a fixed spot, Every N Seconds with For Each Player Near does the job and lets you work out the position at runtime.

Pins

Center Position — map coordinates of the middle. A height (the middle number) of 0 snaps the zone to the ground there.

Every (seconds) — the gap between ticks, one second at minimum.

Position, radius and interval are all read once, when the zone is created at mission start. Type them in, or wire them from Get Config Position and Get Config Number so an owner can retune the zone without opening the editor.

Example

Holding a point pays: While Player In Zone (Center 4600 0 10300, Radius 50, Every 30 seconds) → Add To Player Number (Name "credits", Amount 5) → Send Notification "+5 credits for holding the point".

The same shape with teeth makes a gas zone: While Player In Zone (Center 7500 0 7500, Radius 80, Every 5 seconds) → Get Attachment In Slot (Slot Name = "Mask") → Get Entity Type → Text Equals "GasMask" → Branch → on False, Damage Entity (Entity = the Player, Amount = 8). Reading the worn slot rather than searching the inventory stops a mask in a backpack protecting anyone.

Watch out

• Cost multiplies by the number of people inside. A one-second interval on a busy zone runs your whole chain dozens of times a second; a few seconds is nearly always enough.
• The interval is approximate — the trigger adds up frame time and fires on the first frame past the gap. Treat it as "about every N seconds", never as a clock.
• A Delay under this carries only the Player, and each tick starts its own wait. Stamp anything else onto the player with Set Player Number before the wait and read it back after.
• One node is one zone, fixed at mission start. You cannot loop a config list into a single node to get five zones — place five nodes — and a value computed at runtime is rejected by the generator with a clear message.
• The zone is a sphere, not a column: a radius-10 zone at street level does not cover the fourth floor.
• Server event: everything under it runs on the server, so client-only HUD nodes cannot go here. Use Send Notification to reach the player's screen.

The yes/no decision of every graph. Wire a true/false value into Condition and the chain continues down exactly one of the two paths — True when the condition holds, False otherwise. The condition usually comes from a compare node (Equals (Numbers), Greater Than, Text Equals, Is Valid); with nothing wired, the checkbox on the node is the fixed answer.

When to use it

Any single decision: is the killer real, is the player alive, does the config toggle say on. To pick between several named text values, Switch On Text is one node instead of a ladder of Branches. To run steps in order rather than choose between them, that is Sequence, not Branch.

Pins

Condition — evaluated once when the Branch runs. Leave a path unwired when nothing should happen on that side.

Example

On Player Died → Is Valid (Killer) → Branch — True gives the killer a Rag with Give Item To Player and a "Kill Reward" notification; False does nothing, because a fall or bleed-out has no killer. That empty Killer is the whole reason for the Branch — without it you would be rewarding nobody on every death the server did not attribute to a player.

That wiring is the Kill reward template (File → New from template) if you would rather start from it than build it.

Watch out

Do not wire the True and False arms back together into one shared node. Two exec wires converging make the build copy everything downstream under both arms — the mod still works, but it doubles silently. When both sides must end in the same follow-up, put the Branch under Then 0 of a Sequence and the shared follow-up under Then 1.

Asks "is this thing a player?", and if it is, hands you the player. The chain takes the Is Player path with the Player pin filled in, or the Not Player path when the object turns out to be a tree, a crate, an infected, or nothing at all.

NodeZ lets values flow *up* the ladder on their own — a player is also an entity, an entity is also an object — but never back down. So a pin that only knows it holds "an object" cannot be plugged into anything player-specific, no matter how sure you are. This node is the sanctioned way down, and the check and the conversion are the same step.

When to use it

Any time you hold something that might be a player: an object out of For Each Object Near, the thing that dealt damage, whatever a graph handed you as a general entity. To go down to an item instead of a player, As Item does the equivalent job as a plain value node with no exec wire. To ask only whether a pin is empty, Is Valid is enough.

Pins

Object — anything: an object, an entity, an item, a player.

Player — only in scope under the Is Player path. Wiring it into a node hanging off Not Player is not possible.

Example

An area effect that only touches people: Every N Seconds (10) → For Each Object Near (Position 7500 0 7500, Radius 25) → Body → Cast To Player with the loop's Object → Is Player → Is Player Alive → Branch → True → Send Notification ("Contaminated", "The air here is burning your lungs.") → Add Shock (10). Not Player is left unwired, so trees and crates in the sweep are ignored.

Watch out

• A corpse still casts to a player successfully — it is the same kind of thing, just dead. If a dead body must not count, follow the cast with Is Player Alive and a Branch.
• Not Player also covers "nothing here". An empty pin and a rock take the same path, so do not read it as proof the object exists.
• Do not converge Is Player and Not Player into one shared node. Two exec paths meeting make the build copy everything downstream under both; put the cast under Then 0 of a Sequence and shared work under Then 1.
• If a player-only node refuses your wire, this is almost always the missing piece — not a bug in the pin.

A tally built into the chain. Every time the node is reached it adds one to its own count and takes the Each path, with the running Count available there. On the single pass where that count lands exactly on Target, it also takes the Reached path.

The count only ever goes up. It is not reset by Reached, there is no reset pin, and pass 11 against a target of 10 does not fire Reached a second time. A server restart is the only thing that puts it back to zero.

When to use it

Milestones: the 50th kill of the restart, the 10th airdrop, an announcement when the server passes some round number of joins. Each is there for the running commentary; Reached is the payoff.

For a number you want to read, change and reset yourself, use the variable nodes instead — Add To Global Number with Get Global Number gives you the same tally with full control, and Add To Saved Number keeps it across restarts. For a per-player count this node is wrong: it is one shared number. Use Add To Saved Player Number and Get Saved Player Number, which also feed For Each Player (Ranked) for a leaderboard.

Pins

Target — read on each pass and compared for equality.

Count — the running total after this pass, so the first pass gives 1. Only in scope under Each.

Example

Marking every fiftieth death on the server: On Player Died → Counter (Target 50) → Each → Log Message with Count, so the server log carries a running tally; Reached → Broadcast Chat Message ("50 deaths since the restart. Be careful out there.").

Watch out

• One count, shared by everyone. Under a player event it counts how many times *anyone* triggered it, not how many times each person did.
• Reached is an exact equality test, not "at least". The count steps by one so it normally lands on the target — but a Target wired from something that changes between passes can be stepped straight over, and Reached then never fires at all. Type a fixed target unless you have a reason not to.
• The count keeps rising past the target. If you want the milestone to repeat every 50, use Remainder (Modulo) on a number you keep with Add To Global Number instead.
• Each and Reached must not converge on the same follow-up node — two exec wires meeting duplicate everything downstream. Use Sequence to share a tail.
• Each Counter node keeps its own separate total, and a restart clears it.
• Under a client-side event such as On Key Pressed, the total lives on that player's machine, so it counts their presses alone and resets when they quit the game.

A pause in the middle of a chain. Wire a number of seconds, and everything under Then runs that much later. Nothing freezes meanwhile — the node hands the Then path to the server's own timer queue and returns immediately, so the event that started the chain finishes at once and the server carries on serving everybody else.

That is why Delay is unlike every other node: its Then path is built as a separate routine, and exactly one value crosses the gap. Whatever you wire into Carry Player arrives on the far side as the Player output. Everything else from before the wait — an item you just spawned, a name you just read, a loop's current player — is out of scope over there. Wire one across and the build stops with an error naming the Delay, rather than shipping a mod that quietly misbehaves.

When to use it

Whenever the game needs a beat: letting a freshly teleported player finish loading before you hand them gear, spacing out a countdown, letting a client receive an item before the quick bar is told to point at it. For something that repeats on a schedule instead of once, use Every N Seconds. For a single wait measured from server start, After Delay On Start is a whole event and needs no chain to sit under.

Pins

Seconds — decimals are fine (0.5 works). Read once, at the moment the Delay runs.

Carry Player — the one value that survives the wait.

Player — the same player, on the far side. Use this output downstream, never the original event's Player pin: that one is not in scope inside Then.

Example

Gear after a teleport, which is the wiring this node exists for: On Player Ready → Teleport Player (7500 0 7500) → Delay (Seconds 2, Carry Player wired from the event's Player) → Give Weapon (M4A1 with Mag_STANAG_30Rnd), fed by the Delay's Player output → Resync Player Gear. Handing the rifle over in the same instant as the teleport leaves the player looking empty-handed to everyone else, because the engine is still rebuilding them for the other clients. Two seconds is enough.

Watch out

• Leave Carry Player unwired and the Then path never runs at all. The generated wait is guarded: if the carried player is empty when the timer fires, it stops there. That guard is what saves you when a player disconnects or dies mid-wait, but it also means an unwired Carry Player silently disables everything downstream, with no warning in the editor. Always wire it.
• Only the player crosses. Anything else the Then path needs must be worked out again after the wait, or stamped onto the player beforehand with Set Player Number / Set Player Text and read back with Get Player Number / Get Player Text.
• Do not park it in a global instead. Set Global Number is shared by everyone, and another player's event can overwrite it while you are waiting — that is exactly how a loadout ends up on the wrong person.
• A Delay under Then 0 of a Sequence does not hold up Then 1. Then 1 runs immediately, long before the delayed work. Chain anything that must follow the wait onto the Delay's own Then.
• A Delay inside a loop body does not stagger the loop. Every pass schedules its own wait in the same instant, so they all fire together — see Repeat for the trick of feeding the loop Index into Seconds.
• Delay is server-side. HUD nodes cannot live in its Then path, and putting one under a button press makes the whole chain hop to the server first.
• Inside a custom node, a Delay cannot sit between the entry and Node Outputs: the outputs belong to the caller, which has long since moved on. The build rejects that too.

A one-shot gate. The first time the chain reaches it, the Once path runs; every time after that, the chain simply stops here. There is no reset pin — the latch it keeps holds for as long as the server is up, and only a restart re-arms it.

When to use it

Something that must happen the first time a *condition* is met, rather than at a fixed moment. First player to walk into the bunker, first kill of the restart, first time the weather turns. For work that belongs at startup with no condition at all, On Server Started already fires exactly once and needs no gate.

For "once per player" this is the wrong node — the latch is one shared flag, not one per person. Stamp the player instead with Set Saved Player Number, read it back with Get Saved Player Number and gate on it with a Branch; that also survives restarts. To alternate rather than stop, use Flip Flop; to fire on the Nth time rather than the first, Counter.

Example

Announcing the first arrival at a landmark: Player Entered Zone (7500 0 7500, radius 30) → Do Once → Get Player Name (the event's Player) → Join Text with " reached the bunker first." → Broadcast Chat Message. Everyone who follows trips the zone as usual and the chain quietly ends at the gate.

Watch out

• The latch is global, not per player. The first person through closes it for everybody.
• Each Do Once node keeps its own separate latch. Copying the node gives you a second, independent gate — handy when you want it, surprising when you do not.
• A restart re-arms it. Anything that must stay done across restarts needs a saved value (Set Saved Number) checked with a Branch instead.
• Under a client-side event such as On Key Pressed or On Button Clicked, the latch lives on that player's own machine — so it becomes once per player, cleared when they quit the game, rather than once for the server.

A toggle in the chain. The first time it runs, the A path takes over; the next time, B; then A again, back and forth forever. It keeps one flag to remember which turn it is, and that flag lasts as long as the server is up — a restart puts it back to A.

When to use it

Alternating between two outcomes without any bookkeeping of your own: two airdrop sites taking turns, two announcements rotating, halving the work on a busy timer by doing one job on odd ticks and another on even ones.

For every third or every tenth, this is not enough — use Counter, or Remainder (Modulo) on a number you keep yourself. For a one-way gate that fires once and never again, Do Once. To pick between two paths on an actual condition rather than a turn, Branch.

Example

An airdrop that alternates between two ends of the map: Every N Seconds (1800) → Flip Flop → A → Spawn Item (AmmoBox_556x45_20Rnd) at 3200 0 8600 followed by Broadcast Chat Message ("Airdrop inbound: north-west."); B → its own Spawn Item at 11400 0 4200 and its own broadcast for the south-east. Each arm gets its own nodes.

Watch out

• Give each arm its own downstream nodes. Wiring A and B into one shared follow-up makes the build copy everything after it under both paths, so the shared tail is generated twice. If both arms genuinely must end in the same step, put the Flip Flop under Then 0 of a Sequence and the shared step under Then 1.
• The state is one flag for the whole server, not one per player. Under a player event, two players in quick succession get A and then B — they are sharing the toggle, not each getting their own.
• Every Flip Flop node has its own flag. Two copies do not stay in step with each other.
• A restart always starts again on A, so a schedule that matters across restarts needs a saved number (Set Saved Number) rather than this.

Walks a list of numbers from the mod's config file. Pick the list with the Config Field picker and the Body runs once per entry, handing you that number, then Completed runs. Like the other config lists, it lives in $profile:<ModName>/config.json and the server owner can lengthen or shorten it without touching the graph.

When to use it

Lists of amounts, radii, delays or tiers that a server owner should be able to tune. For one fixed number, Get Config Number needs no loop; for a random pick, wire Random Number into Get Config Number At; to count entries, Config List Count.

Pins

Number — the current entry, as a decimal.

Example

Hordes of configurable size at configurable places: On Server Started → For Each Config Number (Config Field: your number list, say hordeSizes) → Body → To Whole Number on Number → Repeat with that as Times → Spawn Infected or Animal (ZmbM_HunterOld_Autumn) at a position from Random Config Position.

Watch out

• The Number pin is a decimal. Whole-number pins — a Repeat's Times, a quick bar slot, an index — will not take it directly; put To Whole Number in between.
• There is no Index, so this list cannot be lined up with a second one. For parallel lists use Repeat driven by Config List Count, reading each list at the loop Index with Get Config Number At and Get Config Text At.
• The config file is read once and cached, so an owner's edits apply at the next restart.
• An empty or missing list runs no Body passes and still runs Completed.
• Do not converge Body and Completed on the same node — that duplicates everything downstream. Use Sequence.

Walks a list of map coordinates that the server owner keeps in the mod's config file. You define the list once in the Config panel, pick it here with the Config Field picker, and the Body runs once for every position in it — then Completed runs. Add a coordinate to the file and the loop covers it; delete one and it stops. No graph edit either way.

That is the whole point of the config lists: the person running the server gets to move your spawn points around in $profile:<ModName>/config.json without ever opening the editor.

When to use it

Anything that should happen at several places: crates at every configured drop site, static props at every landmark, a sweep of each arena. To pick one entry at random instead of visiting all of them, Random Config Position. For a single fixed place, Get Config Position needs no loop. To count the entries, Config List Count.

Pins

Position — the current coordinate. Only in scope under Body.

Example

Restocking supply crates everywhere the owner asked for one: On Server Started → For Each Config Position (Config Field: your positions list, say crateSpots) → Body → Spawn Item (SeaChest) with the loop Position wired into its Position pin → Set Item Lifetime (3600) so the crate sticks around → Completed → Log Message ("Crate restock done.").

Watch out

• There is no Index on this node, so you cannot line it up with a second list. When entry 3 of the positions has to pair with entry 3 of a classnames list, drive a Repeat from Config List Count instead and read both lists at the loop Index with Get Config Position At and Get Config Text At.
• The config file is read once, the first time the mod looks at it, and kept in memory from then on. An owner editing config.json on a live server sees nothing change until a restart — say so in your server notes.
• An empty or missing list is handled quietly: the Body never runs, Completed still does. A loop that "does nothing" is usually an empty list, not a broken wiring.
• The height in each coordinate is used as written. If the list holds ground-level spots with a 0 height, run the Position through Snap To Ground before spawning, or things end up buried or floating.
• Do not wire Body and Completed into the same follow-up node; converging exec paths duplicate everything downstream. Use Sequence.

Walks a list of text values from the mod's config file — most often a list of classnames. You define the list once in the Config panel, pick it here with the Config Field picker, and the Body runs once per entry, then Completed. The server owner edits the list in $profile:<ModName>/config.json, so a starter kit can grow or shrink without the graph changing at all.

When to use it

Handing out a kit, deleting a banned-item list, spawning one of each of something. To take a single random entry rather than all of them, Random Config Text. For one fixed text value, Get Config Text with no loop. To count entries, Config List Count.

Pins

Text — the current entry. Only in scope under Body.

Example

A starter kit the owner controls: On Player Ready → Clear Inventory → For Each Config Text (Config Field: your text list, say starterKit) → Body → Give Item To Player with the loop Text wired into its Classname pin. Add "BandageDressing" to the list in the config file and every new spawn gets one, with no rebuild of the graph.

Watch out

• Classnames are case-sensitive, and a wrong one fails silently — nothing spawns, nothing complains. "GasMask", not "Gasmask"; "Aug", not "AUG". This is the single most common reason a config-driven kit comes out short.
• One entry is one string; config lists cannot hold structures. When an entry needs several parts, encode them with a separator ("Aug,Mag_STANAG_30Rnd" or "name=medic; radius=40") and unpack inside the Body with Get Text Part or Get Setting.
• There is no Index here, so two lists cannot be walked side by side. For parallel lists, drive a Repeat from Config List Count and read each list at the loop Index with Get Config Text At and Get Config Number At.
• The file is read once and kept in memory, so an owner's edit to config.json takes effect at the next restart, not immediately.
• An empty or missing list runs no Body passes at all and still runs Completed.
• Giving gear in the same instant as a teleport desyncs. If this loop follows an Teleport Player, put a Delay of about 2 s in between and finish with Resync Player Gear.
• Do not converge Body and Completed on one node; that duplicates the tail. Use Sequence.

A full walk of everything a thing is carrying. Give it a container and the Body runs once per item inside: worn clothing, what is in the hands, everything in cargo, and everything nested inside those — the magazines in the vest, the food in the backpack, the backpack itself. It is the same deep enumeration the game uses internally, so nothing hides one level down.

The container you pass in is not included in its own list. It works on anything with an inventory: a player, a tent, a crate, a vehicle.

When to use it

When you need to look at, or act on, everything someone has: auditing gear, stripping a player before a match, counting what is in a stash, taxing a trader crate. If you already know the classname you are after, the direct nodes are far simpler — Has Item In Inventory, Count Items In Inventory, Find Item In Inventory, and Remove Items Of Type to delete them. To wipe a player completely, Clear Inventory is one node. To read only what is worn in a named slot, use Get Attachment In Slot.

Pins

Container — a player, or any entity with an inventory.

Item — the current item. It arrives as a general entity, which reaches entity pins like Delete Entity and Get Display Name directly, but item-specific nodes (Set Item Quantity, Set Item Health, Get Item Quantity) need it passed through As Item first.

Example

Logging what a player is carrying when they die: On Player Died → For Each Item In Inventory with the event's Player wired into Container → Body → Get Display Name (loop Item) → Join Text with "Dropped: " → Write To Log File.

To act instead of watch, swap the tail: Body → Get Entity Type (Item) → Text Equals ("GasMask") → Branch → True → Delete Entity removes every gasmask anywhere on them, pockets and backpacks included.

Watch out

• Worn is not the same as carried, and this loop sees both. A gasmask sitting in a backpack turns up here exactly like one on the face — it protects nobody. When the distinction matters, read the slot with Get Attachment In Slot instead.
• Deleting items while walking the list is fine — the list is taken before the loop starts — but anything you *add* during the loop will not appear in it.
• The Item pin is an entity, not a classname. Compare with Get Entity Type, and remember classnames are case-sensitive: "GasMask", not "Gasmask".
• A large stash means a long loop in a single frame. Running this on every player on a short timer adds up quickly.
• An empty or missing container is handled quietly: the Body never runs and Completed still does.
• Do not wire Body and Completed into the same node; converging exec paths duplicate the tail. Use Sequence.

Everything the engine knows about within a radius of a point — and it means everything. Dropped loot, spawned crates, infected, animals, players, and every tree, rock, fence and building the map is made of. The Body runs once per object with that object available, then Completed runs.

Because the list is that wide, the Object pin gives you the vaguest type NodeZ has. It will not connect to pins that expect an item or a player: you have to narrow it first, and narrowing is also the test for what the thing is.

When to use it

Sweeping an area: clearing loose gear from an arena floor, finding out what is sitting on a spawn pad, hurting everything inside a blast. To clear ordinary ground loot and nothing else, Delete Items In Radius does the whole job in one node with no loop and no narrowing. If you only care about players, For Each Player Near hands them to you already typed. To walk what is inside a container rather than around it, use For Each Item In Inventory.

Pins

Object — narrow it before use: As Item turns it into an item (empty when it is not one, so test with Is Valid), Cast To Player routes players onto their own path, and Get Entity Type gives the classname for a text compare.

Radius (m) — keep it modest, and read it as a flat distance across the ground rather than a bubble. The engine hands back map geometry along with the loot, so a large radius in a town is a lot of objects.

Example

Clearing an arena of the gear your own mod put there, and nothing else: Every N Seconds (300) → For Each Object Near (Position 7500 0 7500, Radius 60) → Body → As Item on Object → Get Item Tag → Text Equals ("arena") → Branch → True → Delete Entity fed by the As Item output.

The tag is what makes this safe. It is written by Tag Item when the item is spawned, and it is the only way to tell your Aug from an Aug a player carried in — the engine keeps no record of who created what.

Watch out

• Never wire the raw Object straight into Delete Entity. The list includes the buildings and trees the map is made of, and a blind sweep aims at those too. Narrow first, then act.
• As Item comes back empty for anything that is not an item, so check it with Is Valid (or compare its tag, as above) before you use it.
• Ownership cannot be read from engine state. Tag your spawns with Tag Item and check with Get Item Tag; there is no other way to tell them apart.
• Height is ignored completely. The engine tests a circle on the ground, not a ball, so the sweep is really a column with no top and no bottom: it catches the crate on a roof overhead and the loot in the basement, however far up or down they sit. If a floor matters, measure it yourself — As Item → Get Entity Position → Split Position and compare the Y (height) output with Less Than.
• The whole sweep happens in one frame. A big radius on a short timer is one of the easier ways to make a server stutter.
• Do not converge Body and Completed into a single node — that duplicates the tail under both. Use Sequence.

Walks everybody on the server. The Body path runs once per player with that player and their Index available, and when the last one is done the Completed path runs once. It asks the engine for the same player list the server keeps for its own housekeeping, so it sees everyone connected right now — no zone, no radius, no filter.

Index counts the players actually handed to the Body, starting at 0, so it is always a gapless 0, 1, 2 you can use as a row number.

When to use it

Server-wide sweeps where each player needs something of their own: a scheduled heal, a per-person message with their own score in it, a restart warning that names the player. If every player just needs to see the same words, skip the loop — Broadcast Notification and Broadcast Chat Message reach everyone in one node. For a subset around a point use For Each Player Near, and for a leaderboard order use For Each Player (Ranked).

Pins

Body — runs once per player. Player and Index are only in scope under this path.

Completed — runs once, after the last Body, in the same instant. Good for a summary line.

Example

An hourly medical drop: Every N Seconds (3600) → For Each Player → Body → Is Player Alive (loop Player) → Branch → True → Heal Player Fully (loop Player) → Send Notification ("Medical Drop", "You have been patched up."). Completed → Broadcast Chat Message ("Medical drop complete.").

The aliveness check is not optional politeness — without it the loop happily "heals" corpses.

Watch out

• Bodies still count. A dead player stays in the list until their corpse despawns, so anything that must not happen to a corpse needs a Is Player Alive gate in the Body.
• Do not wire Body and Completed into the same follow-up node. Two exec wires converging make the build copy everything downstream under both, so your summary line runs once per player as well. Put the shared work under Sequence instead.
• A Delay in the Body does not pause the loop. All the waits are scheduled in the same instant and go off together — each one does carry its own player, which is usually what you want.
• The whole loop runs in a single frame. Heavy work per player (spawning, big searches) multiplied by a full server is a visible hitch; keep the Body light or run it less often.

A leaderboard in one node. It reads a named number off every player on the server, sorts them, and runs the Body once per player in that order — best first by default — handing you the player, their Rank and their Value. Rank counts from 1, so it addresses "row 1, row 2" directly without any arithmetic.

The number is one you have been keeping yourself. Number Name is the name you used when you stored it, and Stored As says where to look: *Saved Player Number* reads the on-disk store written by Set Saved Player Number and Add To Saved Player Number, which is keyed to the player's Steam ID and survives restarts; *Player Number* reads the in-memory value from Set Player Number and Add To Player Number, which lasts only for their session. Pick the one that matches the node you wrote the score with, or every row reads zero.

When to use it

Any ordered pass over players: a scoreboard, a top-three announcement, paying out prizes at the end of a round. When order does not matter, For Each Player is cheaper and gives you a plain Index. To read one player's number without looping, use Get Saved Player Number or Get Player Number.

Pins

Rank — 1 for the leader, 2 for second, and so on.

Value — that player's number, already read. There is no need to look it up again inside the Body.

Completed — runs once after the last row.

Example

A scoreboard broadcast every few seconds: Every N Seconds (5) → For Each Player (Ranked) with Number Name "kills", Stored As *Saved Player Number*, Order *Highest first* → Body → Join Text joining Rank and Get Player Name (loop Player), then a second Join Text adding the Value → Broadcast Chat Message with that text.

To limit it to the top three, put a Less Than on Rank (B = 4) into a Branch and hang the message off True.

Watch out

• Everyone connected is in the list, including players who have never scored — a missing number reads as 0, so the bottom of the board fills with zeroes. Gate on Value with a Greater Than if you only want players who are actually on the board.
• Corpses are still players and still rank. Add a Is Player Alive check in the Body if a dead man should not hold a row.
• Getting Stored As wrong is the silent failure here. A score written with Add To Saved Player Number but read as *Player Number* gives a board of zeroes, in server list order, with no error anywhere.
• Players tied on the same number keep the order the server listed them in, so a board refreshing every few seconds does not jitter between two level players.
• Do not converge Body and Completed into one shared node — that duplicates everything downstream under both. Use Sequence to phase the work instead.
• Saved numbers follow the person, not the character. A player who dies and respawns keeps their score; that is usually the point, but it does mean a wipe needs you to clear the numbers yourself.

Everyone standing within a given distance of a point. The node measures each player's straight-line distance from the position you give it and runs the Body once for each that falls inside the radius, then runs Completed. Position and radius are both read once, at the start, so the whole sweep uses one consistent circle.

When to use it

Anything that should affect a place rather than the whole server: an announcement at a trader, damage inside a hazard, a reward for whoever is standing on the objective. If you only need the count, Count Players Near answers without a loop; for the single closest person, Get Nearest Player. If the point of interest is a standing area players walk in and out of, the zone events (Player Entered Zone, While Player In Zone, Player Left Zone) fire on their own and need no timer behind them. For everyone on the server, For Each Player.

Pins

Position — the middle of the circle. Type it in, or wire it from Get Config Position so the owner can move it, or from Get Player Position to sweep around somebody.

Radius (m) — meters from that point.

Example

A capture point that pays whoever is standing on it: Every N Seconds (30) → For Each Player Near (Position 7500 0 7500, Radius 25) → Body → Is Player Alive → Branch → True → Add To Saved Player Number (Name "points", Amount 1) → Send Notification ("Objective", "+1 point for holding the point.").

Watch out

• It measures in three dimensions, not on a flat map. A 10 m sweep at street level does not reach the fourth floor of a building above it — widen the radius or raise the position if height should not matter.
• Corpses are still players. A body lying on the objective collects points forever unless you gate the Body with Is Player Alive.
• The position is snapshotted before the loop, so wiring a volatile value like Random Point Near into it rolls once and the whole sweep shares that one point — which is what you want here.
• Nothing announces an empty sweep. If nobody is nearby, the Body never runs and Completed still does; put "nobody was here" handling on Completed with a Count Players Near check rather than expecting the loop to tell you.
• Do not wire Body and Completed into the same follow-up node; converging exec paths duplicate everything downstream. Use Sequence.

Do the same thing N times. The Body path runs Times over, with Index counting 0, 1, 2 and so on, and then Completed runs once. Times is read once before the first pass, so nothing that happens inside the loop can change how many passes are left.

Set Times to 0 and the Body simply never runs — Completed still does.

When to use it

Fixed repetition: three crates instead of one, a burst of spawns, ten rows of a table. It is also the way to walk several config lists side by side. The For Each Config nodes give you one value at a time and no position, so when entry 3 of the weapons list has to line up with entry 3 of the magazines list, drive a Repeat from Config List Count and read each list at the loop Index with Get Config Text At, Get Config Number At and Get Config Position At.

For one pass per player, For Each Player; per item, For Each Item In Inventory.

Example

A loot run driven entirely by config: On Server Started → Repeat with Times wired from Config List Count on your positions list → Body → Spawn Item, its Position from Get Config Position At (Index) and its Classname from Get Config Text At (Index) on a parallel classnames list. Entry 3 of one list always lands with entry 3 of the other, because both are read at the same Index.

Watch out

• Index starts at 0. Anything counted from 1 — a quick bar slot, a scoreboard row — needs an Add of 1 on the way out.
• Two parallel lists of different lengths will run off the end of the shorter one. The At nodes return a safe empty value rather than erroring, so the symptom is a silent blank entry, not a crash — size the loop from the shorter list.
• A volatile value like Random Number inside the Body rolls fresh on every pass, which is usually the point. Wiring that same node into two pins in one pass still gives two different numbers — store the roll with Set Global Number and read it back if both need to match.
• A Delay inside the Body does not space the passes out. Every pass schedules its wait in the same instant and they all fire together. To stagger them, wire Index through Multiply into the Delay's Seconds so pass 0 waits none, pass 1 waits the gap, and so on.
• Times is a whole number. A decimal source — a config number, a Divide result — has to go through To Whole Number first.
• A very large Times runs entirely in one frame and will hitch the server.

Runs its three Then paths in order: everything under Then 0 finishes, then Then 1, then Then 2. It is a phasing tool, not a decision — all three always run, in the same instant, one after another. Unwired Then pins are simply skipped.

When to use it

Splitting one event into tidy stages: "first settle the score, then hand out the kit". It is also the cure for a subtle build problem: wiring two exec paths (say, both arms of a Branch) into the same follow-up node makes the generated code duplicate everything downstream under both sources. Instead, put the branching work under Then 0 and the shared follow-up under Then 1 — it runs once, after either arm.

Need more than three phases? Wire another Sequence into Then 2. For choosing one path instead of running all of them, use Branch or Switch On Text.

Example

A spawn handler split into two phases: On Player Connected → Sequence — Then 0 resets the player's round score with Set Player Number (Name "score", Value 0); Then 1 goes into a 2-second Delay and then Give Item To Player (Aug). The bookkeeping lands instantly, because nothing about it needs the player to be finished loading; the kit waits, because handing items to a body the client is still streaming in is how loadouts go missing.

Watch out

A Delay inside Then 0 does not hold up Then 1. The Delay schedules its tail for later and returns immediately, so Then 1 runs right away — long before the delayed work. If step two must wait for step one's delay, chain it after the Delay's Then instead.

One text in, one of five paths out. You type up to four things to match on the node, and the chain takes the Case that matches — or Default when none do. The comparison is a plain, exact, whole-string match, tried from Match 1 downwards, so the first one that fits wins and the rest are skipped.

Match slots you leave blank are dropped entirely: their Case pin can never fire, no matter what comes in. Fill the matches from the top.

When to use it

Routing on a name: which team a player is on, which classname just changed hands, which mode the config asks for. It replaces a ladder of Branch plus Text Equals with one readable node. For a partial match ("does this classname contain Mag_") use Text Contains into a Branch. For numbers, compare with Equals (Numbers) or Greater Than into a Branch. For a single yes/no, Branch is still the right node.

Pins

Value — read once, when the switch runs.

Default — everything that matched nothing, including empty text. Leave it unwired if unmatched values should do nothing.

Example

Team loadouts from a value stamped on the player: On Player Ready → Get Player Text (Name "team") → Switch On Text with Match 1 "blue" and Match 2 "red" → Case 1 → Give Weapon (AKM with Mag_AKM_30Rnd); Case 2 → Give Weapon (M4A1 with Mag_STANAG_30Rnd); Default → Send Chat Message ("You have not picked a team yet.").

The text itself gets there earlier, from Set Player Text when the player chooses a side.

Watch out

• Matching is case-sensitive and exact. "Blue" does not match "blue", and "GasMask " with a trailing space matches nothing at all. Classnames especially: "Aug", not "AUG".
• A blank Match slot silently disables its Case. If Case 3 never seems to fire, check that Match 3 actually has text in it.
• Two Match slots holding the same text mean the lower one can never win.
• Do not wire two Cases into one shared follow-up node. Converging exec paths make the build copy everything downstream under both, so shared work happens twice over. Put the switch under Then 0 of a Sequence and the shared work under Then 1.
• Four matches is the limit. For more, chain a second Switch off the Default path.
• Comparing a classname read from Get Entity Type is the common use, and its exact casing comes from the game's own config — copy it, do not retype it from memory.

Walks the server's player list and disconnects everyone who has a live connection. It is the bulk form of Kick Player, with no pins to fill in — one node, everybody out.

When to use it

Clearing the server at a known moment: the last step of a restart countdown, or emptying the world before maintenance. For a single player, use Kick Player.

Example

The tail of a restart countdown on a four-hour cycle: Every N Seconds (30) → Get Server Uptime → Greater Than (14340) → Branch → the True side runs Do Once → Broadcast Notification ("Restart", "Server restarts in one minute", 30 seconds) → Delay (55 seconds) → Kick All Players. Everyone gets a warning, a minute to find somewhere safe, and a clean disconnect just before the restart script takes over.

Watch out

• This does not stop or restart the server. The moment they are out, players can reconnect to the still-running server — it only makes sense seconds before something else actually takes the server down.
• It kicks whoever triggered it too, including you while testing.
• Do Once or a similar gate matters here more than anywhere: a condition that stays true for the rest of the cycle would kick every player again on each check, including everyone who just reconnected.
• Server node. Under a menu or key event the chain moves to the server from this point, so client-only nodes (Set Widget Text, Close Menu, the HUD nodes) must come before it.

Disconnects one player from the server, the same way the server drops a connection for any other reason. Their character is saved and left in the world as vanilla always handles a disconnect; the person is simply put back at the server browser.

The node checks first. It only acts on a real player with a live connection, so an empty Player pin or someone who has already left is skipped quietly instead of causing trouble.

When to use it

Enforcement you cannot handle in-game: a whitelist, an admin tool, removing someone during maintenance. It is not a punishment with any staying power — for consequences inside the game, Kill Player or Set Player Restrained keep the player on the server. To clear the whole population before a restart, use Kick All Players.

Pins

Player — who to disconnect. Empty is safe: the node does nothing.

Example

A whitelist with a warning: On Player Ready → Is Player In ID List (your Steam IDs, comma-separated) → Not → Branch; the True side (they are not on the list) runs Send Notification ("Whitelist", "This server is private — you will be disconnected", 8 seconds) → Delay (5 seconds, carrying the Player) → Kick Player on the delay's Player output. The wait is what turns a baffling disconnect into an explained one.

Watch out

• A kick is not a ban. The player can reconnect immediately, which is why a whitelist check belongs on On Player Ready — it runs again on every join, so it keeps kicking them until they stop trying.
• The player sees only a generic disconnection, with no reason attached. Send the explanation first, then wait a few seconds before kicking, as above.
• Delay carries the player and nothing else, which suits this node perfectly — but any text or number you worked out before the wait is gone, so build the warning message before the delay, not after.
• Under For Each Player remember that corpses are still in the player list. Gate on Is Player Alive where that matters, and be careful with sweeping conditions — a kick loop with a wrong comparison empties your server in one pass.
• Test with your own account in mind: a rule wired to "everyone who is not on the list" includes you until your own ID is in it.

Appends a line to a plain text file of your own, in the server's profile folder — the folder your server launches with, next to the .RPT logs. The file is created the first time the node runs and added to from then on, so it survives restarts and builds up into a record you can open, search or load into a spreadsheet.

The File Name setting decides which file the line lands in, so one graph can keep several separate records: joins in one file, admin actions in another. Each node writes the text you give it and nothing else — no timestamp, no player name, no separators are added for you.

When to use it

Audit trails and anything you want to keep: who joined and when, which players were kicked, what a shop sold. For quick "did this run" checks while building a graph, Log Message is easier — it needs no file and is already tagged with your mod name. For anything a player should see, use Send Notification or Send Chat Message.

Pins

Text — the whole line, exactly as it will appear. Build it with Join Text.

File Name (panel) — the file inside the profile folder. Plain names only, and pick a distinctive one so it cannot collide with a server or mod log.

Example

A join log that sorts itself: On Player Connected → Get Date & Time Text and Get Player Name into Join Text ("2026-07-17 14:05:33 joined: Dave") → Write To Log File (File Name joins.txt). Because the timestamp starts with the year, the lines end up in time order without any work.

A record you can open as a spreadsheet: join the same values with commas — timestamp, Get Player Steam ID, Get Player Name — and write to joins.csv. One Join Text per column pair, and the file imports straight into any spreadsheet.

Watch out

• Writing is limited to the profile folder. A File Name pointing into a folder that does not exist writes nothing and reports nothing — the node fails silently, so if the file never appears, check the name before you suspect the graph. Prove the chain runs with an Log Message alongside it.
• The file is opened and closed on every single call. That is fine for events; it is not fine inside a one-second timer or a per-player loop, where it becomes real disk work on every pass.
• Nothing is added to your text. No timestamp, no newline separators between fields, no mod tag — an unstamped log line is impossible to place later, so put Get Date & Time Text at the front of anything you intend to keep.
• The file grows forever. Nothing rotates or trims it; on a busy server a per-connect log becomes large, so plan to archive it during restarts.
• Server node. Under a menu or key event the chain moves to the server from here on, so client-only nodes (Set Widget Text, Close Menu, the HUD nodes) must come first.

Sets off a blast at a point on the map, using the game's own explosion damage system. Everything in range takes the damage that ammunition type deals — players, infected, vehicles, dropped loot — falling off with distance the way that ammunition's blast normally does.

The Explosion Type is not decoration: the blast radius and how hard it hits are read from that ammunition's own config, so choosing the type *is* choosing the size of the explosion. Explosion_40mm_Ammo is a launcher shell, ExplosionSmallGrenade a frag grenade, ExplosionLandmine a mine.

The one thing this node does not do is look or sound like an explosion. It is damage only — no flash, no bang, no smoke. In vanilla those come from the grenade itself, and there is no grenade here. Pair it with Spawn Particle Effect and Play Sound At Position at the same point, or players will simply fall over for no reason.

When to use it

Anything that should hurt an area at once: artillery events, minefields, a self-destructing crate. For damage to one thing, Damage Entity. When some players must be spared, For Each Player Near with Damage Entity in the body lets you check each one first — this node gives you no such chance.

Pins

Position — the centre of the blast. Height counts: a position at sea level (a height of 0) puts the explosion under the terrain and much of the damage with it. Send config or computed positions through Snap To Ground first.

Source — optional, the entity blamed for the blast. Leave it empty and the explosion belongs to nobody, which is usually what you want for a scripted event.

Example

A shelled zone that players can hear coming. Add a Position list strikePoints and a Number field strikeEvery (default 900), then wire Every N Seconds (Every (seconds) from Get Config Number) → Set Global Position ("strike") fed by Random Config Position → Broadcast Notification ("Incoming — take cover") → Delay (5 seconds) → Spawn Particle Effect (Large fire) → Play Sound At Position (Explosion_MortarShell_SoundSet) → Create Explosion (Explosion_40mm_Ammo). All three of those last nodes take their position from Get Global Position ("strike") so the warning, the fireball, the bang and the damage land in the same place.

Storing the point in a global before the delay is what makes the five-second warning work: after a delay, only a carried player survives from before the wait, and here the timer is the only thing that ever writes that global, so nothing can overwrite it mid-countdown.

Watch out

• Silent and invisible on its own. Without a particle and a sound alongside it, players just die for no apparent reason.
• It does not care who anybody is: everyone in range is damaged, the player who triggered it included. The damage is dealt by the server, so it lands on players with no mod installed too.
• Height decides the damage. An explosion under the terrain barely reaches anyone.
• A random position must be stored before use. Wired straight into several nodes it rolls a fresh point for each, and the smoke, the bang and the blast land in three different places.

Takes health off anything the engine treats as an object: a player, an infected, a car, a dropped rifle, a tent, a fence. It is the same "decrease health" call the game's own damage system uses when a bullet lands, minus the bullet.

The Amount is health points on that thing's own scale, not a percentage. A player's health runs 0 to 100, so 25 is a quarter of them. An item's maximum health comes from its own config and is usually in the hundreds or thousands, so the same 25 barely scuffs a rifle and does nothing noticeable to a truck. Expect to pick a different number for every kind of target.

When to use it

Wearing something down rather than finishing it: a zone that hurts, a trap, an event that degrades vehicles. To destroy outright use Kill Entity (or Kill Player for a player). To set a condition rather than subtract from it, use Set Player Health for players (0-100%) or Set Item Health for items, which can also take a percentage. To go the other way, Repair Entity.

Pins

Entity — anything: a Player output wires straight in, as does an Item or an Object from a loop like For Each Object Near. An empty pin does nothing at all, so a failed lookup upstream is harmless.

Amount — health points removed, on the target's own scale.

Zone (blank = whole) — leave it blank to hit the entity's overall health. Fill in a damage zone name to hit one part; the names belong to the model, so a character has zones like "Head" and "Torso" while a vehicle has its own set. A name the model does not have does nothing, with no warning — leave it blank unless you know the zone exists.

Example

A hazard area that hurts, built without any item or effect. Place While Player In Zone (Center Position 3800 0 6000, Radius 40, Every (seconds) 5) → Damage Entity with Entity wired from the event's Player and Amount 4 → Send Notification to the same player ("Your skin is burning"). Standing in it costs four health every five seconds, and walking out stops it.

Compare that with the Toxic zone template (File → New from template). It talks more than the wiring above does — Player Entered Zone sends a notification, While Player In Zone sends another every five seconds, and Player Left Zone sends the all-clear — but it never takes a single point of health off anyone. Hang Damage Entity off its five-second chain and it stops being a warning sign.

Watch out

• A corpse is still an object. If you damage everything in a radius, dead bodies and dropped loot are in that list too; gate on Is Player Alive when only the living should be hurt.
• Damage on a player is applied by the server, so it works for players who have no mod installed. Nothing about this node needs a client half.
• Points, not percent. Copying an amount that felt right on a player onto a vehicle does nothing visible — read the target back with Get Entity Health (0 to 1) while you are tuning.
• Enough damage kills. There is no "leave them at 1 health" safety net here, and a player killed this way has no killer to credit.

Sets a thing's health to zero. What that means depends on what it is: an infected or animal dies, a player dies, an item is ruined, a vehicle is wrecked. The object stays in the world in its destroyed state — a corpse, a ruined rifle, a burnt-out car.

That last part is the distinction worth holding on to. This node destroys; it does not tidy up. Delete Entity is the one that makes something vanish as if it had never existed.

When to use it

Killing creatures on command — clearing an arena of infected, ending an event's spawns — or ruining an item deliberately. For players, Kill Player says what it means and reads better in a graph. To remove something without leaving remains, use Delete Entity; for dropped loot in an area, Delete Items In Radius clears the ground in one go. To hurt without finishing, Damage Entity.

Pins

Entity — a creature, item, vehicle or player. An empty pin does nothing, so it is safe to wire straight from a lookup that may find nothing.

Example

A field that destroys whatever a player carries into it. Place While Player In Zone (Center Position 5900 0 2400, Radius 25, Every (seconds) 4) → Get Item In Hands on the event's Player → Branch on Is Valid → True → Kill Entity on that item → Send Notification ("Your equipment is ruined"). The item stays in their hands as a ruined version of itself, which reads far better to the player than it silently disappearing.

The Is Valid check is doing real work there: a player walking through empty-handed produces nothing to kill, and wiring an empty item into this node would simply be a no-op anyway.

Watch out

• Inside For Each Object Near every object is a candidate — players, their dropped gear, parked cars, even the buildings. Narrow the list before killing in bulk: Cast To Player separates players from the rest, Is Item Of Type matches a classname on a plain object, and Get Item Tag recognises items your own mod created. Engine state alone will not tell you what an object is for.
• Corpses and wrecks stay. They despawn on the game's own schedule, so a sweep that runs often will pile bodies up; follow with Delete Entity if the remains are the problem.
• Nothing is credited with the kill. A creature killed this way has no killing player, so a bounty built on On Creature Killed has nobody to pay.

Puts an object back to full health in one step — pristine condition, every damage zone included. It works on anything: a wrecked car, a damaged tent, a badly worn rifle.

Repair means condition and nothing else. A car comes out undented but still empty of fuel, a magazine comes out pristine but still empty of rounds.

When to use it

Service points and admin conveniences: a garage that fixes what you drive up in, a reward that restores a player's gear. For part of the way rather than all of it, Set Item Health takes a value or a percentage and can target a single zone. For fluids use Refuel Vehicle, and for a magazine's rounds Set Magazine Ammo. The opposite direction is Damage Entity.

Pins

Entity — anything with health. An empty pin does nothing, so an upstream lookup that found nothing simply skips.

Example

A repair bay: While Player In Zone (Center Position 4500 0 8100, Radius 8, Every (seconds) 3) → Get Player Vehicle on the event's Player → Branch on Is Valid → True → Repair Entity on that vehicle → Refuel Vehicle (Fluid Fuel, Mode Fill To Full) → Send Notification ("Serviced"). Drive in, wait a moment, drive out whole. Players on foot fail the Is Valid check and are left alone.

Watch out

• Repairing does not refill. Fuel, water, ammunition and every other quantity stay exactly where they were.
• It is total. There is no "repair by 20%" here; use Set Item Health when partial repair is the point.

Plays a sound in the world at a point on the map. Everyone close enough hears it, from the right direction, and it fades with distance the way any game sound does.

Worth knowing how it gets there, because it explains the rules below. Sound only exists on a player's machine — a server has no speakers. So this node does not play anything itself: it sends every connected player a small message saying "play this sound set, here", and the mod's half on their machine does the playing. The distance falloff then happens naturally on each client, so a player across the map receives the message and hears nothing.

When to use it

Anything that should be heard where it happens: an explosion, a siren, a horn at a trader, a warning before an event. For a sound only one person should hear, Play Sound For Player plays at that player's own position instead. For something seen rather than heard, Spawn Particle Effect. When the point is to tell players something in words, Broadcast Notification needs no mod on their side at all.

Pins

Position — where the sound comes from. Height matters as much as it does for anything else in the world; a height of 0 is sea level.

Sound set — the name of a sound set from the game or another mod, typed exactly. The default, Explosion_MortarShell_SoundSet, is a loud one-shot blast. A name that does not exist plays nothing at all, with no error.

Example

Giving a scripted blast its bang: Spawn Particle Effect (Large fire) → Play Sound At Position (Explosion_MortarShell_SoundSet) → Create Explosion, all three taking the same position. The explosion node deals the damage and this one supplies the noise — on its own, the blast is completely silent.

Watch out

• This needs the mod on players' machines. In a project set to "Server only" the editor refuses the node and tells you to switch to "Server + Client" in Project Settings. Players who then join without the mod hear nothing; the server-side half of your graph still runs normally for them.
• Nothing stops a sound once it starts — there is no handle to it. Stick to short, one-shot sound sets.
• The message goes to every player on the server, no matter how far away they are. That is fine for events; do not put this node inside a loop that runs many times a second.
• Sound set names are exact and case-sensitive, and a typo is silent. Test with the default first, so you know the wiring works before you go hunting for names.

Plays a sound for exactly one player. Nobody else hears it, and because it plays at that player's own position it starts right next to them — full volume, wherever in the world they are.

That makes it the audio version of a private notification. Where Play Sound At Position puts a sound in the world for everyone nearby, this puts one in a single player's ears.

When to use it

Personal feedback: a chime when a reward lands, a warning when a player's own timer runs out, a click confirming an action worked. For a sound that belongs to a place rather than a person, use Play Sound At Position. For words on screen, Send Notification — which has the advantage of working for players with no mod installed.

Pins

Player — who hears it. An empty pin does nothing, so wiring it from a lookup that may come back empty is safe.

Sound set — a sound set name from the game or a mod, typed exactly. A name that does not exist plays nothing, silently.

Example

Making a payout audible. The Kill reward template (File → New from template) hands the killer an item when they get a kill; adding Play Sound For Player to that chain, with the Player pin wired from the event's Killer, means the reward announces itself even if the player is not looking at the corner of their screen.

Watch out

• This needs the mod on players' machines. A project set to "Server only" will not accept the node — switch it to "Server + Client" in Project Settings. A player who joins without the mod hears nothing, while the rest of the chain still runs for them.
• The sound is pinned to a spot in the world, not to the player. The server reads their position the moment the node runs and the sound plays there, fixed, for as long as it lasts — it does not follow them. On a short chime you will never notice; a player sprinting away hears a longer one fall behind. There is no way to aim it anywhere else, so use Play Sound At Position when the sound belongs to a place.
• Once started, a sound cannot be stopped from a graph. Keep to short, one-shot sound sets.

Shows a visual effect at a point on the map — fire, smoke or steam, picked from a short list of the game's own effects. Every player near enough to see that spot sees it.

Like sound, particles only exist on players' machines; the server has nothing to draw with. So this node sends every connected player a message saying "play this effect, here", and the mod's half on their machine draws it. That is why the effect needs the mod installed on the player's side, and why a player who connects a minute later sees nothing — the message has been and gone.

When to use it

Marking a moment or a place: the fireball of a scripted explosion, smoke over an airdrop, steam from a vent. It is a burst of feedback, not scenery — there is no handle to move it, stop it, or attach it to anything, and it does not follow whatever you spawned it over. For something that must be there permanently, spawn a real object with Spawn Static Object. For the noise to go with it, Play Sound At Position.

Pins

Position — where the effect appears. A height of 0 is sea level, so smoke meant to rise off the ground needs a real height: run config or computed positions through Snap To Ground first.

Effect — one of the ten built-in choices (Small fire through House smoke, plus Steam). They are the game's own campfire and building-fire effects, so their size is fixed — pick the one whose scale suits, rather than expecting to resize it.

Example

A crate drop you can see from a distance. Every N Seconds → Set Global Position ("drop") from Random Config Position → Spawn Item (SeaChest) at that point → Spawn Particle Effect (Large smoke) at the same point → Broadcast Notification ("Supplies dropped"). To keep the marker alive while players run to it, fire the effect again a few times on a short Delay chain; one call is one puff.

Watch out

• The mod has to be on players' machines. A "Server only" project refuses the node and points you at Project Settings; players without the mod see nothing while the rest of the graph still works for them.
• Only people connected at that instant see it. Nothing about the effect persists, so it cannot mark a place for someone who arrives later.
• Every call is a separate effect. Calling it in a fast loop stacks effects on top of each other on every client and costs them frames.
• The message goes to all players regardless of distance; the effect is simply out of sight for anyone far away.

One line of text in everybody's chat. Unlike the notification broadcast, this really is a loop: the generated code takes the server's current player list and sends the line to each player in turn. Vanilla clients receive it without any mod installed.

Style picks one of the game's own chat colours for the line. It has no effect on who receives it.

When to use it

Announcements that belong in the log rather than on the screen: killfeed lines, event chatter, "the trader is open". When the message must be seen, Broadcast Notification puts a box in front of every player instead. When only one person needs it, Send Chat Message.

Pins

Text — the line. Assemble it from live values with Join Text.

Style (panel) — Info, Action, Friendly or Important. Colour only.

Example

A simple killfeed: On Player Died → Is Valid (Killer) → Branch → on the True side, Get Player Name (Killer) and Get Player Name (Victim) feed two Join Text nodes to build "Dave killed Mike" → Broadcast Chat Message (Style Important). The Is Valid gate keeps bleed-outs and falls out of the feed, where the killer would be blank.

Watch out

• It walks the whole player list every time it runs. Put it inside For Each Player and every player triggers a message to everybody — sixty players means 3600 chat lines from one event. Broadcasts belong outside loops.
• The list it walks is the engine's raw player list, which includes bodies that have not despawned yet. Harmless for a chat line, but it means "everyone who got the message" is not the same as "everyone alive".
• Style is colour only. Nothing about "Important" makes the line stay longer or stand out beyond its colour.
• Chat is easy to drown. On a repeating timer, keep the interval long; behind a condition that stays true, gate with Do Once.
• Server node. Under a menu or key event, the chain moves to the server from here, so client-only nodes (Set Widget Text, Close Menu, the HUD nodes) have to come first.
• Style is the colour, and they are not equally legible: Action is gold

(#F7CA18), Important red (#F22613), Friendly green (#2ECC71), Info blue (#4B77BE). Gold and red carry furthest over the game world. The blue is a muted mid-tone that vanilla mostly emits as blank spacer lines, so a number you actually want read gets lost in it — which makes the default the worst choice for anything numeric.

The same top-right pop-up as Send Notification, but for everybody on the server at once. There is no Player pin: the node tells vanilla's notification system "no particular player", which the engine reads as "all of them". That is a single call rather than a loop, so it costs the same whether three people are online or sixty — and it reaches unmodified clients, so a server-only mod can announce things to a whole population.

When to use it

Server-wide announcements: restart warnings, an event starting, a rule change, a killfeed line everyone should see. When the message concerns one person, use Send Notification so you are not spamming the server. When it should sit quietly in the chat log instead of covering the corner of everyone's screen, use Broadcast Chat Message.

Pins

Title — the bold headline.

Detail — optional second line.

Show Seconds — 1 to 60.

Example

A restart warning that fires once per cycle: Every N Seconds (30) → Get Server Uptime → Greater Than (14100) → Branch → the True side runs Do Once → Broadcast Notification ("Restart", "Server restarts in 5 minutes — log out safely", 20 seconds). Without the Do Once, everyone gets the same warning twice a minute until the server goes down.

An event announcement built from live numbers: Get Online Player Count → Join Text ("Players online: " + the count) into the Detail pin.

Watch out

• Everyone means everyone, including the player whose action triggered it. When the trigger is personal — a kill, a purchase — send them their own Send Notification and broadcast only the part the server needs to know.
• It is easy to make this annoying. On a timer, keep the interval generous; behind a condition, gate it with Do Once or a stored flag so a condition that stays true does not re-announce on every check.
• This is a server node. Under a menu or key event the chain moves to the server from here on, so put client-only work (Set Widget Text, Close Menu, the HUD nodes) before it.
• Players still on the loading screen are not a reliable audience for a one-shot announcement. Anything a joining player must see belongs on On Player Ready with Send Notification instead.

Writes one line into the server's script log — the .RPT file in your server profile folder. Players never see it. This is the node you use to find out whether your graph is doing what you think: drop it into a chain and the log tells you the branch was reached and what the value was.

Every line is stamped with your mod's name in square brackets before your text, so you can filter the whole file down to your own output even on a server running a dozen other mods.

When to use it

Testing and troubleshooting. Put one on each side of a Branch and the log tells you which way the condition went; put one inside a loop and you can count the passes. For a record that must survive the restart and live in its own file, use Write To Log File. For anything a player should read, use Send Notification or Send Chat Message.

Example

Proving a reward chain fires: On Player Died → Is Valid (Killer) → Branch; the True side runs Get Player Name (Killer) → Join Text ("paid reward to " + the name) → Log Message, and the False side runs a Log Message reading "no killer — skipped". Two lines in the log and you know instantly whether the problem is the reward or the killer resolution.

Checking an unfamiliar value: Get Ground Surface → Log Message prints the surface names your map actually uses, so you can write the comparison against real text instead of guessing.

Watch out

• Nothing here reaches a player, ever. A "message" that never showed up in-game is usually this node when Send Notification was meant.
• The .RPT starts fresh each time the server launches, so a line you logged last session is gone. Use Write To Log File for anything you need to keep.
• Logging inside a fast timer or a per-player loop grows the file quickly and makes the interesting lines hard to find. Take the diagnostic logs back out once the graph works.
• This is a server node. Under a menu or key event the chain hands off to the server from this node onward, so client-only nodes — Set Widget Text, Close Menu, the HUD nodes — must sit before it.

Puts a line of text in one player's chat, exactly as if the server had spoken to them. It is the quiet channel: no box covering the screen, no timer, just a line in the log that scrolls with everything else. Vanilla clients receive it with no mod installed.

The Style setting picks which of the game's own chat colours the line is drawn in. It changes nothing else — every style goes to the same player, in the same place, with the same reliability.

When to use it

Feedback that is useful but not urgent: confirming a purchase, reporting a balance, answering a command. When the player must not miss it, use Send Notification — a box in the corner is far harder to scroll past. To say the same thing to everybody, use Broadcast Chat Message.

Pins

Player — who receives the line. Nobody else sees it.

Text — the line itself. Build it from live values with Join Text.

Style (panel) — Info, Action, Friendly or Important. Colour only.

Example

Reporting a stored score on request: On Key Pressed → Get Player Number (kills) → Join Text ("Kills this session: " + the number) → Send Chat Message (Style Info) with the event's Player wired in. The player presses their key and gets one line back, without a box interrupting them.

Confirming a reward: On Player Died → Is Valid (Killer) → Branch → True → Give Item To Player (Rag) → Send Chat Message ("Kill reward: 1 Rag", Style Friendly) on the Killer.

Watch out

• The Player pin goes straight to the engine with no check of its own — an empty player here is not a dependable no-op. Gate risky sources (the Killer of a self-inflicted death, a Get Nearest Player miss) behind Is Valid and a Branch.
• Chat scrolls away and fades. Anything the player has to act on belongs in Send Notification.
• Style is colour, not routing. "Important" does not make the line stickier, louder or more visible than "Info".
• This is a server node. Under a menu button or key press the chain hands off to the server here, so client-only nodes — Set Widget Text, Close Menu, the HUD nodes — must come before it in the chain.
• After a Delay only the carried player survives. Rebuild the text from the player after the wait, or stamp it on them beforehand with Set Player Text and read it back.
• Style is the colour, and they are not equally legible: Action is gold

(#F7CA18), Important red (#F22613), Friendly green (#2ECC71), Info blue (#4B77BE). Gold and red carry furthest over the game world. The blue is a muted mid-tone that vanilla mostly emits as blank spacer lines, so a number you actually want read gets lost in it — which makes the default the worst choice for anything numeric.

The pop-up box in the top-right corner of one player's screen: a bold title, an optional line of detail under it, and a countdown until it fades. This is vanilla's own notification system — the engine pushes the box to that player's client for you — so it works on a completely unmodified client. A server-only mod can talk to its players through this node and nobody has to install anything.

Because the message is aimed at one player, it is the node you reach for after something happened *to them*: they joined, they were rewarded, they broke a rule. Everyone else sees nothing.

When to use it

The default way to tell a single player something. To say it to the whole server instead, use Broadcast Notification. For a quieter line that lands in the chat log rather than covering the corner of the screen, use Send Chat Message. For a message only you should ever see, use Log Message. And when you want to control exactly how it looks and where it sits, build your own overlay with Show HUD Overlay and Set Text — at the cost of players needing the mod installed.

Pins

Player — who sees it. Everyone else is unaffected.

Title — the bold first line. Keep it short; it is a headline, not a sentence.

Detail — optional second line, for the explanation.

Show Seconds — how long the box stays. The editor accepts 1 to 60.

Example

The whole Welcome notification template (File → New from template) is two nodes: On Player Connected → Send Notification, with the event's Player wired into the Player pin, Title "Welcome!", Detail "Welcome to the server — good luck out there." and Show Seconds 8.

Building the text from live values is the same shape with one more step: On Player Died → Get Player Name (Victim) → Join Text ("You killed " + the name) → Send Notification on the Killer, so the message names the person they just dropped. That wiring, guarded by Is Valid on the Killer, is the Kill reward template.

Watch out

• The Player pin is handed straight to the engine with no check of its own. An empty player — the Killer of a bleed-out, a Get Nearest Player that found nobody — is not a reliable no-op here. Put Is Valid into a Branch and send on the True side.
• This node runs on the server. Under a client event (On Button Clicked, On Key Pressed) the chain hands off to the server from here onward, so any client-only work — Set Widget Text, Close Menu, the HUD nodes — has to come BEFORE it, or the editor rejects the graph.
• After a Delay only the carried player survives. A name or number you looked up before the wait is gone by the time the notification runs — re-derive it from the player, or stamp it on them first with Set Player Text and read it back.
• One box at a time is what a player can actually read. Firing one every second from a timer buries the message that mattered; for anything that repeats often, use a longer interval or drop to Send Chat Message.

Stamps a fresh copy of a layout inside a widget you already hold, and gives you the copy's own handle. This is how a list of unknown length gets on screen: the overlay layout holds an empty container, a second small layout describes one row or one card, and this node adds a copy per entry.

Nothing here is cached. Unlike Show HUD Overlay, which hands back the same overlay however often you call it, every run of this node creates another copy. That is exactly what a killfeed wants, and a trap for anything that should exist once.

When to use it

Repeated pieces: killfeed cards, scoreboard rows, one marker per objective. The containing overlay itself comes from Show HUD Overlay. To rebuild a whole list rather than grow it, run Clear Widget Children on the container first and then one Add per entry — that pair lets a list of any length refresh without old rows piling up.

Pins

Parent — the widget the copy is nested inside. Use a container from your overlay (a Find Child Widget on the Root), not the Root itself, so copies stack in the order you add them instead of landing on top of each other. An empty Parent creates nothing, and New Widget comes back empty.

Layout (property) — the layout to copy. Any attached layout works; a small one holding a single card is the usual shape.

New Widget — the copy's own root. Look up labels *inside this handle*, never from the overlay Root.

Example

Continuing a killfeed. A second layout killcard holds three text widgets named CardKiller, CardWeapon and CardVictim. Under On Client Message "kill": Show HUD Overlay (killfeed) → Scale For Screen → Add Widget From Layout (Layout killcard, Parent = Find Child Widget on the Root with Name "Cards") → Scale For Screen again, this time with Root Widget = New Widget and Layout killcard → three Set Text nodes, each fed by a Find Child Widget of New Widget → Auto-Destroy Widget After on New Widget after 6 seconds.

Watch out

• Search for children inside the New Widget. A name lookup walks the whole tree under whatever you hand it, so searching from the overlay Root always finds the *first* card's label — every kill would then rewrite card one.
• Scale each copy. Scale For Screen on the overlay does not reach a card added afterwards; run it again on New Widget, with the card's own layout selected.
• Nothing removes the copies for you. Pair with Auto-Destroy Widget After or Clear Widget Children, or a busy server buries the screen in cards.
• Client-side only: Server + Client project, and the node must come before any server action in its chain. Delay is a server node and cannot sit between two HUD nodes.

Books a widget's removal for a number of seconds from now, and carries straight on. The graph does not wait: the rest of the chain runs immediately, and the widget quietly disappears later on its own.

That "does not wait" is the whole point of the node. Delay is a server-side node, so it cannot sit between two HUD nodes — put one there and everything after it is handed to the server, where widgets do not exist. This node is the client's timer, and it is the supported way to make a HUD element temporary.

It removes; it does not fade. The widget is there and then it is not.

When to use it

Anything that should appear briefly and go: killfeed cards, a "+1 kill" flash, a pickup toast, a warning banner. For a HUD element that stays until something else happens, use Destroy Widget at that moment instead, or Set Widget Visible to keep it around unseen.

Pins

Widget — the widget to remove, usually the New Widget from Add Widget From Layout. An empty handle books nothing.

Seconds — from 0.1 up to 120. Six is the default and reads well for a killfeed; a card that stays longer than the next few kills turns the corner of the screen into a wall.

Example

A killfeed card that clears itself. Under On Client Message "kill": Show HUD Overlay (killfeed) → Scale For Screen → Add Widget From Layout (killcard into the container named "Cards") → Scale For Screen on the new card → Set Text on its labels → Auto-Destroy Widget After on the New Widget, Seconds 6.

The overlay itself is never removed — it is created once and reused — while each card lives six seconds and then goes.

Watch out

• The booking cannot be cancelled or shortened once made. Destroying the widget earlier by hand is safe, though: when the timer comes round there is simply nothing left to remove.
• Book it against a card, not against the Root of an overlay. An overlay is remembered by layout, and Destroy HUD Overlay is the node that removes one properly.
• Booking twice on the same widget books two removals; the second finds nothing and does nothing, which is harmless but a sign the chain is running more often than you think.
• Client-side only: Server + Client project, and the node must sit before any server action in its chain.

Empties a widget: everything inside it is removed, the widget itself stays. It walks the children one by one, taking care to note the next one before removing the current one, so a full list is cleared in a single pass however long it is.

This is the other half of Add Widget From Layout. Clear the container, then add one copy per entry, and a list of any length rebuilds itself without old rows piling up underneath the new ones.

When to use it

Any list that is refreshed rather than appended to: a scoreboard that redraws every few seconds, a nearby-players panel, a quest list. For a feed where old entries should linger and then go on their own — a killfeed — leave the container alone and give each card an Auto-Destroy Widget After instead. To remove a single widget you are holding, use Destroy Widget; to take the whole overlay down, Destroy HUD Overlay.

Pins

Widget — the container to empty, normally a Find Child Widget on the overlay Root. Aim carefully: pointing this at the Root itself empties the entire overlay, headers and frames included, and only Destroy HUD Overlay followed by a fresh show will bring them back.

Example

A scoreboard that redraws on every refresh. The server's ranked loop sends one Broadcast Client Message named "board_start" before it begins, then one "row" per player. On the client: On Client Message "board_start" → Show HUD Overlay (scoreboard) → Scale For Screen → Clear Widget Children on Find Child Widget "Rows". A second client graph on On Client Message "row" then adds one row per message. Rows never double up, because the container was emptied before the first of them arrived.

Watch out

• Order the messages so the clear always lands before the rows. Two graphs listening for two different message names is the clean way to guarantee it; clearing inside the per-row handler would wipe out the previous row every time.
• The cleared children are gone, not hidden. Any widget handle your graph is still holding from before the clear now points at nothing, and nodes using it do nothing.
• An empty Widget handle clears nothing and says nothing.
• Client-side only: Server + Client project, and before any server action in the chain.

Takes an overlay off the screen and forgets it, so a later Show HUD Overlay builds a fresh one from the layout. It finds the overlay by its layout rather than by a widget handle, so you can remove it from anywhere on the client without threading the Root through your graph.

This is a teardown, not a pause. Everything done to that overlay goes with it: text you set, sizes you computed, cards you added, and the screen scaling.

When to use it

When a HUD element is finished — the round ended, the player left the zone, the event is over. For something you will show again in a moment, Set Widget Visible on the Root is cheaper and keeps the contents intact. To empty a list but keep its frame, use Clear Widget Children; to remove one card inside an overlay, Destroy Widget.

Pins

Layout (property) — the same layout you passed to Show HUD Overlay. A different layout removes a different overlay, and a layout that was never shown does nothing at all.

Example

A round timer that vanishes when the round ends. The server sends one Broadcast Client Message named "round_end" when the clock runs out; on the client, On Client Message "round_end" → Destroy HUD Overlay (Layout roundtimer). Every player's timer disappears together, and the next round's first "round_tick" message rebuilds it through Show HUD Overlay.

Watch out

• After a destroy, the next Show returns a brand new, empty overlay. Re-run Scale For Screen and re-set every text — nothing survives.
• Client-side only: the project must be Server + Client, and the node must sit before any server action in its chain, or it lands in the server half and never touches the screen.
• Destroying an overlay that is not showing is safe and does nothing, so you do not need to track whether it is up.

Removes one widget from the screen, along with everything nested inside it. It is immediate and permanent: the handle you were holding is spent, and only Add Widget From Layout or a fresh Show HUD Overlay can produce another.

When to use it

Taking down a single piece you created — one card, one row, one marker — when your graph knows the moment it should go. When the moment is simply "a few seconds from now", Auto-Destroy Widget After schedules it for you and needs no timer. To empty a container but keep it, use Clear Widget Children; to remove a whole overlay, use Destroy HUD Overlay, which also forgets it so a later show rebuilds it.

Example

A "capturing" marker that disappears the moment the point is taken. The server sends Broadcast Client Message "capture_start" and later "capture_done". On the client, the first message shows the overlay and adds a marker card with Add Widget From Layout; the second — On Client Message "capture_done" → Destroy Widget on Find Child Widget of the overlay Root, Name "Marker" — takes it away again.

Watch out

• Do not point it at the Root of an overlay from Show HUD Overlay. That overlay is remembered by layout, and removing it this way skips the bookkeeping; Destroy HUD Overlay is the node that both removes it and forgets it.
• To hide something you will want back, use Set Widget Visible. Destroying and rebuilding loses every text you set and every size you computed, and needs Scale For Screen run again.
• An empty Widget handle destroys nothing and reports nothing, so a mistyped name in Find Child Widget looks the same as a widget that refuses to go away.
• Client-side only: Server + Client project, and before any server action in the chain.

Shrinks a text widget to exactly the width of the text currently in it, plus whatever padding you ask for. A fixed-width label leaves a short name rattling around inside a wide dark box; this measures the string as it actually draws and sets the widget's width to match.

Only the width changes. The height is handed back as "fill", which keeps a label that is not exact-height at the full height of the row it sits in — the shape a row of labels wants. And a widget whose text is empty collapses to nothing rather than keeping the width it was laid out with, so an optional label that is switched off leaves no hole beside the others.

When to use it

Any label whose content varies: a player name, a weapon name, a score. Put several fitted labels inside a spacer and the row packs tight by itself. When you need the number rather than the effect — to position the next widget by hand, or to size a background panel around a whole row — read it with Text Width and use Set Widget Size or Set Widget Position.

Pins

Text Widget — must be an actual text widget; anything else measures 0 and collapses.

Padding (px) — breathing room added to the measured width. Optional; leave it out for a flush fit, 8–14 px is comfortable inside a coloured background.

Example

A killfeed card that hugs its names. On the card layout, CardKiller and CardVictim are text widgets inside a spacer. Under On Client Message "kill": Show HUD Overlay → Scale For Screen → Add Widget From Layout (the card) → Scale For Screen on the new card → Set Text on CardKiller → Fit Widget To Text on CardKiller (Padding 10) → the same pair for CardVictim. Long names and short names both come out evenly spaced.

Watch out

• Set the text first. This node measures what is laid out at the moment it runs, so fitting before Set Text sizes the widget around the previous string — usually the layout's placeholder.
• Scale before you fit. Scale For Screen changes the text size, so a fit taken beforehand is a 1080p width applied to a 4K label.
• Empty text collapses the widget to zero width. That is deliberate, but it means a label whose value failed to arrive disappears rather than showing an empty box — check Find Child Widget first when a row looks short.
• A non-text widget silently ends up at zero width. Fit the label, not the panel behind it.
• Client-side only: Server + Client project, and before any server action in the chain.

Makes a HUD the same apparent size on every monitor. DayZ layouts are authored at 1080p, and anything the layout editor marks "exact" is measured in real, physical pixels — so an overlay that fills a 1080p screen takes up two-thirds the height on 1440p and half of it on 4K. This node walks the layout you name and multiplies every exact position, exact size and exact text size by the screen height divided by 1080. It is the same yardstick vanilla uses to size its own tabbed screens.

It works from the layout as you authored it, so it knows which widgets are exact and which are proportional. Anything positioned or sized as a fraction of its parent already scales by itself and is deliberately left alone — multiplying a 0.5 would fling it off screen.

When to use it

Immediately after Show HUD Overlay, and again after every Add Widget From Layout. Each created piece needs its own call with its own layout selected: scaling the overlay does not reach a card stamped into it afterwards.

Pins

Root Widget — the handle whose contents to scale: the Root from Show HUD Overlay, or the New Widget from Add Widget From Layout.

Layout (property) — the layout that widget was built from, and it must match. Text sizes cannot be read back from a live widget, so they are taken from the layout file itself; naming a different layout scales the wrong things.

Example

The killfeed, scaled twice. On Client Message "kill" → Show HUD Overlay (killfeed) → Scale For Screen (Root Widget = Root, Layout killfeed) → Add Widget From Layout (Layout killcard, Parent = the container named "Cards") → Scale For Screen again (Root Widget = New Widget, Layout killcard) → Set Text on the card's labels.

Watch out

• It multiplies what is there now, so running it twice on the same overlay scales it twice. Show HUD Overlay hands back the *same* overlay on every message, so a chain that shows and scales on each kill compounds the overlay's size on any screen that is not 1080p. Scale the overlay behind a Do Once (on its own branch of a Sequence) and keep the per-message work on the other branch — cards added later still get their own scaling call, since each card is new.
• Only the layout's root widget and widgets that have a name are touched. Give a name in the layout editor to anything that must scale; unnamed decoration keeps its authored pixels.
• Scale first, then measure. Text Width and Fit Widget To Text report the text as it draws at that moment, so measuring before scaling hands you 1080p numbers.
• A layout that uses no exact values has nothing to scale and this node does nothing — correct, not a fault.
• On a 1080p screen the factor is exactly 1 and nothing visibly changes. Test at another resolution before deciding it works.
• Client-side only: Server + Client project, and before any server action in the chain.

Writes a line of text into a text widget. This is the node that actually puts a value on the screen — everything else in the HUD family is plumbing to reach the right widget with the right handle.

It only works on text widgets. Give it a panel, an image or a container and nothing happens, with no error anywhere, so a value that never appears is usually a widget of the wrong class rather than a broken wire.

When to use it

Every number, name or message a HUD shows. For a widget in an open menu, Set Widget Text does the same job by picking the widget from a dropdown. To assemble the string first, use Join Text; to force a house style, Change Text Case.

Pins

Widget — a handle, normally from Find Child Widget. An empty handle is a silent no-op.

Text — a number wired straight onto this pin converts to text on its own, so you do not need a conversion node. The Number pins on On Client Message are decimals, though, so send a score or a rank through To Whole Number (or Round Number) first if you want "7" and not a trail of decimal places.

Example

A scoreboard row. On the server, For Each Player (Ranked) sends one Broadcast Client Message named "row" per player, carrying Get Player Name in Text 1, the loop's Rank in Number 1 and its Value in Number 2. On the client, On Client Message "row" → Show HUD Overlay (scoreboard) → Add Widget From Layout (scorerow into the container named "Rows") → three Set Text nodes on Find Child Widget lookups of the new row for RowRank, RowName and RowScore, with the two numbers passed through To Whole Number on the way in.

Watch out

• Set the text *before* Fit Widget To Text or Text Width. Both measure what is laid out at that instant, so fitting first sizes the widget around the previous string.
• The widget must be a text widget in the layout editor. A styled panel with a label inside it means the label is your target, not the panel.
• An empty Widget handle does nothing quietly — check the Name spelling and the Parent on the Find Child Widget feeding it.
• Client-side only: Server + Client project, and before any server action in the chain.

Moves a widget to an X/Y spot measured from its parent's top-left corner — not from the corner of the screen. X grows to the right, Y grows downward, and a widget living inside a container moves within that container.

This is deliberate hand layout. DayZ's automatic arrangement helps only in particular set-ups — "size to content" exists on spacer widgets, never on the panel that draws your background — so when a row has to pack tightly around text of unknown length, measuring each label with Text Width and placing the next one yourself is the approach that behaves the same on every machine.

When to use it

Laying a row out from measured widths, centring something whose size you just computed, nudging a card into place. To change how big a widget is instead, use Set Widget Size; to shrink a text widget onto its own text, Fit Widget To Text.

Pins

X (px) / Y (px) — pixels for a widget the layout editor marks as an exact position on that axis. A widget positioned proportionally reads them as a fraction of its parent, where 0.5 is the middle and 300 is far off screen.

Example

A label and value that stay tight together whatever the label says. Layout banner holds text widgets Label and Value inside a panel. On the client: Show HUD Overlay (banner) → Scale For Screen → Set Text on Label → Fit Widget To Text on Label with 8 px padding → Set Widget Position on Value, with X from a Add of Text Width of Label plus 8, and Y of 0.

Watch out

• Measure after the text is set and after scaling, in that order. Text Width reports what is drawn right now, so a width taken before Set Text describes the old string and one taken before Scale For Screen is a 1080p number you then use on a 4K screen.
• Scale For Screen reads positions back and multiplies them, so a position set before it is scaled too, and one set after stands as raw pixels.
• Positions are relative to the parent. Moving a killfeed card by 200 px moves it 200 px inside its container, which may be nowhere near 200 px down the screen.
• Client-side only: Server + Client project, and before any server action in the chain.

Sets a widget's own width and height. Use it when the size depends on something the layout could not know in advance: a scoreboard panel that grows a row at a time, a background that has to be as wide as the name printed on it.

The numbers mean pixels only for a widget the layout editor marks as an exact size on that axis. A widget sized proportionally reads them as a fraction of its parent instead, and a "640" sent to one of those throws it far off screen — so set the size mode in the layout editor before you drive it from a graph.

When to use it

Whenever the size is arithmetic: rows times row height, or a sum of measured label widths from Text Width. When you only want a text widget to hug its own text, Fit Widget To Text does it in one node and needs no measuring. To move a widget rather than resize it, use Set Widget Position.

Example

A scoreboard panel that grows with the board. After its ranked loop, the server sends a closing Broadcast Client Message named "rows" carrying Get Online Player Count in Number 1. On the client: On Client Message "rows" → Show HUD Overlay (scoreboard) → Scale For Screen → Set Widget Size on Find Child Widget "Board", Width 640 and Height from a Multiply of Number 1 by 34 — one row of 34 px per player.

Watch out

• Order against scaling matters. Scale For Screen reads a widget's current size back and multiplies it, so a size set *before* the scaling gets scaled with everything else, and a size set *after* stands as raw physical pixels — tiny on a 4K screen. Pick one and be consistent: sizes computed from Text Width are already in screen pixels, because they measure text as it draws.
• Height and width are both applied every time, so passing a "keep it as it is" value means reading nothing back — decide both numbers.
• An empty Widget handle does nothing quietly.
• Client-side only: Server + Client project, and before any server action in the chain.

Shows or hides a widget without destroying it. A hidden widget keeps everything — its text, its size, its position, its children — and comes back exactly as it was. Hiding a parent hides everything inside it, so one call on an overlay's Root takes a whole HUD off screen and one more brings it back.

When to use it

Toggles and optional parts: a scoreboard on a key, a warning line that only appears when it matters, a card that is built once and shown when needed. Compare Destroy HUD Overlay, which throws the overlay away so the next show rebuilds it from the layout, and Destroy Widget, which removes one widget for good.

Example

An F5 scoreboard toggle, from an empty project. On Key Pressed with the key F5 and "Scoreboard" as its name in Controls → Show HUD Overlay (scoreboard) → Scale For Screen → Flip Flop: path A → Set Widget Visible (Widget = Root, Visible ticked); path B → Set Widget Visible (Widget = Root, Visible unticked).

Because Show HUD Overlay hands back the same overlay every time, the first press builds the board and every press after it only flips the switch.

Watch out

• A widget authored hidden in the layout editor stays hidden when you show its parent — its own state is separate, so show it too.
• Hiding is not removing. A hidden killfeed card still exists and still counts toward the pile; use Auto-Destroy Widget After or Clear Widget Children for cards you are finished with.
• An empty Widget handle does nothing at all, so a mistyped name in Find Child Widget looks exactly like a toggle that "does not work".
• Client-side only: the project must be Server + Client, and the node must come before any server action in its chain.

Puts one of your layouts on screen as an overlay: drawn on top of the game world, always there, no mouse cursor and no pause. You design the layout in NodeZ's layout editor and attach it to the project; this node loads it on the player's own machine and hands back the Root widget — the handle every other HUD node works from.

The overlay is created once and remembered, keyed on the layout. Run the node again and you get the same overlay back rather than a second copy stacked on top, which is what makes it safe at the top of an event that fires over and over. Nothing takes an overlay down by itself: it survives death and respawn until Destroy HUD Overlay removes it or the player leaves.

When to use it

Anything permanently on screen that you own — a killfeed, a scoreboard, a round timer, a zone warning. An overlay takes no input, so for something the player clicks build a menu layout and drive it from the UI events (On Button Clicked) instead. For repeated pieces *inside* an overlay — one card per kill, one row per player — use Add Widget From Layout: that node makes a fresh copy every time, this one hands back the same overlay every time.

Pins

Layout (property) — one of the layouts attached to this project. Pointing at a layout that is not attached is an error the editor reports before you build.

Root — the top widget of the overlay. Send it to Scale For Screen first, then to Find Child Widget to reach the named widgets inside. It comes back empty if the layout could not be loaded, and every HUD node downstream then quietly does nothing.

Example

A killfeed, from an empty project. Build a layout killfeed whose root holds a container widget named Cards. On the server: On Player Died → Broadcast Client Message named "kill", carrying the killer's Get Player Name in Text 1 and the victim's in Text 3. On the client: On Client Message listening for "kill" → Show HUD Overlay (Layout killfeed) → Scale For Screen → Add Widget From Layout with Parent set to Find Child Widget of the Root, Name "Cards".

The first kill builds the overlay; every kill after that reuses it and only adds a card.

Watch out

• This runs on the player's machine, so players must have the mod and the project must be set to Server + Client. On "Server only" the editor blocks the build and says so; on a server-only *install* the server half still runs and the HUD is simply never there, with nothing in the logs to explain it.
• Run Scale For Screen straight after. Layouts are authored at 1080p and exact sizes are real pixels, so on 1440p or 4K an unscaled overlay shrinks into a corner.
• Everything from the first server node onward in a chain is handed to the server, and HUD nodes there do nothing. Delay is a server node, so it cannot sit in the middle of a HUD chain — use Auto-Destroy Widget After when you need timed removal.
• Take an overlay down with Destroy HUD Overlay, not Destroy Widget on the Root. Only the first also forgets the overlay, so a later Show builds it again.

Seats an item that already exists into a matching attachment slot on a target — a scope onto a rifle, a wheel onto a car, a battery into a flashlight. You do not pick the slot: the engine reads which slot the item belongs in from its own config and finds a free one on the target. The move is server-authoritative, so all clients see the attachment appear.

When to use it

This is the only attach node for an item you already have a wire to. If you want to create a brand-new attachment from a classname, that is Attach New Item (or Attach Item To Item when you are chaining off items other nodes made). If the item belongs in cargo rather than a slot, use Move Item Into Container — a wheel goes in a slot, a jerrycan goes in cargo.

Pins

Attach To — the entity receiving the attachment: a weapon, a vehicle, a piece of clothing. Attached — false when the target has no free slot that matches the item.

Example

Fitting an optic you are holding onto the rifle on your shoulder: On Press Item Action (Item Class ACOGOptic, Prompt Text "Fit to rifle") → Get Attachment In Slot (Entity = the event's Player, Slot Name = "Shoulder") → Is Valid → Branch. On True, Attach Existing Item (Item = the event's Item, Attach To = that slung rifle) → Branch on Attached → Send Notification "Optic fitted" or "No free optics slot". On False, Send Notification "Sling a rifle first".

Watch out

• Attached is false when the matching slot is already occupied or the target simply has no such slot — an item can only ever land in a slot its config names. Branch on it.
• Both wires must be real entities. Empty hands, a failed search, or an empty Get Player Vehicle all produce empty wires — gate on Is Valid before attaching.
• Attach To will not take the Target of On Press Interaction or On Hold Interaction. Those hand you a plain world object, and the editor refuses that wire. Send it through As Item first — but that only converts things that really are items, so a car or a building comes back empty. For a vehicle, take an already-entity source such as Get Player Vehicle or the Vehicle from On Player Entered Vehicle.

Creates a brand-new item from a classname and seats it in a matching attachment slot on the target, in one step — a battery into a torch, an optic onto a rifle, a wheel onto a car. You never name the slot: the engine reads which slot the new item belongs in from the item's own config and puts it in the first free one. This is the same inventory call vanilla uses when it builds a kitted-out weapon.

An attachment slot is not cargo. A suppressor goes in a slot; a jerrycan goes in a car's cargo grid.

When to use it

Finishing an item you just created: the battery for the flashlight you handed out, the optic on the rifle. When the attachment already exists somewhere and you have a wire to it, use Attach Existing Item instead. Attach Item To Item does the same creation as this node but first checks that the class is not blank and the target is real, and it hands back an item rather than an entity — prefer it when the classname comes from a config that may be empty. For cargo rather than a slot, Spawn Item In Cargo.

Pins

Target — the entity that receives the attachment: a weapon, a vehicle, a piece of clothing, a player.

Item Class — the panel picker, or a wire that overrides it (from Get Config Text or Random Config Text, say).

Attachment — the created item, as an entity. Tag Item and Set Item Lifetime take it directly; the item-typed setters like Set Item Health need As Item in between.

Example

A flashlight that actually lights: On Player Ready → Give Item To Player (Item Class Flashlight) → Attach New Item (Target = the Item output of Give Item, Item Class Battery9V) → Send Notification ("Kit", "Your flashlight is charged").

Wiring Target from Give Item's Item output is what makes it land in *that* flashlight rather than somewhere else in the inventory.

Watch out

• If the target has no slot that fits, or the fitting slot is taken, nothing attaches and Attachment comes back empty. Check it with Is Valid before using it.
• This node does not check its own inputs. An empty Target wire — a failed lookup, or Get Player Vehicle for a player on foot — puts an error in the server's script log instead of quietly skipping. Gate it with Is Valid, or use Attach Item To Item, which checks for you.
• Classnames are case-sensitive: Battery9V, not battery9v.
• Attaching something to a player fires On Item Attached — including your own attach. A graph that attaches inside that event will trigger itself again.
• Do not attach gear in the same instant as Teleport Player: the item never reaches the other clients and the player looks unequipped to everyone else. Put a Delay of about 2 s between them and run Resync Player Gear afterwards.

Pulls an item out of whatever is carrying it and drops it on the ground. The node walks up the carrying chain to the top — the player wearing the backpack the item sits in, the crate the bag is stored in — and drops the item at that carrier's feet, using the same server-side drop the vanilla skinning action uses. Every client sees it land.

When to use it

Forced disarms, spilling loot, making a player physically let go of something. If the item should cease to exist rather than hit the ground, use Delete Entity. If it should go somewhere specific instead of the floor, use Move Item Into Container. To strip a player of everything at once, Clear Inventory is the bigger hammer.

Pins

Dropped — false when there was nothing to do: the item is already lying on the ground, or the wire was empty.

Example

A safezone that disarms on entry: Player Entered Zone (trader camp, radius 50) → Get Item In Hands (Player) → Drop Item To Ground → Send Notification "No weapons in the safezone."

Watch out

• The item lands at the feet of the top-level carrier, not where the item's immediate container is. An item buried in a pouch inside a worn backpack drops at the player.
• An empty wire (empty hands, a failed search) is handled quietly — Dropped just comes back false — so it is safe to run without checking first, but branch on Dropped when you need to know it actually happened.

Takes an item that already exists — on the ground, in a player's hands, inside another bag — and moves it into a container's cargo space. The move is server-authoritative, the same inventory channel the engine itself uses, so every client sees the item land in its new home. Nothing is created or destroyed: it is the one node for relocating a real item you already have a wire to.

When to use it

Reach for this when the item exists and you want it somewhere specific. If you want to conjure a new item inside a container, that is Spawn Item In Cargo. If the item should sit in an attachment slot (a scope on a rifle, a wheel on a car) rather than in cargo, use Attach Existing Item — cargo and attachment slots are different things and this node only does cargo. To hand an item to a player "anywhere it fits", Give Item To Player creates a new one instead.

Pins

Container — anything with cargo space: a crate, barrel, backpack, tent, or vehicle. It must have room for the item's size. Moved — false when the item did not fit. The item stays where it was.

Example

A deposit box: On Hold Interaction (Object Class WoodenCrate, Prompt Text "Deposit", Hold Seconds 3) → Move Item Into Container, with Item fed by Get Item In Hands on the event's Player and Container fed by As Item on the event's Target → Branch on Moved → Send Notification "Stored" or "No room".

The As Item step is the part people miss. An interaction event hands the crate over as a plain world object, and Container wants an entity, so the editor refuses the wire until you cast it.

Watch out

• Moved comes back false more often than you expect — a full container, an item too big for the grid. Always branch on it instead of assuming success.
• Container must be a real entity. World objects — an interaction event's Target, anything out of For Each Object Near — arrive as plain objects and will not wire in at all; run them through As Item first. When the source can also come up empty (a search, Get Player Vehicle, or a cast of something that is not an item), gate on Is Valid as well: running this with an empty Container wire fails at run time.
• Cargo only. A rifle has attachment slots, not cargo; trying to "move" a suppressor onto it does nothing useful — that is Attach Existing Item's job.

Deletes up to a set number of items of one class from an entity's inventory. It walks the whole inventory tree — hands, pockets, worn clothing and everything inside it, a backpack's cargo, the magazine attached to a rifle — and deletes the first matches it meets, subtypes included. The items are destroyed, not dropped.

Removed reports how many it actually took. That number is the point of the node: it is how you tell "they paid the toll" from "they were one short", in one step, with no separate count.

When to use it

Taking things away: contraband sweeps, an entry fee at an arena, the ingredient half of a craft. To empty someone completely, Clear Inventory is one node. To look before you take, Has Item In Inventory and Count Items In Inventory answer without changing anything, and Find Item In Inventory hands you the item itself if you would rather modify it than delete it.

Pins

Container — whose inventory to search. A player wires straight in; so does a tent, a car, or a crate.

How Many — the ceiling. It stops as soon as it has taken that many.

Item Class — the panel picker, or a wire that overrides it.

Removed — how many were destroyed, 0 to How Many.

Example

A two-can trade you can perform from your hands: On Press Item Action (Item Class TacticalBaconCan, Prompt Text "Trade in") → Remove Items Of Type (Container = the event's Player, Item Class TacticalBaconCan, How Many 2) → Equals (Numbers) (Removed, 2) → Branch → true: Give Item To Player (BandageDressing) and Send Notification ("Trade", "Two cans for a bandage") → false: Send Notification ("Trade", "You need two cans").

The Branch is not decoration. Without it a player with one can loses that can and gets nothing back.

Watch out

• Deleting a container deletes what is inside it. Removing a backpack takes its whole cargo with it.
• Subtypes count. Naming a base class removes every variant descended from it, which is occasionally what you want and often a surprise.
• Worn gear is included, not just pockets — a hat on someone's head is removed like anything else. If only carried items should go, find them yourself with Find Item In Inventory and delete with Delete Entity.
• Classnames are case-sensitive.
• Removed can be less than How Many. Branch on it before paying anything out.
• Sweeping every player with For Each Player hits corpses too — they count as players until they despawn. Gate on Is Player Alive when a body should keep its loot.

Decides *what* is inside a container: Water, Clean Water, Vodka, Beer, Gasoline, Diesel, Disinfectant, Saline, or None. These are the game's own liquid types, so the item's label and what drinking it does to a player follow automatically.

It does not change *how much* is in there. An empty canteen set to Clean Water is still an empty canteen — pair this node with Set Item Quantity to put something in it. And the amount already inside is not thrown away: setting a half-full canteen to Gasoline gives you half a canteen of gasoline.

When to use it

Filling containers for players: a canteen of clean water at spawn, a canister of fuel as a reward, a purify prompt on a held bottle. To read what is in there, Get Container Liquid returns the same words as text for Text Equals. To top up a vehicle instead of a container, Refuel Vehicle is the node.

Pins

Container — the item to fill, item-typed. Give Item To Player, Find Item On Player and the held-item events wire straight in; entity-shaped sources need As Item between them.

Liquid (panel) — one of the nine types. "None" empties the type without touching the amount.

Example

A canteen of clean water in every spawn kit: On Player Ready → Give Item To Player (Item Class Canteen) → Set Container Liquid (Container = the Item output, Liquid "Clean Water") → Set Item Quantity (Item = the same Item, Mode "Fill To Max") → Send Notification ("Kit", "A full canteen of clean water").

Watch out

• Water and Clean Water are not the same thing. Plain Water is the unpurified kind that can make a player ill; Clean Water is the safe one. Handing out "Water" as a reward is a slow way to poison your server.
• Items that cannot hold liquid ignore this node, and an empty item wire is skipped silently.
• Setting the type never adds any liquid. If the container was empty it stays empty and the player sees nothing change — that is the most common "it did not work".
• Gasoline and Diesel in a drinking container are perfectly legal as far as the engine is concerned. Nothing stops a player drinking them.

Cooks or spoils a piece of food instantly, jumping it to the stage you pick: Raw, Baked, Boiled, Dried, Burned or Rotten. It is the same state change a fireplace produces over several minutes, applied in one node — the item's name, its look and what it does to whoever eats it all follow the new stage.

Only food responds. Anything else wired in is skipped silently, so a graph that runs over mixed inventory does not need to filter first.

When to use it

Food as a reward or a punishment: a hot cooked meal at spawn, a stash that rots while nobody visits, a "campfire in a box" prompt. To read the current stage use Get Food Stage, which gives the same words back as text — compare it with Text Equals. Cooking is not the same as heat: Set Item Temperature makes a meal warm without cooking it, and this node cooks without making it warm.

Pins

Food — the item to cook, item-typed. The held-item events, Give Item To Player and Find Item On Player fit directly; entity-shaped sources go through As Item first.

Example

Roasting an apple by hand: On Hold Item Action (Item Class Apple, Prompt Text "Roast", Hold Seconds 4) → Set Food Stage (Food = the event's Item, Stage "Baked") → Set Item Temperature (Item = the same Item, Degrees 60) → Send Notification ("Roasted", "It smells good").

Stage first, temperature second: the first makes it cooked, the second makes it hot. Without the second node the player eats a baked apple straight from the fridge.

Watch out

• Only food with cooking stages changes. Sealed food and drinks have nothing to move through, so the node does nothing to them.
• Rotten is a real stage, not a cosmetic one — food set to Rotten makes people sick when they eat it. Say so in a notification if you use it as a joke.
• The stage does not change the quantity. A half-eaten steak stays half-eaten; use Set Item Quantity for that.
• The item wire is skipped when empty, so a lookup that found nothing fails silently. Check with Is Valid when it matters.

Sets an item's condition — the Pristine / Worn / Damaged / Badly damaged / Ruined ladder players see in their inventory. Three modes decide what the Value pin means. Set Value writes raw health points, whose maximum comes from the item's own config. Set Percent (0-1) writes a fraction, 1 being perfect and 0 ruined. Repair Full puts it back to new and ignores Value altogether.

Percent is the mode to reach for. Raw values only make sense once you know that item's maximum, and the same "1" means pristine in one mode and nearly destroyed in the other.

When to use it

Handing out gear in a deliberate state: a worn rifle as a low-tier reward, a pristine one as a high-tier one, a repair bench that restores what a player is carrying. Repair Entity and Damage Entity work on anything at all — vehicles, creatures, world objects — while this node is the item-shaped one, with modes and a zone. To read the current condition, Get Item Health gives you both the raw number and the 0-1 percentage.

Pins

Item — item-typed. Outputs from Give Item To Player, Find Item On Player and the held-item events fit straight in; Get Item In Hands, Find Item In Inventory and other entity-shaped sources go through As Item first.

Value — health points in Set Value, a 0-1 fraction in Set Percent, unused in Repair Full.

Zone (panel) — a named damage zone instead of the whole item. Leave it blank unless you know the item has zones; vehicles do, most hand-held items do not.

Example

A rifle service on login: On Player Ready → Find Item On Player (Item Class M4A1) → Branch on Is Valid of that item → true: Set Item Health (Item = the found rifle, Mode "Repair Full") → Send Notification ("Armoury", "Your rifle has been serviced").

The Branch is doing real work here, because this node does not check its own Item pin.

Watch out

• Unlike most item nodes, an empty Item wire is not skipped — it puts an error in the server's script log. Gate uncertain lookups with Is Valid as in the example.
• The Value pin changes meaning with the mode. Switching to Set Percent and leaving 100 in the box, or to Set Value and typing 1, both produce a surprise.
• Zone names are exact and case-sensitive, and a zone the item does not have does nothing at all — no error, no change.
• Repair Full ignores Value entirely.
• Ruining an item a player is wearing does what ruining always does: it stops protecting them. That is a fine punishment, but say so in a notification or it reads as a bug.

Sets the despawn clock on an item lying in the world. DayZ's cleanup system gives every dropped item a lifetime and removes it when the countdown runs out; this node writes both that item's full lifetime and the time it has left, so the clock restarts from the number you give.

Only items in the world are on that clock. Something in a player's inventory is not counting down at all.

When to use it

Event loot that should tidy itself up, so an airdrop or a reward pile does not sit there until the next restart. It is the natural partner of Spawn Item, which creates items with no cleanup timer at all — a lifetime here is how you hand one back. To read the remaining time, Get Item Lifetime gives Seconds Left and Max Seconds. To remove something immediately instead of eventually, Delete Entity or Delete Items In Radius.

Pins

Item — the item, as an entity. Both item and entity wires fit: the Item output of Spawn Item, of Spawn Item In Cargo, or anything found by Find Item In Inventory.

Seconds — the new lifetime. 3600 is an hour, 86400 a day.

Example

An event drop that clears itself after ten minutes: On Player Died → Spawn Item (Item Class Mag_STANAG_30Rnd, Position from Get Player Position on the Victim) → Set Item Lifetime (Item = the Item output, Seconds 600) → Tag Item ("drop").

Watch out

• A short lifetime on something a player is expected to walk to is a trap. Ten minutes is generous for a body drop and mean for a hidden stash.
• Picking the item up and dropping it again is up to the game's own rules from then on; this node writes the clock once, it does not keep enforcing your number.
• The item wire is skipped when empty, so a spawn that failed on a bad classname leaves nothing to time.
• Cleanup is not instant. The system sweeps periodically, so an item can outlive its number by a little.

Sets the number an item carries — the stack size on rags, the fill level in a canteen or a fuel canister, the charge on a battery. It is the same quantity the game itself changes when a player drinks or a stack is split, so the new value shows up on their screen straight away.

Three modes. Set writes the number you give. Add adds it to what is already there. Fill To Max tops the item up to its own capacity and ignores the Amount pin entirely — reach for that instead of typing a big number and hoping.

When to use it

Whenever an item should arrive part-used or full: a half-empty canteen at spawn, a full canister as a reward, a stack of four rags. For rounds in a magazine prefer Set Magazine Ammo, which talks to the magazine's own ammo count. To see the current value and the ceiling, use Get Item Quantity — its Max Quantity output tells you what Fill To Max would do.

Pins

Item — the item to change, item-typed. Wires from Give Item To Player, Find Item On Player and the held-item events fit directly; entity-shaped sources (Get Item In Hands, Find Item In Inventory, the Item output of Spawn Item In Cargo) need As Item in between.

Amount — in the item's own units, whatever the item counts in. Ignored in Fill To Max mode.

Example

A spring you can drink from by hand: On Hold Item Action (Item Class Canteen, Prompt Text "Fill from spring", Hold Seconds 3) → Set Container Liquid (Container = the event's Item, Liquid "Clean Water") → Set Item Quantity (Item = the same Item, Mode "Fill To Max") → Send Notification ("Canteen", "Filled with clean water").

Liquid type and amount are two different things: the first node decides *what* is in the canteen, this one decides *how much*.

Watch out

• Fill To Max ignores Amount. Changing the mode without noticing is the usual reason a carefully typed number does nothing.
• Items with no quantity — a rifle, a helmet — ignore this node completely. Get Item Quantity reporting a Max Quantity of 0 is the tell.
• An empty Item wire is skipped silently, so a lookup that found nothing simply does not happen. Check with Is Valid when the difference matters.
• Do not wire Random Number into Amount *and* into the notification that announces it: a volatile value re-rolls at every use, so the player is told one number and given another. Store the roll once with Set Player Number and read it back with Get Player Number.

Sets how hot or cold an item is, in degrees Celsius. It is a one-time write, not a setting: from that moment the world starts pulling the item back toward the temperature around it, so a steak you heat to 80 is merely warm a few minutes later and cold by nightfall.

Heat is not cooking. A raw steak at 80 degrees is a hot raw steak — Set Food Stage is what makes it baked.

When to use it

Warm rewards and cold punishments: a hot meal handed out at spawn, a frozen stash, a meal that arrives with the heat already in it so the player gets the benefit of eating it warm. To read the current value, Get Item Temperature.

Pins

Item — item-typed. Give Item To Player, Find Item On Player and the held-item events fit directly; Get Item In Hands and other entity-shaped sources go through As Item first.

Degrees (°C) — the temperature to write.

Example

Breakfast in the spawn kit: On Player Ready → Give Item To Player (Item Class TacticalBaconCan) → Set Item Temperature (Item = the Item output, Degrees 45) → Send Notification ("Kit", "Hot breakfast, eat it while it lasts").

Watch out

• The value drifts. Anything you set here is temporary by design, so it is worth doing at the moment the player receives the item rather than minutes earlier.
• Heating does not cook and cooling does not spoil. Use Set Food Stage for those.
• An empty Item wire is skipped silently, so a lookup that found nothing simply does nothing.
• Items that have no use for temperature accept the value and ignore it in play.

Sets how wet an item is, from 0 (bone dry) to 1 (soaked). Wetness is what makes clothing stop keeping a player warm after rain or a swim, so drying someone's gear is a real, felt reward — and soaking it is a real punishment.

Like temperature, this is a one-time write. Rain, water and body heat keep changing it afterwards; the node just moves the number now.

When to use it

Instant-dry rewards at a shelter or a base, a soaking as the cost of some event, gear handed out dry regardless of the weather. To read the current value, Get Item Wetness. To warm a player up rather than dry them, Set Item Temperature on what they carry, or the player's own heat as read by Get Heat Comfort.

Pins

Item — item-typed. The held-item events, Give Item To Player and Find Item On Player fit directly; entity-shaped sources such as the Item of For Each Item In Inventory need As Item in between.

Wetness (0-1) — 0 dry, 1 soaked. The panel spinner keeps you inside that range; a wired number does not check itself, so run config values through Clamp Number (Min 0, Max 1).

Example

Drying off at a campfire: On Hold Interaction (Object Class Fireplace, Prompt Text "Dry your gear", Hold Seconds 6) → For Each Item In Inventory (Container = the event's Player) → Body: As Item on the loop's Item → Set Item Wetness (Wetness 0) → Completed: Send Notification ("Dry", "Your gear is dry again").

Everything a player wears or carries passes through that loop, nested bags included, so one wiring dries the whole kit.

Watch out

• The loop above includes items that were never wet. Setting them to 0 is harmless, which is why no filter is needed.
• Wetness comes straight back in rain. A drying spot under open sky feels broken to players — put the prompt on something sheltered, or pair it with a notification that explains the weather is winning.
• An empty Item wire is skipped silently.
• Wiring a number from a config without clamping can push wetness outside 0-1. Clamp Number costs one node.

Sets how many rounds are in a magazine. It goes through the magazine's own server-side ammo call, the one vanilla uses when a magazine is filled or emptied, so every client sees the new count and the weapon behaves accordingly. Set Count writes the number you give; Fill To Max loads it to capacity and ignores the Rounds pin.

Only magazine items respond. Point it at a rifle, a can of beans or an empty wire and it quietly does nothing.

When to use it

Handing out ammunition in a deliberate state: a half-loaded starting magazine, full spares as a kill reward, an empty magazine that has to be filled by hand. Give Weapon already loads and chambers the gun it creates, so use this node for the *spare* magazines rather than fighting that one. To read a magazine, Get Magazine Ammo gives both the current rounds and the maximum.

Pins

Magazine — the magazine item, item-typed. The Item output of Give Item To Player and Find Item On Player fit directly; entity-shaped sources such as Spawn Item In Cargo or Get Item In Hands need As Item first.

Rounds — the count to write. Ignored in Fill To Max mode.

Example

A spawn kit with one half-loaded magazine: On Player Ready → Give Item To Player (Item Class Mag_STANAG_30Rnd) → Set Magazine Ammo (Magazine = the Item output, Mode "Set Count", Rounds 15) → Send Notification ("Kit", "One magazine, half loaded").

Give Item hands back the exact magazine it created, which is what keeps the count on *that* one rather than on some other magazine the player was already carrying.

Watch out

• Anything that is not a magazine is skipped in silence — there is no warning that you pointed it at the wrong item.
• A weapon with a built-in magazine, like the Mosin9130, has no magazine item to aim at. Fill those by other means.
• Fill To Max ignores Rounds. Ask Get Magazine Ammo for Max Rounds when you want a fraction of capacity rather than a fixed number.
• Classnames are case-sensitive when you look a magazine up: Mag_STANAG_30Rnd, not MAG_STANAG_30RND.
• Find Item On Player returns the first match, so loading "the magazine" twice in a row loads the same one twice and leaves the spare empty.

Creates a new item straight inside a container's cargo — the grid you see when you open a tent, a barrel, a sea chest, a backpack or a car boot. The item is born in there; nothing is dropped on the ground first and nothing has to be moved.

Strictly cargo, and that is the difference worth knowing: Put Item Into Item asks the container's inventory for any free spot, attachment slots included, while this node places into the cargo grid only.

When to use it

Stocking containers — event crates, a trader's stash, a resupply barrel, loot in a car you just spawned. For loose loot on the ground use Spawn Item, for a player's own inventory Give Item To Player, and to move an item that already exists Move Item Into Container.

Pins

Container — the entity being filled. A container you spawned, a vehicle from Get Player Vehicle, or a world object passed through As Item.

Item Class — the panel picker, or a wire that overrides it. Wiring it from Random Config Text gives you a crate whose contents a server owner can retune without opening the editor.

Item — the created item, as an entity. Tag Item and Set Item Lifetime accept it directly; the item-typed setters (Set Item Quantity, Set Magazine Ammo) need As Item in between.

Example

A sea chest that restocks when searched: On Hold Interaction (Object Class SeaChest, Prompt Text "Search", Hold Seconds 5) → As Item on the Target → Spawn Item In Cargo (Container = that item, Item Class Mag_STANAG_30Rnd) → As Item on the Item output → Set Magazine Ammo (Mode "Set Count", Rounds 10) → Tag Item ("restock") on the Item.

Two conversions and one tag. As Item bridges the world object into the Container pin and the new entity into the magazine setter; the tag is what later lets a cleanup graph tell your restock from a magazine a player left behind.

Watch out

• Nothing is created when the cargo is full or the item does not fit the grid, and the Item output comes back empty — check it with Is Valid before wiring it onward.
• The Container pin is not checked. An empty wire logs an error in the server's script log rather than skipping quietly, so gate uncertain sources (As Item, Get Player Vehicle) with Is Valid first.
• Classnames are case-sensitive: Mag_STANAG_30Rnd, not mag_stanag_30rnd. A wrong-case class creates nothing and says nothing.
• The item you create is indistinguishable from an identical one a player dropped in. If any later graph must recognise your stock, Tag Item it now and read it back with Get Item Tag.
• A config list entry is one string, so "one item per line" is all you get for free. Pack extras into the line ("Mag_STANAG_30Rnd,2") and unpack with Get Text Part.

Sends a named signal from the server to every connected player's game, where On Client Message with the same name picks it up. This is the bridge between the two halves of a mod: the server decides something happened, and every client is told so it can draw it.

The payload is a fixed envelope — three texts, two numbers and one on/off flag — so sender and receiver never have to agree on a custom format. You fill only the slots you need and leave the rest blank. Under the hood the node loops over everyone currently on the server who has a live connection and sends each of them one guaranteed message; players still connecting, or without a network identity yet, are skipped rather than erroring.

When to use it

Anything every player should see at once that plain text cannot carry: a killfeed row, a round timer, a scoreboard refresh, an event banner. When all you want is words on screen, Broadcast Notification and Broadcast Chat Message are simpler and work on a server-only mod. Reach for this node when the client has to *build* something — a HUD widget, a counter, a coloured row — from the values you send. For one player instead of everyone, use Send Client Message.

Pins

Message (the panel field) — the name that decides which On Client Message wakes up. It is matched as exact text, so "killfeed" and "KillFeed" are two different messages.

Text 1-3 / Number 1-2 / On / Off — the payload slots. Each can be typed into the node or wired. Unwired slots arrive as empty text, 0, and off. Decide what each slot means and keep sender and receiver in step: slot order is the only contract.

Example

A killfeed every player can see: On Player Died → Broadcast Client Message with Message kill, Get Player Name (Killer) into Text 1, Get Player Name (Victim) into Text 2, Get Item In Hands (Killer) → Get Display Name into Text 3, and Was Killed By Headshot (Victim) into On / Off.

On the client side a separate graph starts with On Client Message (Message kill) → Show HUD Overlay → Add Widget From Layout → Scale For Screen → Set Text built from the three texts with Join Text, and a Branch on the On / Off pin that adds a headshot marker. The server decides, the client draws.

Watch out

• Both halves only exist in a Server + Client project, and every player must

have the mod installed. On a server-only install the broadcast has nobody listening and the HUD is simply absent — with no error anywhere.

• The message name is exact text. A typo on either side means silence: the

message is sent, no handler matches, nothing happens. There is no warning for an unhandled name.

• Nothing is sent to a player who has not finished connecting. If a message

matters at join time, send it from On Player Ready with Send Client Message rather than assuming a broadcast caught them.

• HUD nodes belong under On Client Message, never under the server event

that broadcasts. Everything hud* runs on the player's own machine and cannot be reached from a server-side chain.

• Broadcasting inside a per-hit or per-kill event on a busy server means a lot

of traffic. Send state changes, not a message per frame.

Sends a named signal from the server to one player's game, where On Client Message with the same name picks it up. It is the private version of Broadcast Client Message — same envelope, one recipient.

The payload is fixed: three texts, two numbers and one on/off flag. Fill the slots you need and leave the rest blank. The node checks the player before it sends: an empty Player pin, or one whose connection is not live yet, is skipped silently rather than erroring, so a failed lookup upstream just means no message.

When to use it

Anything meant for one player's screen that plain words cannot carry: a personal score panel, a quest tracker, a stamina bar, a warning ring that only they see. For just a line of text, Send Notification and Send Chat Message are simpler and work on a server-only mod. When everyone should get the same signal, use Broadcast Client Message — one broadcast is far cheaper than looping For Each Player around this node.

Pins

Player — who receives it. Required, and it must be a live player: nothing is sent for an empty pin.

Message (the panel field) — the name that decides which On Client Message wakes up on that client. Matched as exact text, so "score" and "Score" are two different messages.

Text 1-3 / Number 1-2 / On / Off — the payload slots. Typed in or wired; unwired slots arrive as empty text, 0, and off. The order is the whole contract between sender and receiver, so decide what each slot means and stick to it.

Example

A personal bounty panel: On Creature Killed → Is Valid (Killer) → Branch → Add To Saved Player Number ("bounty" + 5) on the Killer → Send Client Message (Player = Killer, Message bounty) with Get Saved Player Number ("bounty") wired into Number 1.

The other half is its own graph: On Client Message (Message bounty) → Show HUD Overlay → Add Widget From Layout → Scale For Screen → Set Text fed by Join Text ("Bounty: " + Number 1) → Fit Widget To Text → Auto-Destroy Widget After (6 seconds), so the panel appears, sizes itself, and clears itself away.

Watch out

• Both halves only exist in a Server + Client project, and that player must

have the mod installed. Against a vanilla client the send is a no-op and no error is raised anywhere.

• The message name is exact text on both sides. A mismatch means the message

arrives and no handler matches — silence, with nothing to debug.

• Nothing is sent while the player is still connecting. On join, send from

On Player Ready rather than On Player Connected, which can fire while the client is still on the loading screen.

• Set the HUD text before Fit Widget To Text and scale before you measure —

those nodes read what is laid out right now, so the order in the receiving chain matters.

• After a Delay only the carried player survives, so re-derive the

values you want to send instead of reading a global that another player's event may have overwritten during the wait.

Changes a player's shock — the knock-out meter. Negative amounts push them toward unconsciousness; positive amounts help them recover. As a feel for the scale: -25 is a firm hit, and -100 or more will likely drop them on the spot.

When to use it

Graded, stackable stun effects: a gas zone that wears players down tick by tick, a taser that usually — but not always — drops its target. When you want a guaranteed instant knockout, use Knock Out Player; for a guaranteed instant wake-up, Wake Up Player. Read the meter with Get Player Shock.

Example

A disorienting field: While Player In Zone ticking every 10 s → Add Shock -35 — an unprotected player staying put drops after the third tick, which gives them two warnings' worth of time to leave.

Opens a real bleeding wound on the player at the body zone you pick — the same wound system a knife slash uses. The player sees the blood indicator, their blood drains over time, and a bandage or rags treat it exactly like any other cut. The Started output tells you whether a new wound actually opened.

When to use it

Environmental harm that should feel physical rather than abstract: gas exposure, anomaly damage, trap teeth. Compared with an instant hit from Set Player Health or Damage Entity, a bleed drains gradually and the player can fight back with a bandage — which makes it the right pressure for "get out or gear up" zones. Its counterpart is Stop All Bleeding; check state with Is Player Bleeding or Get Bleeding Wounds.

Pins

Started — true when a fresh wound opened; false when that body zone is already bleeding (a repeat tick does not stack a second wound on the same spot).

Example

A gas zone that punishes anyone without a mask: While Player In Zone over a 100 m zone, ticking every 5 seconds → Get Attachment In Slot (slot "Mask") → Get Entity Type → Text Equals against "GasMask" → Branch; on the false branch, Apply Bleeding → Send Notification "Put a gas mask on!". The tick is what gives the zone teeth: every 5 seconds it reopens the wound the player just bandaged, so staying costs rags.

The same idea goes config-driven by reading the zone and the accepted mask list with Get Setting instead of typing them into the panel, so the zone can be retuned without reopening the editor. For the enter/stay/leave skeleton around it, start from the Toxic zone template and swap its stay-tick notification for Apply Bleeding.

Watch out

• One wound per zone: while a spot is still bleeding, running this again there does nothing and Started reads false. Pick a different zone in the panel, or let the tick reopen it after the player bandages.
• Players can and will bandage. For a persistent zone effect, keep applying on every While Player In Zone tick rather than once on entry.
• If you gate on worn gear: Get Attachment In Slot reads what is worn in the slot — a gas mask in a pocket protects nobody — and the compare is case-sensitive ("GasMask", not "Gasmask").

Strips a player bare: every piece of worn clothing, whatever is in their hands, and everything in cargo — all of it removed in one call. The items are deleted, not dropped; nothing lands on the ground.

When to use it

The step before a loadout. New gear equips into whatever slots are free, so giving a kit over the default fresh-spawn clothes leaves items landing in odd places — clear first and everything the kit gives goes exactly where it should. Also arena resets and confiscation. To remove only specific things, use Remove Items Of Type instead.

Example

A spawn kit: On Player Ready → Delay 3 s → Clear Inventory → a welcome Send Notification → Teleport Player to the arena pad → a second Delay 2 s → Give Item To Player "TShirt_Black" → Give Item To Player "CargoPants_Black" → Give Weapon "M4A1" loaded with "Mag_STANAG_30Rnd" → Resync Player Gear. That second delay is the one people leave out: handing gear over in the same instant you move someone leaves every other client looking at a naked body, and the resync on the end is the backstop. Each Delay carries the player to its Then side, so every node after one takes its Player from the delay rather than from the event. Wire the same chain under On Player Respawned so a death puts the player back in the same kit.

A reusable kit routine opens the same way, one node longer: Clear Inventory → Heal Player Fully before the loadout — gear and body both wiped, so it does not matter what shape the player arrived in.

Watch out

• There is no undo and no drop — everything the player owned is gone for good. Wire it only where losing gear is the point.
• Wait a beat (about 3 s) after the spawn event before clearing and re-gearing. Give the fresh character that moment to finish setting up before you strip and re-dress them, and keep the give-plus-teleport off the same instant — see Resync Player Gear for what happens otherwise.

Removes every disease and infection from a player in one go — everything Give Disease can apply, plus anything they caught naturally from bad water or a dirty wound.

When to use it

A medic NPC, a hospital zone, or an admin heal. It is already part of Heal Player Fully, so only wire it separately when you want to cure without healing everything else. Check whether there is anything to cure with Has Disease.

Example

A field hospital: Player Entered Zone at the medical camp → Cure All Diseases → Send Notification "You feel the fever break."

Infects a player with one of the game's real disease agents — cholera, influenza, salmonella, brain disease, food poisoning, chemical poisoning, wound infection, nerve agent, or heavy metal poisoning. From there the vanilla illness runs its own course: incubation, symptoms, progression, and the usual cures.

Strength is how big a dose lands. The immune system fights small doses off before symptoms ever show; 100 or more makes the illness stick.

When to use it

Contaminated water sources, cursed loot, chemical zones, or punishments with a slow burn. Check for an active illness with Has Disease; clear everything with Cure All Diseases (which Heal Player Fully also includes).

Example

A leaking chemical plant: While Player In Zone ticking every 15 s over the site → Branch on a worn-mask check (Get Attachment In Slot, slot "Mask") → on false, Give Disease set to Chemical Poisoning at strength 150 → Send Notification "Your lungs burn."

Watch out

• These are the vanilla diseases, so vanilla medicine cures them — charcoal, antibiotics, and friends work exactly as players expect. You cannot make an incurable variant this way; for relentless zone pressure, keep re-applying on a tick.
• Strength below roughly 100 is a gamble: a healthy player may shrug it off without a single symptom. That can be exactly the flavour you want, or a bug report waiting to happen.

Adds to a player's energy — the food stat eating fills. A negative amount removes it instead. Energy tops out around 5000, and this node adds to the current value rather than setting it.

When to use it

Spawn kits, quest rewards, or drains (a harsh-winter mod ticking energy away). Its twin for hydration is Give Water; Heal Player Fully fills both to maximum. Read the current level with Get Player Energy.

Example

Comfortable spawns: On Player Ready (On Player Ready) → Give Water 2000 → Give Energy 2000 — fresh characters start fed and watered.

Adds to a player's water — the hydration stat drinking fills. A negative amount removes it instead. Water tops out around 5000, and this node adds to the current value rather than setting it.

When to use it

Spawn kits, rewards, or hardship effects (a desert zone draining water on a tick). Its twin for food is Give Energy; Heal Player Fully fills both to maximum. Read the current level with Get Player Water.

Example

Comfortable spawns: On Player Ready (On Player Ready) → Give Water 2000 → Give Energy 2000 — fresh characters start fed and watered instead of hunting a well.

One node, one finished weapon: the gun is created directly in the player's hands, the magazine is attached, a round is chambered, and up to two attachments are bolted on. These are the same calls vanilla's starting-loadout spawner uses. Done by hand with Give Item To Player, each of those goes wrong separately — the gun lands in the backpack, the magazine sits loose beside it, and the player still has to rack the bolt before the weapon fires. This node fixes all three at once.

Every slot is forgiving about blanks. An empty Weapon Class means "no weapon this time" and the whole node quietly skips — deliberate, so a config-driven kit can leave the weapon out. An empty magazine or attachment slot is simply skipped. And if the weapon classname turns out not to be an actual firearm, the "magazine" is attached like any other attachment instead of loaded — odd classnames stay safe.

When to use it

Any time a player should receive a working gun: spawn kits, kill rewards, arena loadouts. For a weapon placed in the world rather than in hands, use Spawn Item. For adding more attachments than the two slots here, chain Attach Item To Item against the Weapon output.

Pins

Weapon Class / Magazine (loaded) / Attachment — each can come from the panel's classname picker or a wired text pin; a wire overrides the panel. This is what makes config-driven kits work: wire classnames straight out of your config.

Weapon — the created item. Feed it to Set Quick Bar Slot or Attach Item To Item. It comes back empty when the classname was wrong — check with Is Valid.

Example

Team loadouts with literal classnames: On Player Ready → Clear Inventory → team clothes via Give Item To Player → Give Weapon. The blue team's node holds AKM, Mag_AKM_30Rnd and AK_WoodBttstck; the red team's holds M4A1, Mag_STANAG_30Rnd, M4_OEBttstck and M4_RISHndgrd. One node per side, and each fighter spawns with the bolt already racked.

The config-driven form drops the literals: read the weapon and ammo names from your config with Get Setting (keys weapon and ammo) and wire them into the Weapon Class and Magazine pins — one graph then serves any number of kits — with extra attachments added afterwards via Attach Item To Item against the Weapon output.

Watch out

• Classnames are case-sensitive: Aug, not AUG; Mag_STANAG_30Rnd exactly. A wrong-case name produces nothing, the Weapon output comes back empty, and no error is shown.
• Giving gear in the same instant as a teleport desyncs — the player looks naked to everyone else. Wait about 2 s (Delay) after Teleport Player before giving, and run Resync Player Gear after the last item as a backstop.
• The gun is created in the hands, so make sure they are free — run Clear Inventory first. When in doubt, check the Weapon output with Is Valid.
• Wiring the Weapon output into Set Quick Bar Slot straight away can leave the slot empty — the client needs a couple of seconds to receive the new item first. Put a Delay of about 2 s between the give and the quick-bar assignment.

The full reset button. One run restores everything at once: health and blood to maximum, shock refilled, every bleeding wound closed, every disease removed, hunger and thirst filled, broken legs healed. It is the combined effect of the individual medical nodes, in a single step.

When to use it

Spawn kits, arena round resets, an admin heal, a medic NPC. When you only want to touch one thing, reach for the specific node instead: Set Player Health, Set Player Blood, Stop All Bleeding, Cure All Diseases, Give Water and Give Energy, Set Broken Legs.

Example

An arena kit routine opens with exactly this pattern: On Player Respawned → Delay 3 s → Clear Inventory → Heal Player Fully, and only then Teleport Player into the arena and the loadout. Clearing takes away what the player carried, healing takes away the state they carried in their body — so every fighter starts identical, whatever they arrived in.

Watch out

• Stamina is the one stat it leaves alone — add Set Player Stamina if you want the bar full too. It also does not release a restrained player.
• Because it refills shock, it wakes an unconscious player as a side effect. If that is all you wanted, Wake Up Player is the targeted tool.

Drops the player's health to zero on the spot. It is a normal death in every other way: the death screen shows, the body stays where it fell, and On Player Died fires.

When to use it

Rule enforcement — leaving the arena, entering a forbidden area, an admin's last resort. For drama without a corpse, Knock Out Player puts them down temporarily instead. For damage they might survive or treat, use Set Player Health or Apply Bleeding.

Example

The classic arena boundary: Every N Seconds (every 1 s) → For Each Player; each player outside the arena radius and still alive ticks a per-player grace counter up (Add To Player Number); a Branch warns while grace remains and runs Kill Player once it is spent, then resets the counter. The counter is what keeps it fair — a player who clips a metre over the line gets a few seconds of warnings, not an instant death.

Watch out

• On Player Died fires, but the Killer output is empty — this is a health set, not an attack, so nothing resolves as the attacker. Check Killer with Is Valid before granting kill credit, or a scoreboard will silently skip these deaths.
• For Each Player includes dead bodies until they despawn. Gate on Is Player Alive before counting anyone as "outside", or your loop keeps "killing" corpses every tick.

Instantly knocks a player unconscious by draining their shock to zero — the same faint a heavy hit to the head causes. They collapse where they stand, and On Player Knocked Out fires.

When to use it

Non-lethal punishment, stun traps, or the first half of a capture (knock out, then Set Player Restrained). For a graded hit that only might drop them, deal negative shock with Add Shock instead. End it early with Wake Up Player; see who is down with Is Player Unconscious.

Example

A stun anomaly: Player Entered Zone at the anomaly → Knock Out Player → Delay 20 s → Wake Up Player — the delay carries the player through the wait, so the same person wakes up.

Watch out

• The knockout is not permanent: shock recovers on its own and they wake after a short while. To keep someone down, re-run this on an Every N Seconds timer or an While Player In Zone tick.
• An unconscious player is still alive and still counts in For Each Player loops — do not confuse down with dead.

Re-sends a player's worn and held items to every other player on the server. The player's own screen is already right — this fixes what everyone else sees.

The bug it exists for: items created on a player while the engine is rebuilding them for other clients — which happens right after a teleport — never reach those clients. The player sees their full kit; everyone else sees them naked, permanently. This node re-announces the gear and everyone's view snaps back.

When to use it

As the closing step of any loadout sequence that also teleports: teleport, wait, give gear, then Resync Player Gear. Also as a repair tool anywhere players report "so-and-so looks naked".

Example

A loadout that teleports first and dresses the player second: On Player Ready → Teleport Player (the spawn point) → Delay (2 seconds, carrying the Player) → Repeat (Times = 3) → the Body path runs Give Item To Player once per kit item, and the Completed pin runs Resync Player Gear → Send Notification ("Kitted up", 8 seconds). Hanging the resync off the Repeat Completed pin rather than Body is the whole trick: it fires once, after the last item is placed, and the notification lands after that — so the player is told they are kitted only when everyone else can already see the kit. Wiring it inside the loop instead would resync a half-finished set three times over and still miss the final item.

Watch out

• Run it after the final item. It re-sends what the player is wearing at that moment — anything you give later needs another resync.
• It is the backstop, not the fix. Prevention is a Delay of about 2 s between Teleport Player and the first give; resync then covers whatever slips through.

Sets a player's legs to one of three states, picked in the panel. Broken is the vanilla fracture — hobbling, pain, no sprint. Splinted is the walkable-but-mending state a splint normally gives. Healed makes them whole again.

When to use it

Custom fall punishments, trap consequences, or the other direction: instant leg-fix items and medic services. Check the current state with Has Broken Legs. Heal Player Fully also heals legs as part of its sweep.

Example

A leg-fix item the server owner configures rather than you hard-coding it: On Item Injected fires when something is injected into a player → Get Entity Type (Item) gives the classname that was used → Repeat scans your leg_fix_items config list (Times = Config List Count) → Get Config Text At (the loop Index) → Text Equals against the injected type → Branch, and True runs Set Broken Legs (state Healed) on the event's Player, then Send Notification ("Your legs are set", 8 seconds).

The scan is what makes it configurable: nothing in the graph names Morphine, so adding another medical item is a config edit instead of a graph edit. Heal the event's Player pin and not the person holding the injector — Player is who received the injection, which is often a friend.

Watch out

The state is a panel choice, not a pin — a graph that both breaks and heals needs two of these nodes, one per state.

Sets a player's blood level directly, where 5000 is full. The floor is 2500, not zero: PlayerConstants.BLOOD_THRESHOLD_FATAL is 2500, so anything below that is not a wounded player but a dead one. Blood is the slow stat — bleeding drains it and it regenerates on its own over time — and this node snaps it to a value right now. Low blood means the grey screen.

When to use it

Vampiric zones, transfusion mechanics, or setting up a wounded state that regular healing will slowly recover from. Overall health is the fast stat with its own node, Set Player Health. Read the current level with Get Player Blood.

Example

A blood-price shrine: Player Entered Zone at the shrine → Set Player Blood 3000 → Give Weapon as the reward — power for most of your blood, leaving them grey-screened and hunting for a transfusion. Do not price it at 2500: that is the fatal line, and the shrine would simply kill them.

Watch out

Regeneration undoes your work: a value you set drifts back up over the following minutes. For a lasting drain, pair it with Apply Bleeding or repeat it on a tick.

• Values below 2500 do not wound, they kill. Clamp anything you compute so a

subtraction cannot fall through the floor by accident.

Turns a player's body to face a compass heading: 0 is north, 90 east, 180 south, 270 west. Position does not change — only the way they face.

When to use it

Mostly right after Teleport Player, so arrivals face the arena, the trader, or the door instead of a random wall. Read the current facing back with Get Player Direction. For objects and vehicles, use Set Entity Direction instead.

Example

On Player Ready (On Player Ready) → Teleport Player to your event stage → Set Player Direction 180, so every new arrival faces south toward the action.

Sets a player's overall health as a percentage: 100 is full, 0 is dead. It sets rather than adds — running it twice with 50 leaves the player at 50, not 0.

When to use it

Softening or topping up a player by a known amount: a hardcore spawn that starts hurt, a shrine that restores. To kill outright, Kill Player is the clearer choice (it is the same thing as setting 0 here). Blood is a separate stat with its own node, Set Player Blood. Read the current value with Get Player Health.

Example

A hardcore start: On Player Respawned (On Player Respawned) → Set Player Health 65 → Send Notification "You wake up hurting. Find medicine."

Watch out

Setting 0 kills the player, and On Player Died then fires with an empty Killer — no one dealt the hit, so nothing resolves as the attacker. Gate any kill-credit logic with Is Valid.

Flips god mode for one player. On, they take no damage of any kind — bullets, falls, infected, gas, starvation ticks. Off restores normal damage. One node handles both directions through the checkbox.

When to use it

Safezones are the classic case; also event staging ("nobody dies during the briefing") and admin protection. Check the current state with Is Player Invulnerable.

Pins

Invulnerable — checked makes them immune; unchecked makes them mortal again.

Example

A trader safezone: Player Entered Zone at the trader → Set Player Invulnerable (checked) → Send Notification "Safezone"; and the mirror wiring on Player Left Zone → Set Player Invulnerable (unchecked). Stop All Bleeding on the way in rounds it out — protection does not close wounds they brought with them.

Watch out

• The flag does not persist: a relog or server restart silently resets it to mortal. Treat it as something you re-apply on every enter, never something you set once.
• Always build the "off" side. Without the Player Left Zone wiring, a player who visits the safezone keeps god mode for the rest of their session — everywhere.

Puts a player into the restrained state — hands bound, unable to use items — or releases them when the box is unchecked. It is the same state vanilla handcuffs produce, but with no item involved: no cuffs appear on their wrists and no key exists.

When to use it

Jail and arrest systems, event staging ("everyone hold still"), or pairing with Knock Out Player for a capture mechanic. Check who is currently bound with Is Player Restrained.

Pins

Restrained — checked ties them up; unchecked sets them free. One node, both directions.

Example

A holding cell: Player Entered Zone on the cell → Set Player Restrained (checked); Player Left Zone → Set Player Restrained (unchecked). An admin drags a rule-breaker in, the graph does the rest.

Watch out

Because there is no cuffs item, nothing in the world can free them — no struggling out, no cutting loose. The only way out is this node with the box unchecked, so always build the release path before you build the restraint.

Sets the stamina bar right now: 0 exhausted, 100 full. It is a one-time set, not a lock — the bar drains and refills normally afterwards.

When to use it

Exhausting a player as a cost (0 after a teleport, so they cannot immediately sprint off) or refilling as a perk. Read the current value with Get Player Stamina. Note that Heal Player Fully does not touch stamina — this is the only node that does.

Example

An unlimited-stamina server: Every N Seconds (5) → For Each Player → Set Player Stamina 100 — the bar never gets low enough to matter.

The quick bar is the numbered row at the bottom of a player's screen — press "1" and the item in slot 1 comes to hand. This node fills one of those slots from the server, the same shortcut assignment the game makes when a player drags an item onto the bar themselves.

It needs a live item, not a classname: wire in the actual thing you gave or found. If the item pin comes up empty the node quietly does nothing, so a failed lookup upstream just skips the slot.

When to use it

Right after handing out a loadout, so the rifle sits on "1" and the bandage on "4" without the player arranging anything. This node does not give items — Give Weapon and Give Item To Player do that, and both output the created item you can feed straight in here. To bind something the player already carries, find it first with Find Item On Player.

Pins

Item — a live item reference (the Weapon out of Give Weapon, the Item out of Give Item, or a Find Item On Player result). Not a classname.

Slot (1-10) — 1 is the "1" key, 10 is the "0" key.

Example

The full dance, binding a loadout to the bar after handing it out: On Player Ready → Give Weapon (M4A1 with Mag_STANAG_30Rnd) → Give Item To Player (BandageDressing) → Delay (2 seconds, carrying the Player) → Repeat (Times = 2) walks your quickbar list — each pass runs Find Item On Player for that entry's classname into Set Quick Bar Slot, with Slot wired as the loop Index + 1.

Two details carry the example. The wait sits between giving and binding, because the client has to have the items before a slot can point at one. And the item is looked up again after the wait rather than reusing the Weapon output of Give Weapon — a delay carries only the player across, so that reference is gone by the time the loop runs. Index + 1 is because loop indexes start at 0 and quick bar slots start at 1.

Watch out

• The slot references the item on the player's own machine. If the item was created a moment ago it may not have replicated to their client yet, and the slot lands empty. Assign the quick bar a couple of seconds after giving the items — a Delay of about 2 s is there for exactly this.
• Find Item On Player returns the first match, so duplicate classnames in a kit list all bind the same single item.
• After a Delay the only data carried over is the player. Stamp anything else the binding needs — which kit was rolled, for instance — onto the player with Set Player Number before the wait and read it back after, rather than trusting a global: another player's event can overwrite a global while you are waiting, and the quick bar then binds someone else's loadout.

Closes every open wound on a player at once, however many there are — an instant full bandage that consumes nothing. The counterpart to Apply Bleeding.

When to use it

Safezone entry, a medic reward, or cleanup before a fair fight. It is already part of Heal Player Fully, so wire it alone when you want the bleeding gone but the rest of their state untouched. Check first with Is Player Bleeding, or count wounds with Get Bleeding Wounds.

Example

A safezone that patches you up on the way in: Player Entered Zone at the trader → Stop All Bleeding → Set Player Invulnerable (checked) — wounds close at the gate and no new ones open inside.

Brings an unconscious player back round immediately. Shock is the hidden meter that keeps a player down; this node refills it to full, which is what standing back up requires. The counterpart to Knock Out Player.

When to use it

Revive mechanics, medic events, or an admin "get up" tool. To help a player recover without instantly waking them, add a positive amount with Add Shock instead. On Player Woke Up fires when they come round, and Is Player Unconscious tells you who is down.

Example

A "no knockouts" arena: Every N Seconds (5) → For Each Player → Is Player Unconscious into a Branch → on true, Wake Up Player.

Watch out

Waking treats the symptom, not the cause. If something keeps draining shock — a gas zone ticking Add Shock, a repeated knockout on a timer — they will drop again moments later.

Shuts the menu for one of your layouts on this player's screen. Closing it also hands the player back their character: while one of these menus is open the mouse cursor is showing and player control is switched off, and this node reverses both.

Players can already close a menu with Escape — the generated menu handles that for you. This node is for the other case: the button did its job, so the menu should get out of the way by itself.

When to use it

The last step of a menu button: confirm, apply, cancel. If the menu should stay open and just report back, use Set Widget Text instead and leave it on screen.

Pins

Menu Layout (panel) — which layout's menu to close. It only closes that one, and does nothing when it is not open.

Example

A confirm button that closes behind itself: On Button Clicked (your layout, button ConfirmButton) → Set Widget Text (label StatusLabel, "Confirmed") → Close Menu → Teleport Player (the spawn position). The two client-side nodes run on the player's machine in order, then the chain reaches the teleport and hands off to the server, which does the work with the menu already gone.

A cancel button is the same idea with nothing after it: On Button Clicked (button CancelButton) → Close Menu.

Watch out

• Client-side only. It needs the mod installed on players' machines; a server-only build has no menus to close.
• It must come BEFORE any server action in the chain. Everything after the first server node runs on the server, where there is no menu — the editor blocks that ordering and points at the node to move.
• Put it after your Set Widget Text calls, not before. Once the menu is closed there is nothing to write into, and those writes quietly do nothing.
• Only one menu can be open at a time. Your menu will not open while the player has the inventory or another menu up, which is worth knowing when a menu seems not to respond to its key.
• Reopening builds the menu again from the layout file, so it comes back in its authored state — anything the player typed or you wrote into it is gone.

Rewrites the text on one widget inside a menu that is open on this player's screen. Each layout you attach to the project becomes a real in-game menu; this node reaches into the open one, finds the widget by the name it has in the layout, and puts your text on it.

It handles the three widgets that carry text: a label (text widget), a text box, and a button's caption. Anything else in the layout — images, sliders, checkboxes, panels — is found but left untouched, with no error. And because it works on the menu that is currently open, it does nothing at all when the menu is closed.

When to use it

Everything a menu says back to the player: a status line after they press a button, a result, a running total, prefilling a text box with a suggested value. For text on an always-on HUD overlay rather than a menu, use Set Text. To read what the player typed instead of writing to it, use Get Text Box Text.

Pins

Menu Layout (panel) — which of your attached layouts this refers to. It must be the same layout the menu was opened from.

Widget (panel) — picked by name from that layout. Rename the widget in the layout editor and the editor flags the node, so it cannot silently point at nothing.

Text — what to display. Build it from live values with Join Text.

Example

A shop button that answers the player. On Button Clicked (your layout, button BuyButton) → Set Widget Text (widget StatusLabel, "Order sent") → Give Item To Player, with Get Text Box Text (text box ItemBox) wired into its Item Class pin so the player gets whatever they typed.

Read the order carefully. The label is written first, on the player's own machine; only then does the chain reach Give Item To Player — a server node — and hand off to the server. Put the Set Widget Text after the give and it would land in the server half, where there is no menu to write into: the editor refuses to build that graph and tells you to move it up. The text box reading is fine on either side of the handoff, because a widget value consumed by a server node is read on the client and carried across for you.

Watch out

• Client-side only. The mod has to be installed on players' machines (a server-and-client project), and any menu is invisible on a server-only install.
• It must come BEFORE every server action in the chain. A menu button starts on the player's client and moves to the server the moment it reaches a server node — everything after that point runs there, where the menu does not exist. The editor blocks this with a clear message, but the fix is always the same: move the client feedback up.
• Only labels, text boxes and buttons respond. Pointing it at an image or a slider does nothing and reports nothing.
• Closing and reopening the menu rebuilds it from the layout file, so anything you wrote is back to the text you authored. Text set here lasts as long as the menu stays open, no longer.
• It writes to the menu of the player running the chain. There is no way from here to change what someone else is looking at — for that, send them a message with Send Client Message and act on it in their own On Client Message.

Bumps a shared server number by an amount, in one node. It reads the current value, adds yours, and writes the result back to the same named slot Set Global Number and Get Global Number use. A negative Amount subtracts — there is no separate "take away" node.

Like every global, it lives in memory and starts at 0 again after a restart.

When to use it

Counters that belong to the server rather than to a person: total kills this restart, crates dropped, how many players have finished the event. Use Set Global Number when you want to force a value rather than adjust it, Add To Player Number when the tally is one player's, and Add To Saved Number when it has to survive a restart.

Counter looks similar but is not the same thing: it counts how many times one point in one graph is reached. This node counts a value that any graph can read, write and reset.

Example

A milestone announcement. On Player Died → Add To Global Number (Name "kills", Amount 1) → Get Global Number ("kills") → To Whole Number → Remainder (Modulo) (B = 10) → Equals (Numbers) (B = 0) → Branch → True path → Broadcast Chat Message ("10 more have fallen"). Every tenth death on the server announces itself, and the running total is available to any other graph that wants it.

The To Whole Number step in the middle is not decoration. A global is a decimal number and Remainder only takes whole ones, so without it the editor refuses the wire.

Watch out

• The Name must match the other nodes exactly. Case counts ("Kills" is not

"kills"), and spaces and punctuation are stripped, so "kill count" and "killcount" are the same slot.

• One value for the whole server. Adding under a player event adds once per

player, not once per player each.

• Restarting the server resets it to 0. Use Add To Saved Number for a

lifetime total.

• Reading the tally back gives a decimal, even when you only ever add whole

numbers. Pins that want a whole number — Remainder (Modulo), any "Index (from 0)" — need To Whole Number in between; NodeZ never narrows a decimal behind your back.

Adds an amount to a number stored on one player, reading the current value and writing the new one in a single node. A negative Amount subtracts. It uses the same named slots as Set Player Number and Get Player Number, so all three can share a Name.

A player who has never had that name set counts as 0, so the first add on a fresh player leaves them on the Amount you passed.

When to use it

Per-person tallies that only need to last the session: a kill streak, points this round, how many times someone has used a shop. Reach for Set Player Number when you want to force a value — resetting a streak to 0, for instance — and Add To Saved Player Number when the tally should still be there after a restart. Add To Global Number is the one-number- for-everyone version.

Example

A kill streak that announces itself and resets on death. On Player Died → Sequence. Then 0 runs Is Valid on the event's Killer → Branch → True path → Add To Player Number (Killer, Name "streak", Amount 1) → Get Player Number (Killer, "streak") → Equals (Numbers) (B = 5) → Branch → True path → Broadcast Chat Message. Then 1 runs Set Player Number (Victim, "streak", Value 0) so the person who just died starts again.

The Is Valid check matters: a death by infected, fall or bleed-out has no killer, and adding to an empty player is silently dropped rather than credited to anyone.

Watch out

• Session only, never saved. A disconnect wipes the number.
• An empty Player pin makes the node do nothing at all, without an error.
• The Name must match the reading node exactly, spaces and case included.
• Use Sequence rather than running two arms of a Branch back

into the same node — converging exec wires make the compiler duplicate everything downstream under both.

Adds an amount to a saved server number and writes the new total straight to disk. It reads, adds and stores in one node, against the same names Set Saved Number and Get Saved Number use. A negative Amount subtracts, and a name that has never been saved counts as 0.

When to use it

Lifetime tallies for the server: total kills since the mod was installed, how many airdrops have ever landed, an event counter that must not reset when you restart for a patch. Add To Global Number is the memory-only version, and Add To Saved Player Number is the one that credits a person rather than the server.

Example

A running total announced once a day. On Player Died → Add To Saved Number (Name "total_kills", Amount 1). Then, in the same project, Daily At Time (Hour 3, Minute 0) → Get Saved Number ("total_kills") → Join Text ("Deaths so far: " and the number) → Broadcast Chat Message.

Nothing has to survive in memory between the two graphs, and a restart in between changes nothing — that is the whole point of using the saved version here rather than Add To Global Number. Note that Daily At Time runs on the in-game day/night clock, not the wall clock, so on a fast time acceleration this announces several times a real day.

Watch out

• Each add rewrites the saved file. One write per death is fine; one per second

from an Every N Seconds tick, or one per player inside a For Each Player loop, is not. Total it up in a memory global and save once at the end instead.

• The file is loaded once at server start and kept in memory. Editing

persist.json by hand while the server runs is undone by the next add.

• The Name is matched exactly — case and spaces both count.

The stats workhorse. It adds an amount to a number stored permanently against a player's Steam ID — reading the current figure, adding yours, and writing the result to disk in one node. A negative Amount subtracts, and a player with no entry yet counts as 0, so the first kill leaves them on 1 without any setup.

Because the key is the Steam ID rather than the character, a player's total survives death, respawn, a fresh start and a server restart. It is the same store Set Saved Player Number writes and Get Saved Player Number reads.

When to use it

Kill counts, deaths, money, points, bounties, quest progress — every number a player expects to still be theirs tomorrow. Use Add To Player Number for the session-only equivalent (a kill streak that should reset when they log off), and Add To Saved Number when the tally belongs to the server rather than any one person.

Pair it with For Each Player (Ranked), which reads exactly these values: set its Number Name to match and its Stored As to "Saved Player Number", and it walks everyone in score order for you.

Example

Start from the Kill reward template (File → New from template). It already has the right shape — On Player Died → Is Valid on the Killer → Branch — so hang Add To Saved Player Number (Killer, Name "kills", Amount 1) on the True path and the kill reward becomes a permanent scoreboard.

Then read it back anywhere. A top-three announcement: Daily At Time (Hour 20) → For Each Player (Ranked) (Number Name "kills", Stored As "Saved Player Number", Order "Highest first") → Body → Less Than (the loop's Rank, B = 4) → Branch → True path → Join Text building "1. Name — 37" from the loop's Rank, Value and Get Player Name → Broadcast Chat Message. Rank counts from 1 and Value is that player's stored number, so the top three rows come straight out of the loop.

Watch out

• The Is Valid check on the Killer is not optional. Deaths by infected, falls,

drowning and bleed-outs have no killer, and adding to an empty player is dropped in silence — you would simply see kills going missing.

• Only headshots to the "Brain" zone register as headshots if you are counting

those separately; a graze to the head does not. See Was Killed By Headshot.

• Every add rewrites the whole saved file. One write per kill is fine. One per

player per tick is not — keep fast-moving tallies in Add To Player Number and commit the total when the round ends.

• It needs the player to be connected; there is no way to credit someone who

has already left. If credit has to survive them logging off mid-fight, record their Steam ID at the time with Set Player Text and settle up on their next join.

• The Name is matched exactly — case and spaces both count, and a typo quietly

starts a second, separate tally.

Remembers an actual thing — the item, vehicle or object another node just made — under a name, so a node further down the chain can pick it up again with Get Remembered Item. Numbers and positions are values you can copy; this stores a handle to something that exists in the world.

That handle is deliberately weak. If the thing is destroyed, taken apart, or cleaned up by the server, the name reads back empty rather than pointing at rubble. It is built for carrying "the thing I just created" a short distance through a graph, not for keeping a permanent register of objects.

When to use it

The case it exists for is Delay. A delay compiles the rest of the chain into a separate piece of work that runs later, and the editor will refuse to let you wire anything from before the wait into the Then path — only the carried Player crosses. Stash the item here before the wait and read it back after, and the chain survives.

The other case is a loop: remember what this pass created so the next pass can attach to it, or so the work after the loop can finish it off.

If you only need the item within one straight run of nodes, you do not need this at all — wire the creating node's Item output directly. And if the point is to recognise your item later among identical ones, tag it with Tag Item instead; a tag is written on the item itself and survives anything.

Example

An airdrop crate that cleans itself up ten minutes later. Every N Seconds (Every 1800) → Spawn Item (SeaChest) → Remember Item (Name "airdrop") on the spawn's Item output → Delay (600 seconds) → Get Remembered Item ("airdrop") → Is Valid → Branch → True path → Delete Entity.

Two things earn their keep. The remember-and-read pair is what gets the crate across the ten-minute wait at all. The Is Valid check is what stops the delete running on nothing when a player has already looted and destroyed the crate — the name reads back empty in that case, quietly.

Watch out

• One slot per Name, shared by the whole server. If two crates can be in the

air at once, the second overwrites the first and the older one is never cleaned up. Give each its own Name, or do not let them overlap.

• Reading back empty is normal, not an error. Always check with

Is Valid before acting on it.

• This is not storage. It remembers nothing across a server restart, and it

cannot tell your item from an identical one a player dropped — that is what Tag Item and Get Item Tag are for.

• Item names live in their own set of slots, so "drop" here and "drop" in

Set Global Number are unrelated. The Name is matched with spaces and punctuation stripped, and case counts.

A named number the whole server shares. Every node that uses the same Name reads and writes the same single slot, no matter which graph or which event it sits in — so a number stamped here during one player's death event is the same number a timer reads five minutes later.

It lives in memory only. When the server restarts it is back to 0. Think of it as the server's own scratch pad: the round number, how many crates are out, whether the boss event is running. It is not the player's — one value exists for everyone.

When to use it

Two jobs. First, plain server state: a round counter, a flag, a threshold. Second — and this is the one people miss — pinning down a value that would otherwise change. Random Number and Random Config Text re-roll every single place you wire them, so one roll used in three nodes gives three different answers. Roll once, store it here, and read it back with Get Global Number everywhere else.

For a number that belongs to one person use Set Player Number. For one that must survive a restart use Set Saved Number. To bump a value rather than overwrite it, Add To Global Number does the read and the write in one node.

Pins

Name — the slot's identity. Matched exactly, and case matters: "Score" and "score" are two different numbers. Punctuation and spaces are stripped, so "kill count" and "killcount" end up as the same slot. Numbers, positions (Set Global Position) and items (Remember Item) are kept apart, so the same Name in all three is three separate values.

Example

An airdrop that picks one site and then uses it consistently. Put two config lists side by side — a position list drop_sites, and a text list drop_names holding the place names, in the same order.

Every N Seconds (Every 1800) → Random Number (Min 0, Max = Config List Count of drop_sites) → Set Global Number (Name "drop_index") → Spawn Item (SeaChest) with Position from Get Config Position At (drop_sites), then Broadcast Notification with the text from Get Config Text At (drop_names).

Both of those config nodes take a whole number in Index (from 0), and Get Global Number hands back a decimal, so the index goes through one To Whole Number on the way: Get Global Number ("drop_index") → To Whole Number → the Index pin on both. Wire the global straight in and the editor refuses the connection.

The roll happens once and is written down. Both lists are then indexed by that one stored number, so the crate and the announcement can never disagree — which is exactly what happens if you wire the Random Number node into both directly. Max counts up to but not including the number you give it, so the list count itself is the right Max for a list index.

Watch out

• Shared means shared. Under a player event the value is whoever ran it last.

If it should describe a person, use Set Player Number instead.

• A global written before a Delay can be overwritten by another

player's event during the wait. The Then path then reads someone else's value. Stamp it on the player before the wait instead.

• Reading a name that was never written gives 0, so 0 cannot be told apart from

"not set yet". Start meaningful codes at 1.

• Everything here is gone on restart. Set Saved Number is the version

that is written to disk.

Writes a position down under a name so any node, anywhere in the project, can read it back with Get Global Position. It is the same shared server scratch pad as Set Global Number, holding a point in the world instead of a number.

Positions get their own set of slots, so a global number called "drop" and a global position called "drop" are two different values and never collide. Like all globals it lives in memory: after a restart every stored position is back to 0 0 0.

When to use it

Whenever a point is worked out in one place and needed in another. The classic shape is a loop that examines candidates and remembers the best one — you cannot carry a value out of a loop body any other way, so you write the winner here and read it after the loop finishes.

It is also how a rolled position stops moving. Random Point Near and Random Config Position pick a fresh point at every place you wire them, so a crate spawned at one and announced at another lands in two different spots. Store the roll once and everything downstream agrees.

For a point that belongs to one player, there is no per-player position — store its text form with Set Player Text and convert with Text To Position instead.

Example

One airdrop site, used three times. Every N Seconds (Every 1800) → Random Config Position (list drop_sites) → Snap To Ground → Set Global Position (Name "drop"). Then, still under that event, Spawn Item (SeaChest) with Position from Get Global Position ("drop"), and Broadcast Notification telling players where to go. Ten minutes later a separate Every N Seconds reads the same "drop" position into Delete Items In Radius to sweep whatever nobody collected.

The crate, the announcement and the cleanup all point at one stored roll. Wire the Random Config Position node into all three instead, and you get three unrelated map corners.

Watch out

• A never-written name reads back as 0 0 0. That is a real place on the map —

the south-west corner of the world — so a graph with a typo in the Name silently spawns things in the sea instead of erroring. Pair the position with a "have I set this" flag (Set Global Number) when it matters.

• One value for the whole server. Two overlapping events using the same Name

will overwrite each other; give each its own Name.

• A position written before a Delay can be replaced during the wait by

another run of the same graph. Give the second event its own Name, or make the wait short enough that they cannot overlap.

• The Name is matched with spaces and punctuation stripped, and case still

counts: "Drop" and "drop" are two slots, "drop site" and "dropsite" are one.

• Cleared to 0 0 0 on every server restart.

Writes a number onto one player under a name. Each player carries their own set, so "team" can be 1 for one person and 2 for another at the same time — the thing a global number cannot do. Read it back with Get Player Number.

The value lives on the character in memory. Nothing is written to disk and nothing is sent to the client; it is a note the server keeps about that person for as long as they are connected. When they leave, it is gone.

When to use it

Anything that describes a person for the duration of a session: which team they are on, which kit they rolled, a kill streak, the game time a cooldown started.

It is also the reliable way to carry a value across a Delay. Only the carried Player survives a wait, so a global written before the wait can be overwritten by the next player's event while you are counting down — and the graph then acts on somebody else's value. A number stamped on the player cannot be, because it travels with them.

Use Add To Player Number to adjust rather than overwrite, Set Player Text when the value is words rather than digits, Set Saved Player Number when it must still be there tomorrow, and Set Global Number for something that belongs to the server.

Pins

Player — who the note is about. If this comes in empty the write is quietly skipped, so a failed lookup upstream loses the value without an error.

Name — matched exactly, spaces and case included. "kit" and "Kit" are two different numbers on the same player.

Example

Random loadouts that stay random-once. On Player Ready → Random Number (Min 1, Max 4 — Max is not included, so this rolls 1, 2 or 3) → Set Player Number (Player from the event, Name "kit") → Delay (3 seconds, Carry Player wired from the event) → Get Player Number (the delay's Player, "kit") → Equals (Numbers) (B = 1) → Branch, with the False path testing 2, and so on into three different Give Weapon kits.

Three details make it work. The roll happens once and is written down, because a Random Number node wired into three comparisons rolls three separate times. The wait is there because gear handed out too early does not reach the client. And the kit number rides on the player through the wait, so two people joining a second apart each get the kit they actually rolled.

Watch out

• Session only. It is gone when the player disconnects, and it is never saved —

Set Saved Player Number is the version that is written to disk.

• A name that was never set reads back as 0, so 0 and "not set" look identical.

Start team and kit numbers at 1 and keep 0 as the "no answer" case.

• An empty Player pin means nothing is written and nothing complains. Check

with Is Valid when the player came from a lookup like Get Player By Name.

• For Each Player hands you corpses as well as the living. Gate on

Is Player Alive before stamping a value that only makes sense for someone still playing.

Writes a line of text onto one player under a name — a classname, a role, a label, a Steam ID. It is the words version of Set Player Number, with its own set of slots, and it is read back with Get Player Text. The text lives on the character in memory for as long as they are connected; nothing is saved and nothing reaches the client.

The trick worth knowing is what it lets you store safely. You cannot keep hold of another player across time — they can disconnect and the reference goes stale. A Steam ID is just text, so it never goes stale. Store the ID here and turn it back into a live player with Get Player By Steam ID when you actually need them; if they left, the lookup simply comes back empty.

When to use it

Remembering something about a player in words: which faction they picked, the classname of the kit they rolled, the name of the zone they are standing in, or — through the Steam ID trick — who last shot them.

Use Set Player Number when a number will do; numbers compare and add, text does not. Use Set Global Number or Set Global Position for anything that belongs to the server rather than a person. There is no saved text — if a label has to survive a restart, map it to a number and use Set Saved Player Number.

Pins

Player — who the note is about. An empty pin means the write is quietly skipped.

Name — matched exactly. Case and spaces count.

Value — plain text. It comes back byte for byte, so a classname stored here is still case-sensitive when you use it later.

Example

Kill credit that survives a bleed-out. The engine only reports a killer for a direct kill — bleeding out, falling and drowning all leave the Killer pin empty — so keep your own record.

On Player Took Damage → Is Valid on the Attacker → Branch → True path → Get Player Steam ID (Attacker) → Set Player Text (Victim, Name "lastHit"). Then a second graph: On Player Died → Get Player Text (Victim, "lastHit") → Get Player By Steam ID → Is Valid → Branch → True path → Add To Saved Player Number (that player, "kills", 1) and Send Notification.

The ID is written on the victim, so two fights happening at once cannot mix each other up. The lookup at the end is what handles the shooter having logged off in the meantime — you get empty text or an empty player, never a broken graph.

Watch out

• Session only, never saved, and gone the moment the player disconnects.
• A name that was never set reads back as empty text. That is indistinguishable

from a name you set to "" on purpose.

• An empty Player pin drops the write silently — no error, no log line.
• Storing a live player is not an option; store their Steam ID with

Get Player Steam ID and look them up again. A Steam ID is safe to hold for as long as you like, a player reference is not.

• Classnames kept here stay case-sensitive: "GasMask" works, "Gasmask" fails

forever and silently when you feed it to a spawn node.

A server number that is written to disk. Where Set Global Number keeps its value in memory and forgets it on restart, this one is saved into $profile:<YourMod>/persist.json the instant you set it, and is still there when the server comes back up. Read it with Get Saved Number.

The file is plain JSON with the names and values side by side, so you can open it in a text editor to see what your mod has stored — or to fix a number by hand while the server is stopped.

When to use it

Anything that must outlive a restart and belongs to the server rather than to a person: the season number, a lifetime total, a "the world has already been seeded" flag, the timestamp of the last event.

Prefer Set Global Number when the value is meant to reset each restart — it is faster and it makes the intent obvious. Use Set Saved Player Number for something a person owns, and Add To Saved Number to adjust a saved total rather than overwrite it.

Example

One-time world setup. On Server Started → Get Saved Number ("seeded") → Equals (Numbers) (B = 0) → Branch → True path → For Each Config Position over your props list → Spawn Static Object at each, then after the loop Set Saved Number (Name "seeded", Value 1).

Do Once would look like the obvious node here, but its latch is in memory: it opens again at the next restart and you would get a second copy of every prop. A saved flag is what makes "once, ever" actually mean once.

Watch out

• Every set rewrites the whole file. That is nothing for a handful of events a

day, but do not put this under Every N Seconds with a short interval or inside a loop over every player — use a memory global while the work is running and save the result once at the end.

• The file is read once when the server starts and then held in memory, so

editing persist.json while the server is running achieves nothing — the next save overwrites your change. Stop the server first.

• A name that was never saved reads back as 0. A flag set to 0 and a flag never

set are the same thing.

• Numbers only. There is no saved-text node; if you need a saved label, store a

number that stands for it and keep the labels in your config.

• The Name is matched exactly and case counts.