On the engine development branch, gateways can target named positions and headings in a destination place. Different entrances can lead to different sides of the same room. Existing gateways continue to use the place entrance until a named arrival is selected.
#Try it
- In the editor, select the destination place and open Arrival points….
- Choose Add an arrival, give it a name, and set its position and facing. Coordinates are in that place's local space. The position is the traveler's centre: start around 0.85 m above a solid floor, with room around it. A facing of 0° looks toward −Z, 90° toward −X and 180° toward +Z.
- Choose Preview arrivals. Gold markers in the atelier show the landing positions and directions; they are editor guides, not published world objects. Save the changes.
- Select the source gateway's light object, open Gateway…, and choose the destination and Arrival point. Preview and Save, then Apply to the shared room.
- Travel through the gateway in two browser profiles. Each traveler should arrive at the selected point facing the chosen direction. Walking forward follows that heading.
- Move the arrival point and Apply while travelers are in the destination. Their current positions remain unchanged; the next crossings use the new position and heading. Saved Undo/Redo restores the source across editor reloads.
To remove a point, first change any gateways that reference it to another point or Place entrance. The editor explains linked-point removal, and compiler validation rejects dangling links through file/API/CLI edits as well.
#Contract
World format 9, compiler arrival-world.9, adds optional Place.arrivals and portal destinationAnchor. Formats 1–8 retain their historical compiler identities. Native checkpoint profile remains unchanged. The set-arrival authoring command shares revision checks, validate-only proposals, conflict handling and retained Undo with browser edits.
Each place supports up to 16 named arrivals, identified independently of their names. Coordinates are bounded to ±100 m for the current relay profile and facing to ±one turn. References must resolve inside the portal's destination. Deleting a referenced point fails; arrival edits and dependent gateway edits conflict conservatively. Material edits elsewhere remain disjoint.
Destination collision is constructed before the live place is replaced. The authored point is not automatically projected onto a floor or checked for empty space: inspect its marker and playtest it. Native checkpoints retain the accepted position and heading. Lightweight reload saves retain position but continue to use the place's default facing. The existing relay travel profile remains unchanged; this is not server-authoritative crossing admission, streaming, visual portal rendering or a cross-host travel transaction.
#Verification
Run npm run test:browser:arrivals for the isolated production two-traveler workflow. Run npm run test:browser:places separately for the previous gateway workflow. Each scenario creates a different world and needs its own isolated relay; the CI matrix gives them separate jobs. Headless tests cover references and limits, historical compiler identity, stable command replay, exact multiple-removal undo, protected dependency edits, native arrival, live-edit occupant preservation and checkpoint restoration. Browser checks cover creator controls, marker preview, both travelers' positions and input headings, movement in the chosen direction, live edits, durable Undo/Redo and linked-point removal rejection.
See acceptance evidence.