Install the server extension

Creator’s server extension is a small companion that runs on your Rust dedicated server and applies the parts of your map the standard format has no room for: trigger volumes, IO wiring, loot, vending and NPC profiles, ziplines, and the map’s Deep Sea settings. It also keeps Deep Sea objects you placed on your map alive through the Deep Sea’s close, and restocks them each time the Deep Sea opens. Everything else in your map runs without it, so this is an add-on rather than a requirement. See Run your map on a server for the split.

It works on both of the modding frameworks Rust servers use, Oxide (also called uMod) and Carbon. You need one of them installed on the server; if your server has neither, that is the first step and it is their documentation, not ours. On a Crucible Local Server, framework installation is Mods and plugins.

Where to get it

It ships with Creator, in a folder named ServerExtension. The start screen’s Servers need the Creator extension line has a button that opens it for you. The editor itself does not need the extension.

Inside it:

What	For
Carbon\	the two files a Carbon server needs
Oxide\	the three files an Oxide server needs
README.txt	the short version of this page: which files go where

The extension in your Creator folder is the one built for that Creator release, so when you update Creator, copy the new files onto your server too. If the server holds an extension from before Creator 0.1.8, read Upgrading from a Creator older than 0.1.8 first: two files were renamed, and the old ones have to be deleted.

Install it

Copy the files for the framework your server runs, not both. Every file in that framework’s folder is needed.

On Carbon:

1. Stop the server.
2. Copy the two files in ServerExtension\Carbon\ (Creator.Ext.Carbon.dll and Creator.Ext.Core.dll) into the server’s carbon\extensions\ folder.
3. Start the server.

On Oxide:

1. Stop the server.
2. Copy the three files in ServerExtension\Oxide\ (Oxide.Ext.Creator.dll, Creator.Ext.Core.dll and protobuf-net.dll) into the server’s RustDedicated_Data\Managed\ folder, the one that holds Oxide.Core.dll.
3. Start the server.

Keep the file names exactly as they are. Oxide loads an extension from that folder only when its file name starts with Oxide., so a renamed Oxide.Ext.Creator.dll is silently never loaded.

Copy the Core file too, or nothing works. On Oxide, protobuf-net.dll is needed as well: Oxide does not ship it.

Upgrading from a Creator older than 0.1.8

Two files were renamed in 0.1.8. RustCreator.Ext.Carbon.dll is now Creator.Ext.Carbon.dll, and RustCreator.Ext.Core.dll is now Creator.Ext.Core.dll. Copying the new files onto a server therefore no longer replaces the old ones: they land beside them.

1. Stop the server.
2. Delete the old files from the folder you installed them in: RustCreator.Ext.Carbon.dll and RustCreator.Ext.Core.dll from carbon\extensions\ on Carbon, or RustCreator.Ext.Core.dll from RustDedicated_Data\Managed\ on Oxide.
3. Copy the new files in, as above, and start the server.

Framework	What happens if the old files stay
Carbon	The old extension and the new one both load, and every block of your map is applied twice: two sets of wires, and two spawners for each one you authored.
Oxide	Oxide.Ext.Creator.dll kept its name, so it is replaced as before. The old RustCreator.Ext.Core.dll is left behind as a file nothing loads.

The extension reports each old file it finds as an error in the log, with the words OLD FILE.

The log tag changed with the files: lines that began [RustCreator.Ext] now begin [Creator.Ext], so a search or a log filter you kept for the old tag needs the new one.

Upgrading a Carbon server that ran Creator 0.1.8

The 0.1.8 extension on Carbon put a power counter’s target into its running count, and the server saved that count. Newer releases set the target correctly, but they do not touch a count the server already saved. So if you upgrade a Carbon server from 0.1.8 without a wipe, a counter on your map can start at its target, and what it powers (a puzzle door, for example) is on from the start. The next wipe puts every counter back to zero.

Check that it worked

The extension reports itself in the server console and the server log. Search for [Creator.Ext]. On a map that carries Creator data you get a manifest line and then one line per block, like this:

