For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

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.

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.

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.

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.