Loading

A new world already has a starter zone and room, but it has no live item or mob population. First create item and mob templates, which define kinds of objects. Then create live objects from those templates with the builder-only /load command or with repeatable loaders.

The distinction matters while testing: editing a template changes its definition, while an item or mob already present is a live object created from an earlier version of that definition.

Load one object manually

Play as the Builder character and enter /load <type> <template_id>. The object is created in the builder’s current room or inventory, depending on its type.

Load item template 234 into the Builder's inventory

/load item 234

Load mob template 456 into the current room

/load mob 456

Drop an inventory item when it should be on the ground:

drop apple

Manual loading is ideal for a quick template test or a live game-mastered event. It does not define how the world should rebuild that object later.

Build a loader

Open a zone and select Loads. A loader belongs to that zone and contains an ordered list of rules.

1. Select Add and give the loader a descriptive name.
2. Choose whether it inherits the zone’s respawn frequency or uses its own.
3. Add a rule, choose an item or mob template, enter Number of Copies, and choose a target.
4. Add dependent rules after the rule they target.
5. Save and playtest the result with /repopulate.

Descriptions are builder-facing notes. Use them to record what population the loader owns and which other rules depend on it.

Rule targets

Each rule creates copies of a template and places them into one of four target types:

Target	Result
Room	Every copy is created in that exact room. A mob loaded this way is static unless a command moves it.
Zone	Each copy starts in a randomly chosen eligible room in the zone. A loaded mob may roam throughout that zone.
Path	Each copy starts in a randomly chosen eligible room in the path. A loaded mob may roam only among connected rooms in that path.
Output of Rule	Creates an item inside each object created by an earlier rule in the same run. Use this for mob inventory or a container’s contents.

Rules execute in displayed order. A rule can target only a previous rule because its output must exist first.

When targeting another rule, Number of Copies applies per newly created parent. If rule 1 creates two soldiers and rule 2 creates three apples in rule 1’s output, that run creates six apples. A later loader pass does not independently refill apples inside soldiers who already exist; the dependent rule runs against parents created during that same pass.

Population counts

For room, zone, and path targets, Number of Copies is the desired live total attributable to that rule. Scheduled and manual repopulation compare that target with the current population and create only the missing amount.

If a player moves or collects a loader-created item, the loader can replace it after the relevant wait. Purging a live object also makes room for a replacement. Manually loaded objects are not owned by that loader rule and do not count as its output.

Eligible random load locations depend on the kind of object:

• Mob rules targeting a zone exclude No Load, No Roam, and Water rooms.
• Mob rules targeting a path exclude No Load and No Roam. A path can load a mob into a Water room.
• Item rules targeting a zone or path exclude No Load and Water rooms. No Roam does not restrict items.

No Roam is available in the current Room Config screen. Existing worlds may also contain the older No Load flag, but the current editor does not expose a toggle for it.

The flags can leave a zone or path with no eligible location. When that happens, the rule creates nothing.

Respawn timing

A loader can inherit its zone’s respawn frequency or use a separate value:

• A positive number waits that many seconds between eligible runs.
• 0 means there is no additional wait.
• Disabling Respawns means the loader runs during initial population but not during scheduled repopulation.

Running worlds check loader eligibility on the engine’s recurring cycle, currently every 15 seconds. A 60-second wait therefore means “on the first processing cycle after the wait has elapsed,” not exactly 60 seconds after an object disappears.

Multiplayer worlds usually need repeatable loads so late-arriving players can find essential mobs and items. In a single-player world, a never-respawn loader can model one-time progression.

Loader conditions

The loader’s Conditions field uses the same expression language as conditions, but its actor is the world rather than a player. In practice, world facts are the useful state here:

fact_check timeofday night

All conditions must pass for the loader to run. Conditions are still evaluated during manual repopulation.

The separate Zone Data Condition is a specialized war-zone feature. Leave it blank unless you are deliberately building against war-zone data.

Repopulate immediately

Use the canonical /repopulate command while playing a builder in the zone you want to test. /repop is an accepted shorter alias.

/repopulate

This ignores zone and loader wait timers, but it still respects population counts and conditions. It affects the current zone, not every zone in the world.

If nothing appears, check in this order:

1. The rule references the intended template and target.
2. The target contains a room eligible for that kind of object.
3. The loader condition passes.
4. The target count is not already satisfied by a live object somewhere else in scope.
5. A dependent rule comes after its parent rule.

Whenever a mob is created, it fires its Mob Loads reaction after spawning. Use that reaction for initialization commands that belong to the mob rather than to the loader.