[Creator.Ext] manifest: 3 blocks, editor <version>
[Creator.Ext] io: v3 nodes=12 wires=11 OK
[Creator.Ext] loot persist: placements=4 filled=4 items=17 unknownItems=0 (of 212 loot spawn(s) seen) OK
[Creator.Ext] loot: found=4 applied=0 deferred=4 skipped=0 OK
[Creator.Ext] vending: found=1 applied=1 skipped=0 items=6 refillFromProfile=1 OK
[Creator.Ext] io settings: applied=5 skipped=0 byKind[accessLevel=1 doorAction=1 broadcastFrequency=1 receiveFrequency=1 phoneName=1]

Read them as: found is how many things the map asked for, applied is how many landed on a live entity, and skipped is the rest, with the reason in brackets. What you want is applied matching what you authored and skipped=0.

Loot is the one family with two lines. A crate or barrel is filled from its profile by the game’s own refill, each time it happens, so the loot line counts those as deferred and the loot persist line counts how many have been filled so far (filled) out of the placements the map carries (placements). On a server that loaded a save, filled=0 at startup is normal: the containers hold what the players left, and each gets its profile again at its next refill. A plain storage box with a profile is still counted under applied.

On the vending line, refillFromProfile is how many of the applied machines now restock from your profile. A shop front with a shopkeeper and a player’s own machine are applied but not counted there.

On a map with no Creator data the extension stays silent on purpose. Silence there is not a failure; it means the map is not carrying anything for it to apply.

Which version is installed

Type creator.version in the server console, or send it over RCON. An admin can also run it from the F1 console in the game. It answers with the Creator release the extension came from, the framework it was built for, and the version each of its two files carries:

[Creator.Ext] Creator server extension 0.1.9 for Carbon (Creator.Ext.Carbon.dll 0.1.9, Creator.Ext.Core.dll 0.1.9)

The extension writes the same line to the log when it loads, so a log you send with a question already says which release was running. If the two files come from different releases, which happens when only one of them was copied over an older install, a second line says so:

[Creator.Ext] MIXED INSTALL: Creator.Ext.Carbon.dll is from Creator 0.1.9 and Creator.Ext.Core.dll is from Creator 0.2.0. Stop the server, copy every file of ONE release's ServerExtension folder over them, then start it again.

The command is in the extension from Creator 0.1.9 on. An older extension answers that the command was not found; compare its files with manifest.json in the ServerExtension folder of the release you think it is. A file from before 0.1.9 cannot report a mix either, so a mix with one of those shows as errors when the server starts; the fix is the same, copy every file of one release’s folder.

What the census lines tell you when they are not clean

What you see	What it means
skipped=… (noMatch=…)	The map asked for an entity that is not there, at that position. Usually a prefab that was moved or deleted after the wiring was authored.
skipped=… (ambiguous=…)	Two entities sit on the same spot, so the extension will not guess which one you meant.
skipped=… (missingProfile=…)	A placement points at a loot, vending or NPC profile that is not in the map.
io settings: … skipped=… (refused=… declined=… threw=…)	A wiring setting was not set. refused is a stored value the game cannot take, declined is one the live object would not take (an identifier already in use, a weapon the server does not have), threw is an error. A line under it names each one by node and setting.
unknownItems=…	An item shortname this wipe’s Rust does not have. The line names each one. Fix the profile in Creator and re-save.
CRC-FAIL	The block is damaged. Re-save the map from Creator.
MISSING (in manifest, not in map)	Something stripped one of Creator’s blocks out of the file. See the Caution below.
SKIPPED (needs reader >= N)	The map was saved by a newer Creator than your extension. Update the extension.

None of these stop the map loading. The extension is written so a data problem is reported and skipped, not thrown.

A third-party tool can silently strip Creator’s data out of your map

Creator’s extras ride inside the .map file under their own names. A tool that re-saves a map and drops entries it does not recognize will take them with it, and the map will still load and play as if nothing happened.

If you see MISSING, the map you uploaded is not the one Creator saved.

Loot profiles and the game’s own refill

