A room can look correct from one camera angle and still have a broken visibility setup. Test transitions, not just interiors: the moment a player approaches or crosses an opening often reveals the problem.
This lesson expands the original workshop from the MLO walkthrough. It is not a collection of universal portal flags.
Keep a room graph beside the model
Draw three named nodes: outside, front room, workshop. Connect outside to the front room and the front room to the workshop. That graph is the intended relationship for this exercise. If you later add a window or another opening, update the drawing before changing the project.
The Sollumz YTYP tutorial documents rooms, limbo and portal construction. In that workflow, limbo participates in the external connection, and portal direction at that connection matters. Use the tool’s visible direction indicator and documented convention rather than deciding from a screenshot of somebody else’s project.
Give the test spaces distinct identities
Use descriptive names such as front_room and workshop. While checking the model, keep a simple record of their bounds, connected openings and expected contents. This is a test note, not extra game metadata.
Make the rooms visually distinguishable during testing. A temporary original prop or a different plain surface can make it immediately obvious which space vanished. Remove test-only objects before the final build.
Avoid moving a room boundary, reassigning entities and flipping a portal in the same edit. If the result improves, you need to know which change mattered.
Inspect each opening as a separate item
For the internal doorway, identify its four corner positions and the two rooms it should connect. Check the portal plane against the actual opening. A plane that is offset into a wall can be difficult to notice from the editor’s default view.
For the exterior doorway, independently inspect the connection to limbo. Do not assume that copying the internal portal produces the correct external setup. After edits, export a matched set of files rather than only whichever file you last opened.
A portal does not remove a wall, provide a walking surface, or implement a moving door. If visibility works but movement is blocked, switch to the collision test instead of continuing to alter portal settings.
Use a doorway test matrix
| Position | Look direction | Expected observation |
|---|---|---|
| Outside, before the entrance | Into the front room | The intended entrance view is visible |
| Just inside the front room | Back toward the street | Exterior visibility behaves as designed |
| Front room, before the inner doorway | Into the workshop | The connected room is visible through the opening |
| Workshop, before the inner doorway | Into the front room | The reverse connection behaves consistently |
| On either side of a threshold | Slowly rotate the camera | No unexplained disappearance tied to the transition |
These are proposed acceptance tests for this example, not a guarantee that every MLO must expose every room from every position. Record the visibility you intended before judging the result.
Diagnose with observations
If the workshop disappears only while looking through its doorway, record the camera position and direction. Inspect that connection before altering unrelated materials. If the whole interior is absent after reconnecting, first establish that the resource and archetype loaded.
If the problem occurs near a room boundary, compare the behavior at a series of positions along the same route. A repeatable boundary is more useful than “sometimes invisible.” Retain the last working export so you can test whether a new room or portal edit introduced the issue.
Once the two-room setup is stable, add one extra opening or room at a time. Scale the test matrix with the graph; do not replace a small proven model with a large untested one in a single export.
Match room bounds, portals and entity assignments
The Sollumz YTYP walkthrough documents creating an MLO definition, adding limbo and interior rooms, setting bounds from selected vertices and defining doorway portals. Use the installed version’s controls; do not interchange a project UUID, an archetype identifier and a collision room ID because all three look like “room numbers” in a screenshot.
For the two-room exercise, keep a small graph beside the source: outside ↔ front room ↔ workshop. Each opening should connect the intended pair of spaces and lie on the real doorway. Check portal corner order/direction, opening size and the room assignment of each shell or prop. Inspect physical door openings separately from visibility data.
A repeatable portal acceptance route
Use the same route for every candidate: outside looking in, front room looking out, front room facing the shared doorway, workshop looking back, then the reverse traversal. Pause at each doorway instead of racing through it. Record the exact room that disappears, the camera direction and whether neighboring props disappear with it.
Change one suspect relationship, export all affected data from the same revision and repeat. A portal change that helps one direction but breaks the return route is not accepted. The MLO source example provides a constrained graph to inspect, not evidence that your final native room data already works in-game.