The map file and the sidecar

A Rust custom map is one file, a .map, and it is a complete world: the terrain, every layer, every placed object and every path, in a single compressed container. Creator sometimes writes a second file beside it, a .rcside sidecar, for the things that have no place in the standard format. This page is what is in each, and which of it a server reads.

The .map format is Rust’s, not Creator’s. It is the same file other map editors write, the same file a server downloads, and it is documented here because knowing what is in it tells you what can and cannot survive a trip through another tool.

What a .map is

A tiny plain header, then one compressed block holding the whole world.

The current format is version 10. Version 9 files still open: they are upgraded on load, and the only difference between the two is that 10 records the time it was saved. Anything that writes a modern map writes version 10.

Inside, the world is four things:

Part	What it is
size	The map’s edge length in meters. This is the one number the whole file is scaled to.
maps	The named terrain layers: height, water, splat, biome, topology, alpha. Each one is a square grid covering the map.
prefabs	Every placed object. Each entry is a reference to a Rust prefab plus a position, rotation and scale.
paths	Roads, rivers, rails and powerlines. Each is a line of nodes plus its width, its fades, and which splat and topology it paints.

What each layer does is on How Rust builds a map.

Two things worth knowing about the prefab list:

• A prefab is stored as a number, not a path. The entry holds a hash of the prefab’s asset path, which is why a map file is not readable text and why a prefab that no longer exists in Rust cannot be named by the file alone.
• Monuments are in there like anything else, as a root prefab at a position. The monument’s own contents and its terrain masks come from the game’s assets, not from your map.

Two categories that are baked, and one that is not

Generated maps carry finished prefab sets that look like they should be built at runtime, and are not: the train tunnel network under the rails, and the underwater lab interiors, are both assembled during generation and written into the file. The server does not rebuild them.

Trees, ore, collectibles, animals and container loot are the opposite: none of them is in the file, and the server creates them every time it starts, from your biome and topology layers. So a map file is a world plus a rulebook, and the living part is spawned onto it.

Creator’s own data, inside the same file

The standard format has no room for trigger volumes, IO wiring, loot and vending profiles, NPC spawners or custom ziplines. Creator stores those in the .map anyway, as extra named entries alongside the terrain layers, because Rust’s format allows named entries and a server ignores the names it does not know.

So one file carries both. On a stock server it loads and plays with those parts inert. Install the server extension and it reads them and applies them. Nothing is lost either way.

A last entry, written after the others, lists what the file is supposed to be carrying. That exists for one reason:

A tool that re-saves your map can strip Creator’s data out of it

Creator’s entries are named plainly rather than disguised, which makes them debuggable and honest. The cost is that a third-party tool which re-saves a map and drops entries it does not recognize takes them with it. The map still loads. Nothing errors. The wiring just is not there any more.

That is what the listing entry catches: the extension knows what the file claimed to carry, so a stripped entry is reported by name at server start instead of quietly doing nothing. If you pass a Creator map through another editor, check the extension’s boot lines afterwards.

Creator itself never does this to anyone else’s data. Entries it does not own are passed through byte for byte, including RustEdit’s. See Import a RustEdit map, which is that rule in detail and has one more twist to it.

The sidecar

The sidecar is a .rcside file with the same name as your map, sitting beside it. It holds the things that belong to the editor rather than to the world:

In the sidecar	Why it is not in the map
Trigger volumes	They mean something only to a server extension, so faking them as inert map objects would be a lie the map tells.
The recipe a generated map was built from, and the verdict it was given	It is a record of how you got here, not part of the world. A Creator Mode run records its mode and everything it was asked to do (the land, the monuments left out, the pins and the bridge settings), and a fingerprint of the height it ran on, which is how the panel reopens in Creator Mode with the same settings.
Bridge records	The bridge itself is entirely in the .map. What the sidecar keeps is what the geometry cannot say, above all the clearance each deck was built to.
Which server a RustEdit map is written for, and anything set aside for that choice	See Import a RustEdit map.

Most maps have no sidecar at all, and that is correct. Generate a map in Standard Mode and save it and you get one file. The sidecar appears only when there is something for it to hold, and its absence is never an error.

A sidecar write touches only the sidecar. Your .map is not opened, so authoring a sidecar feature can never change the map’s prefab list or a terrain layer.

Moving, sharing and backing up

• Keep the two files together. Copy the .map and its .rcside as a pair, to another PC, to a server, or into a backup.
• A map without its sidecar still loads and still plays. You lose the editor-side layers, not the world. Nothing breaks.
• A sidecar without its map is useless. It is keyed to the map beside it.
• Give each version its own name. Servers and Rust clients both cache the map they downloaded, so an edited map under the same name can come back as the old one. See Run your map on a server.

Where these files live on your disk, along with everything else Creator writes, is Where your files live.