Setting	What it does
RC_EXT_LOOT_PERSIST	On by default. 0 goes back to how Creator 0.1.8 and older behaved: a profile is applied once when the server starts, applied again at every restart, and replaced by the container’s normal loot the first time the game refills it.
RC_EXT_VENDING_REFILL	On by default. 0 goes back to how Creator 0.1.8 and older behaved: a vending machine’s orders are set once when the server starts and its stock is not refilled.

Both are environment variables on the server, read once when the extension loads. To re-roll every container on the map by hand, Rust’s own spawn.respawnloot_all does it, and each profiled container gets its profile.

Respawn rules for what you placed by hand

Rust already brings some hand-placed things back by itself. A crate, barrel, ore node, tree or log that sits in your map’s own prefab list returns at the same spot once it is gone, on a server-wide timer (spawn.tick_individuals, 300 seconds unless you change it). A collectable (hemp, mushrooms, berries, the stone, metal, sulfur and wood pickups) does not: it is there after a wipe, a picked one never returns, and every one of them is gone after the first restart.

A map can carry its own rules for this, one for each of four groups: loot containers, ore nodes, trees and logs, and collectables. A map with no rules is left exactly as Rust runs it, and that is every map unless its author set one. When a map has rules, the extension prints them at startup and applies them:

[Creator.Ext] upkeep: loot=Managed(own window) ores=Managed(600..900s clear 30m) trees=Game collectables=Managed(300s) shopkeepers=Leave
[Creator.Ext] upkeep individuals: listed=1840 mapPlaced=212 loot=64 ores=40 trees=108 other=0
[Creator.Ext] upkeep gate: asked=0 released=0 waited=0 deferred=0 never=0 pending=0
[Creator.Ext] upkeep collectables (serverinit): placements=36 adopted=0 created=36 respawned=0 waiting=0 deferred=0 failed=0 OK

A group set to	What happens
Game	Nothing: Rust’s own behavior, as on a server without the extension.
Managed	For crates, barrels, ores, trees and logs, the extension holds Rust’s own respawn back until a delay has passed since the thing was found gone and, if the map asks, until no player is within a distance. own window means a crate or barrel waits as long as Rust itself takes to refresh that container’s loot (one to two hours for most). For collectables the extension brings them back itself, after the delay, and puts them back after every restart.
Never	It stays gone until the next wipe.

The extension only ever delays or allows Rust’s own respawn for the first three groups. It does not spawn a second copy, it saves nothing, and a delay ends on Rust’s next timer tick, so it can run up to spawn.tick_individuals longer than the number says. A restart starts every wait again. Only what the map itself placed is affected: a monument’s own crates, and anything spawned by a plugin or an admin, follow Rust’s rules as before.

creator.upkeep, typed at the server console or sent over RCON by an admin, prints the rules and the running counts at any time.

Setting	What it does
RC_EXT_UPKEEP	On by default. 0 leaves every rule unapplied: the rules are printed, and Rust’s own respawn stands.

Shopkeepers for shop fronts

A shop front (the invisible counter a shopkeeper stands behind) cannot be used until a shopkeeper is attached to it, and Rust attaches one only when the shopkeeper spawns after its shop front and within a meter of it. For shop fronts placed in a map, Rust does not fix which of the two spawns first. On every map, for each shop front the map itself placed, the extension:

1. attaches a shopkeeper that already stands within a meter of it, whatever order the two spawned in;
2. when there is none, and only if it is told to, creates the right shopkeeper at the shop front’s own spot.

It checks again once a minute, because a water well’s shopkeeper is the one shopkeeper that can be killed. A shop front inside a monument, a rentable shop’s own counter, and one an admin or a plugin spawned are left alone. A line is printed at startup, and again whenever a later check did something:

[Creator.Ext] shopkeepers (serverinit): found=3 kept=1 bound=1 created=0 skipped=9 noKeeper=1 (creating is off) OK

kept already had theirs, bound were attached, created were made, and noKeeper are still without one because creating is off.

