Your map node can sit anywhere in the world — but it must stay unrotated and unscaled. That one rule keeps preview, collision, occupancy, manipulation, and restore agreeing with each other.
What you can do
Move the map (TileMapLayer in 2D, GridMap in 3D) wherever your level needs it: world offsets, negative coordinates, and custom cell sizes all work. The same goes for its parent nodes — panning a whole level container is fine.
| Map | Move (position) | Rotate | Scale |
|---|---|---|---|
2D TileMapLayer |
Yes | No | No |
3D GridMap, including yaw |
Yes | No | No |
| SMOOTH (no map involved) | Not applicable — world coordinates | Rotate placed objects normally | Scale placed objects normally |
Note the distinction the table is drawing: rotating or scaling the map node is unsupported, while rotating a placed object (preview rotation, 3D yaw) is a normal, supported part of placement.
What happens if the map is rotated or scaled
Placement refuses through the normal failure report, naming the offending node. The fix is on your side of the scene tree, not in plugin settings:
- Select the map node in the editor.
- Reset its
rotationto zero and itsscaleto one. - Walk up its parents and do the same — a rotated level container counts too.
- Run placement again.
Do not work around this by bypassing the host: the preview can look right while collision or restore still reads the map's axes differently, which surfaces much later as misplaced objects or broken saves.
Why the rule exists
Every subsystem has to interpret the map's axes identically. A rotated or scaled map is a case the 6.0 pipeline deliberately does not take on, so it says no up front instead of failing halfway through a commit. Future releases may relax this; for now, treat unrotated/unscaled maps as a hard requirement.