“Not showing” can describe several failures. The resource may not start, the map may place the interior elsewhere, an archetype may be absent, or a room may disappear only from a particular viewpoint. Start by separating those observations.
This is a diagnostic decision process. It does not claim that one symptom has only one possible cause.
Capture the failing state
Record the resource version, target edition, coordinates, camera direction and active neighboring map resources. Keep the exact client and server errors where available. Save a screenshot that includes enough context to revisit the position.
Preserve the failing export before changing it. A failure you can reproduce is a useful test case. One that disappears after six unrelated changes teaches you very little.
Is the entire resource absent?
Check the resource path, filename and startup output. Inspect fxmanifest.lua and verify that the expected files exist with the expected case and extensions. Confirm that you are testing the intended resource folder rather than an older duplicate.
For custom archetypes, inspect the YTYP registration and references. Compare the delivered inventory with the resource packaging guide.
Do not assume that a successful command entered into a console means every dependency was available. Read the resulting output and verify the visible placement separately.
Does the asset open, but not appear in the world?
Check the chain from asset to archetype to entity placement. Use the file-format reference to keep those responsibilities distinct. Confirm the MLO archetype’s exact name and the world transform applied to the placement.
Check that the exported map reflects your latest changes, including calculated extents where appropriate. A project file saved on your workstation does not prove the server received a new YMAP.
If you authored in local space, check for a duplicated translation or rotation in the exported data and placement. Do not move the asset repeatedly until it happens to appear without first understanding which transform is being applied.
Does one room disappear at a doorway?
Return to the room graph. Record which opening, which side of the threshold, and which look direction triggers the problem. Inspect the connection and room setup using the portal test matrix.
Do not use an unrelated wide-angle screenshot as proof that the connection works. A failure at a specific transition requires testing that transition.
Compare the same route with the previous working export. If the failure began when you added a room, narrow the experiment to that change instead of rebuilding every material.
Is the room visible, but movement wrong?
Switch to collision investigation. A blocked entrance can come from collision that does not share the visible opening. Falling through a floor is not fixed by registering the same YTYP repeatedly.
Inspect the exported collision and repeat the walking route. Check overlapping resources at the same location. Disable suspects only in a controlled development environment and document each comparison.
Does the problem depend on distance or other resources?
Use fixed approach paths to distinguish distance-dependent behavior from room transitions. The author’s README explains the LOD hierarchy; it does not justify increasing every distance without inspecting the hierarchy and bounds.
For suspected conflicts, test your resource alone, then add neighboring map resources back in a known order. Record the first combination that reproduces the issue. Resource order is an observation to investigate, not a substitute for understanding duplicate or overlapping assets.
Close the loop
For each attempted fix, write the hypothesis, exact change and result. Restore the previous version when the hypothesis fails. Once a fix works, reproduce it from the source project and rerun fresh-connection tests.
Cache operations are not a diagnosis. Consider stale delivery only when your evidence points there, and follow the platform’s current guidance rather than deleting unrelated folders as a ritual.