Setting	What it does
RC_EXT_SHOPKEEPER	On by default. 0 leaves every shop front to Rust’s own pairing.
RC_EXT_SHOPKEEPER_CREATE	Not set by default, which leaves creating to the map: a map whose Shopkeepers setting is Add when missing gets them, any other map does not. 1 creates a missing shopkeeper on every map; 0 never creates one, whatever the map says.

A shopkeeper the extension creates is saved by the server like any other, so it is there after a restart and is not created twice.

Deep Sea objects and settings

Three things happen on every map the extension loads, including maps with no Creator data, because all three are about the Deep Sea that Rust runs beside your map.

Deep Sea objects you placed on your map stay, and players on the mainland see them. On a server without the extension, a copy you placed on your own map vanishes at the first Deep Sea close, and players on the mainland most likely never see it. The extension keeps the copies you placed out of every close and shows them to mainland players. It only protects what the map itself placed, and only outside the Deep Sea zone: the Deep Sea’s own random islands, cities and ships open and close exactly as they do on any server, and a copy an admin spawns in by command is not protected. Creator’s server-ready check notes every one of them you place, and it also warns when a map is wider than 7,800 m, because the west edge of such a map reaches into the Deep Sea zone. On a server that will not run the extension, swap the islands and ghost ships for their art instead (EDIT, Swap Deep Sea Objects for Their Art): it looks the same and no close removes it.

The Deep Sea objects it keeps, and the tropical islands you stamped, are restocked. Each time the Deep Sea opens, the extension fills what it keeps with loot and people: a ghost ship’s crates, barrels and scientists, an island’s loot and its residents, and the same for every tropical island you made with the Island Stamp. On a fresh wipe it also fills them once when the server starts. Objects fill with the game’s normal amounts and are never doubled. The server’s own deepsea.loot_scale and deepsea.loot_respawn_scale apply, and turning off ai.npc_spawn_on_deep_sea_islands or ai.npc_spawn_on_junkpile keeps the island residents or the ghost ship scientists away as it does in the Deep Sea. Residents can walk around the islands. A refill line is logged each time.

A floating city has no spawners of its own: its shopkeepers and turrets are part of it and stay with it.

The map’s recommended Deep Sea settings are applied. A map can carry Deep Sea settings: the Tropical look (the Deep Sea’s sand, palms and ground cover over the whole map), how long the Deep Sea stays open, and which side of the world its portal opens on. The extension sets them when the server starts and logs each one. A setting this server’s Rust version does not have is reported as SKIPPED and the rest still apply. deepsea.terrain_everywhere is saved by the server, so it stays set after you switch to another map until you set it back.

Without the extension, Creator writes the same settings beside your map when you save, as a file named after it that ends in .server.cfg. Paste its lines into the server’s server.cfg. That covers the settings, not the Deep Sea objects you placed. Setting deepsea.enabled false is not a way to keep them: it stops the close but turns the whole Deep Sea off, and players on the mainland still do not see them. Swap them for their art instead, as above.

Setting	What it does
RC_EXT_DEEPSEA_KEEP	On by default. 0 gives the Deep Sea close back its normal behavior, deleting the copies you placed. A map can also turn it off for itself.
RC_EXT_DEEPSEA_REFILL	On by default. 0 stops the restocking: the objects the extension keeps and your stamped islands keep only the loot the game refills by itself over time, and their residents have no walking paths.
RC_EXT_DEEPSEA_SETTINGS	On by default. 0 leaves your own server.cfg in charge: every setting the map asks for is printed as NOT APPLIED and none is changed.

All three are environment variables on the server, read once when the extension loads.

List your server as modded

A server that uses the extension’s Deep Sea features is changing how part of the game behaves, so it should list as modded. The Tropical look on its own is a standard Rust setting and needs no extension.

Semi-Tropical ground

On a map saved in Semi-Tropical mode (see Tropical biome), the extension gives the tropical look to each player while they stand on the map’s painted Tropical ground, and tells the game’s own spawns that the ground there is Tropical. On any other map it does nothing at all. It logs what it found at startup, and a line each time a player switches.

