Portal management

Portals connect the rooms of the navigation tree (spawn → sub-lobbies → chapters → levels). A portal is deactivated at start; activating it creates and links a puzzle room. A portal placed inside a room gives access to a sub-room — this is how the tree is built, by spatial containment.

Portal create command

• Stand where you want to create a new portal.
• Type /. portal create.

Portal set teleport exit destination command

• Stand where you want to the player to appear when he returns from the portal's room.
• Type /. portal setTeleportExitDestination.

Portal activate command

• Stand next to a deactivated portal.
• Type /. portal activate <template name> "<room description>".

This will copy the room template with the given name and create a new room with the given description. The portal will be linked to this room.

Portal copy command

• Stand next to a deactivated portal.
• Type /. portal copy "<existing room description>" "<room to create description>".

This will copy the room with the given description and create a new room with the new description. The portal will be linked to this new room.

Portal deactivate command

• Stand in the lobby near to an activated portal.
• Type /. portal deactivate confirm.

This will delete the puzzle room with all its content and deactivate the portal.

Note: The room will be deleted definitively. Be careful when using this command.

Portal delete command

• Ensure the portal is deactivated
• Stand next to the portal, less than 3 blocks away.
• Type /. portal delete.

Portal info command

• Stand next to a portal, less than 3 blocks away.
• Type /. portal info.

This will display information about the nearby portal: its room description, its path in the navigation tree, whether it is a Hub (leads to a sub-lobby/chapter that contains other portals), its access conditions (gating), its order segment and its teleport exit destination.

Portal swap room command

• Type /. portal swapRoom <room 1 description> <room 2 description>.

Portal swap room here command

• Stand next to a portal (it can be deactivated), less than 3 blocks away.
• Type /. portal swapRoomHere <room 2 description>.

Portal orderInsert command

• Type /. portal orderInsert <origin room description> <destination room description>.

Only usable if the destination portal is in the lobby.

This command makes the origin room the new destination of the destination room's portal. The room previously linked to that portal becomes the destination of the next lobby portal, and so on until every portal destination has been shifted by one position.

Portal orderInsertHere command

• Stand in the lobby, next to a portal (it can be deactivated), less than 3 blocks away.
• Type /. portal orderInsertHere <origin room description>.

This is the local variant of orderInsert: the destination portal is the one near the player. The origin room is inserted at this position and all next portals' rooms are shifted.

Portal moveRoomToPath command

• Type /. portal moveRoomToPath "<room description>" "<path>".

This moves the room identified by its description to the free (disabled) portal designated by its <path> (the path shown above a portal and in /. portal info, e.g. solo.1.3, including automatically numbered ones). The target portal must be free (no room on it) and must have a teleport exit destination; otherwise the command refuses with a clear message (room not found, unknown path, target already occupied, target without a teleport exit, or a move that would create a cycle). Unlike swapRoom, it does not exchange two rooms — the source portal simply becomes free.

Portal moveInactivePortalsToHubEnd command

• Stand in the community lobby or inside any hub room.
• Type /. portal moveInactivePortalsToHubEnd.

This command compacts the portals of the hub you are standing in: every inactive (empty) portal is pushed after the active ones by moving the rooms forward, following the hub's portal order (manual order segments, or the automatically numbered ones when no segment is set). Portals of sub-hubs and of the parent hub are never touched.

Portal activateWithExistingBuild command

• Stand next to a deactivated portal, less than 3 blocks away.
• Type /. portal activateWithExistingBuild "<room description>" <minX> <minY> <minZ> <maxX> <maxY> <maxZ> <spawnX> <spawnY> <spawnZ>.

This links the nearby portal to an already-built space delimited by the given min/max corners, with the given spawn point. Unlike activate, it does not paste a template, scan blocks, create a LasersEnigma area or auto-tag the room. It is used to adopt an existing build (for example to turn the legacy lobby into the Community room).

Portal setOrderSegment command

• Stand next to a portal, less than 3 blocks away.
• Type /. portal setOrderSegment <name|number>.

This sets the order segment of the portal — the last part of its path among its siblings (the portals sharing the same parent). Use a name (solo, duo, community) for the three spawn portals, or a number to order levels/chapters within their parent. The full path is recomputed from the tree (solo.1.3, community.5, …). A segment cannot contain a . — it is the separator between segments in the full path, so the command rejects it.

Automatic numbering

When a portal has no manually-set segment, it is auto-numbered 1..N among its siblings (the portals sharing the same parent). The ordering depends on where the portal is:

• Inside the Community lobby (the area defined in the config): by spatial position — Y, then descending X, then Z.
• Everywhere else in the tree: by room difficulty (easiest first).

A manually-set segment always takes precedence over the auto number, and auto numbers skip any value already used by a manual numeric segment of the same parent, so paths stay unique within a parent. Auto numbers are positional, so adding, removing or reordering siblings can shift them — set a manual segment with setOrderSegment / insertOrderSegment if you need a level's path to stay stable (e.g. when it is referenced by an access condition).

Portal insertOrderSegment command

• Stand next to a portal, less than 3 blocks away.
• Type /. portal insertOrderSegment <number>.

