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.