Setting	What it does
RC_EXT_TROPICAL_SWITCH	On by default. 0 keeps every player on the ordinary look.
RC_EXT_TROPICAL_BIOME	On by default. 0 leaves the game’s own biome answers untouched, so spawns treat Tropical ground as the Arid under it.
RC_EXT_TROPICAL_EDGE	The margin, in meters, a player must be clear of Tropical ground before their look switches back. Default 12.

If an admin sets deepsea.terrain_everywhere true by hand while a Semi-Tropical map is running, every player already has the tropical look, so the extension sends nothing until it is set back to false; then the players on Tropical ground get their look back at the next check.

The traveling vendor

Rust’s traveling vendor drives only a ring: the first road in the map whose last point is its first. At startup the extension works out which road that is, on any map, so you do not have to wait for the event to fire to find out:

[Creator.Ext] vendor ring: mainRoads=6 closed=1 ring="Road 72" hierarchy=3 (no mesh) nodes=1622 length=12160 m decks=4 spawnable=1580 of 1623 (monument 31, blocked 12)
[Creator.Ext] vendor ring: not taken: 5 open main road(s) ('Road 0 A' ends 1340.2 m apart, ...), 21 side road(s) (hierarchy 1), 50 trail(s) (hierarchy 2)

decks counts the bridges the vendor’s road runs over. When no road qualifies the line says vendor ring: NONE (...): the travelling vendor will not spawn on this map. That is the case on a map whose ring road or island loop crosses a bridge and that does not carry a vendor ring: each bridge splits the road at its two ends, and Rust needs one unbroken loop.

While a vendor is out, the extension also logs its trip: where it appeared, each bridge entered and left, when it pulls over (its hazard lights), a stall (no movement for a minute with nobody near it), and how far it got before it left:

[Creator.Ext] vendor: deck 2 left after 41.0 s at (612.3, -548.9) (crossed)
[Creator.Ext] vendor: lived 1834 s, travelled 8120 m, decks crossed 3, stalls 0

Setting	What it does
RC_EXT_VENDOR_RING	On by default. 0 turns off the startup line and the repair below.
RC_EXT_VENDOR_WATCH	On by default. 0 stops the trip lines.
RC_EXT_VENDOR_RESCUE	Off by default. 1 replaces a stalled vendor with a new one, on a map made in Creator.

On a map made in Creator the extension also repairs one thing: if a Rust update ever stops counting Creator’s vendor ring as a main road, it puts the ring back in the list and says so in a line that starts vendor ring: SAFETY NET. The startup line and the trip lines have been watched on a live server; the repair has not been needed yet.

Reloading it

Reloading the extension (c.reload on Carbon, oxide.reload on Oxide) cleans up what it created and applies the map again from scratch. Reloading the extension is safe to do as often as you like.

What is proven, and what is not

Tested on Carbon. Oxide is not tested yet; tell us how it goes.

Oxide, Creator 0.1.8 and older

Through Creator 0.1.8 the Oxide build loaded and then applied nothing when the server started: no wiring, no loot, vending or NPC profiles, no ziplines, markers, monument names or volumes, and no door fix. Only the parts that hook the game while it is still loading could run (the Deep Sea keep at a close, and the Deep Sea settings). The Carbon build was not affected. It is fixed in the release after 0.1.8: on Oxide the extension now applies the map once the server has opened, and says so at load with the line [Creator.Ext] server init seam: installed on ServerMgr.OpenConnection. If your Oxide server’s log has no line per block after an update, copy the new files again.

If it does not load at all

• Nothing in the log mentions Creator.Ext. The files are in the wrong folder, a file was renamed, or not every file was copied. Check each one, in the folder named above for your framework.
• Every block is applied twice on Carbon, or the log carries lines that say OLD FILE. The files from before Creator 0.1.8 are still on the server: see Upgrading from a Creator older than 0.1.8.
• The server logs an assembly or type error on startup. The extension was built against a different Rust server version than the one you are running. A Rust update can break it; install the extension from the matching Creator release. On Oxide, a missing protobuf-net.dll shows up the same way.
• It loads and every block is skipped. The positions in the map no longer match the entities the server spawned. That is usually a map edited after the wiring was authored: see noMatch above.