This inserts the portal at the given numeric segment among its siblings and shifts the following siblings up by one, keeping a contiguous ordering.

Portal accessConditions command

• Stand next to a portal (hub or level), less than 3 blocks away.
• Type one of:
  • /. portal accessConditions add <levelsSolved|bonusesObtained> <count> [path]
  • /. portal accessConditions add <hubSolved|hubSolvedWithAllBonuses> [path]
  • /. portal accessConditions add levelSolved <path>
  • /. portal accessConditions add isAuthor
  • /. portal accessConditions clear
  • /. portal accessConditions info

This manages the access conditions that gate teleportation through the portal, evaluated per player:

• levelsSolved <count> [path] — at least count levels solved (under path when given, server-wide otherwise).
• bonusesObtained <count> [path] — at least count bonuses obtained (under path when given, server-wide otherwise).
• hubSolved [path] — every level under path solved. Self-adapting: unlike levelsSolved <count>, it tracks the current level count, so it never needs editing when levels are added or removed.
• hubSolvedWithAllBonuses [path] — every level under path solved and all of their bonuses obtained.
• levelSolved <path> — one specific level solved: the one whose path is exactly <path> (no subtree semantics, unlike levelsSolved). The path is required. Fail-closed: a path that matches no level (hub path, typo, removed level) keeps the portal locked.
• isAuthor — the player must be one of the authors of the room the portal leads to (handy to reserve an in-construction level to its creators).
• clear — removes all access conditions from the portal.
• info — lists the portal's current access conditions.

Conditions are combined with AND. A portal with no condition is open by default. A targeted hubSolved / hubSolvedWithAllBonuses whose path currently contains no level stays locked (fail-closed) rather than vacuously unlocking — so an emptied or mistyped hub path never silently opens a portal. There is no per-condition removal: to change one of several conditions, clear and re-add them.

A target path is accepted only when every segment along it is a manual order segment. If the leaf or any ancestor is auto-numbered, the path is unstable and the add is refused — give every level on the path a manual segment first. Symmetrically, once an access condition references a path, the portal mutations that would change that path are refused with the list of dependent portals: deleting/deactivating the target subtree, setting/inserting an order segment, swapping/moving rooms (swapRoom, swapRoomHere, orderInsert, orderInsertHere, moveRoomToPath) or compacting a hub (moveInactivePortalsToHubEnd). Clear or re-pin the dependent conditions first, then retry the mutation.

Examples — lock a hub behind another being fully finished: accessConditions add hubSolved solo.1. Require partial progress in two branches: accessConditions add levelsSolved 6 solo.1 then accessConditions add levelsSolved 4 solo.2. Lock a level behind one specific other level: accessConditions add levelSolved solo.1.3.

Portal bypassAccessConditions command

• Stand on the active portal you want to enter.
• Type /. portal bypassAccessConditions.

Admin only (lasers.admin). Teleports you through the portal ignoring its access conditions — a one-shot escape hatch to test gated content without satisfying the conditions.

Portal placeNextLevelPortal command

• Stand on the block where you want the next-level portal.
• Type /. portal placeNextLevelPortal.

This places a next-level portal at your feet. Stepping onto it teleports the player to the first level they have not solved yet, scoped to the path of the room that contains the portal (server-wide when placed outside any room). Several next-level portals can be placed (one per sub-lobby/chapter).

Portal deleteNextLevelPortal command

• Stand on the next-level portal.
• Type /. portal deleteNextLevelPortal.

This removes the next-level portal at your feet.

Portal colours

The triangle above a portal — and its label — are rendered per player: two players with different progress see different colours and texts on the same portal at the same time.

The label also adapts to the game mode: creative/spectator builders see the full technical path (e.g. solo.1.3) on its first line, while survival/adventure players don't. Instead, the room name is prefixed with a friendly number derived from the level's last path segment — #3 <name> — both above the portal and in the title shown when entering the room (the full path always stays in the entry subtitle). Portals whose path has no numeric tail show no number.

Level portals

State	Triangle colour
Locked (access conditions unmet)	Gray
Not completed yet	Difficulty colour — Easy: light blue · Medium: green · Hard: yellow · Legendary: red · Mythic: purple
Completed, some bonuses missing	Yellow
Completed, all bonuses obtained	Light gray

The label above the portal states why it is accessible or locked, so the colour overlap between a Hard level (difficulty yellow) and a completed-missing-bonus level (yellow) is never ambiguous in practice.

Hub portals (sub-lobbies and chapters)

A hub has no puzzle of its own, so its colour aggregates the progress of the levels under it, and its label shows the counts (✔ solved/total · 🏆 bonuses/total).

State	Triangle colour
Locked (access conditions unmet)	Gray
Not started (no level under it solved)	Blue
In progress (some, but not all, levels solved)	Green
All levels solved, some bonuses missing	Yellow
All levels solved, all bonuses obtained	Light gray
Empty hub (no level under it yet)	Light gray

Next-level portals

A next-level portal (placeNextLevelPortal) is rendered with a white triangle and a label, and teleports the player to their first unsolved level under the path where it is placed.