> For the complete documentation index, see [llms.txt](https://docs.rainmad.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rainmad.com/resources/map-editor-place-anything/import-and-export.md).

# Import & Export

A build can leave in five shapes and come back in three. **Export** is on every card in the layout browser and on the way out of a session.

The dialog shows the layout file straight away, because that is the one nearly everybody wants. The others are underneath: picking one shows it and writes nothing. **Save on the server** is the press that leaves a file behind, and it says where afterwards.

## What Each Shape Carries

| Shape           | Carries                                                                                  | Comes back in |
| --------------- | ---------------------------------------------------------------------------------------- | ------------- |
| **Layout JSON** | everything: props, lights, hidden pieces, collision, tint, embedded light colour, groups | yes           |
| **Resource**    | everything, as a folder that stands the build up on its own                              | no            |
| **Lua table**   | the rows, for a script of your own that already spawns props                             | no            |
| **ymap XML**    | props as map data, with their tint                                                       | yes           |
| **Spooner XML** | props with their tint, frozen where they stand                                           | yes           |

{% hint style="info" %}
**Runtime features** are lights, hidden map pieces, collision and embedded light colour, and each needs a script running. No map file can hold them, so a ymap or spooner export leaves them out and says how many rows it dropped. The layout file and the generated resource keep them.
{% endhint %}

## Where the Files Go

Inside the resource, one folder per shape:

```
rm_mapeditor/exports/json/<name>.json
rm_mapeditor/exports/lua/<name>.lua
rm_mapeditor/exports/xml/<name>.ymap.xml
rm_mapeditor/exports/spooner/<name>.xml
rm_mapeditor/exports/resource/rmme_<name>/
```

## The Generated Resource

The resource shape writes a folder you can drop straight into `resources` and `ensure`. Two files: a manifest, and a `layout.lua` that makes the props when it starts and deletes them when it stops. Nothing is saved and no database is touched: stopping the resource takes the build away.

Because it is a script rather than a file, it is the one export with anything to decide, and the dialog asks:

|                        | Default  | What                                                                                                                        |
| ---------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Runtime features**   | Included | left out, it writes the least a script can do: props where they were put, with their tint, and nothing it has to keep doing |
| **Draw lights within** | 120 m    | further than this from the camera and a light is skipped rather than drawn                                                  |
| **Lights at once**     | 24       | the nearest this many, and no more: the game shares one light pool with everything on screen                                |
| **Hide radius**        | 0.10 m   | how near a map piece has to be to the saved spot to count as the one being taken out of view                                |

Changing any of them rewrites what is on screen, so you're reading the file you're about to keep.

{% hint style="info" %}
The generated script asks the game for every model once, then places the rows, so a layout streams the way the game streams everything else rather than one file at a time. A light's direction and reach are worked out at load, and what is near enough to draw is swept a few times a second rather than every frame.
{% endhint %}

## Importing

**Import** in the browser rail. Paste the file, give it a name, bring it in. Three kinds are read:

* **A layout file** from this editor: everything comes back, lights and hidden pieces included.
* **ymap XML** as a map tool writes it. Props come back where they stood, with their tint.
* **Spooner XML**, and the older `MapObject` kind. Props come back with their tint; vehicles and peds are counted out, because a layout is props and a car quietly turning into nothing would be worse than a number saying so.

What it refuses, and why:

| Message                                                  | What happened                                         |
| -------------------------------------------------------- | ----------------------------------------------------- |
| That is not a layout file this can read                  | the text is not any of the three                      |
| That file comes from a newer version of this editor      | a layout file written by a later version              |
| That XML is not a map this can read                      | XML, but not a `CMapData` or a spooner placement list |
| That file stores its rotations in a way this cannot read | a rotation order this cannot convert                  |
| A layout is already called that                          | pick another name; nothing was overwritten            |

An import counts the models it does not recognise and says how many. A file written on another server can name that server's own prop packs, and those rows come in fine and then stand up as nothing here.

## Rotations

Everything here writes and reads rotation order 2 (ZXY), which is what the game uses for an object. A layout file records the order it was written in, so a file from a later version that changes it is refused rather than read wrong. The ymap export writes the quaternion a map file expects.