DungeonLoadingOptimizer

Makes landing on a moon faster and removes the freeze that cuts your voice while the interior loads.

⚠️ ALPHA — read this before installing

This build is published for compatibility testing on large modpacks. It has been measured and it works, but multiplayer determinism has not been verified yet: the two-client test that confirms every player generates the same interior and the same navmesh has not been run.

Do not use it on a save you care about, and do not assume it is safe for a full lobby yet.

Tested on Lethal Company v81 only, as host, on Experimentation, Assurance and Titan.

What it actually fixes

Since v80 the game already generates interiors asynchronously, so this is not another Loadstone. Two real defects remain, both found by decompiling v81.

1. The frame budget is broken. RoundManager.GenerateNewLevelClientRpc sets DunGen's per-frame work budget to 1 ms, and DunGen measures wall-clock time — its stopwatch keeps running through the frame's rendering. By the time the generator resumes, ~16 ms have passed, the 1 ms budget is long gone, and it yields on the very first check. Generation therefore runs exactly one work unit per frame, which is why landing takes several seconds of mostly doing nothing.

2. Every navmesh bake blocks the main thread. Nothing in the stock game uses the incremental navmesh API. Dissonance captures your microphone on the main thread, so this is precisely what cuts your outgoing voice while everyone else's keeps playing.

Measured results

Same moon, host, compared against a control run with the mod disabled:

Numbers come from the mod's own load report, which you can read in the BepInEx log. Interiors that are bigger or more heavily modded than Titan should benefit more, not less.

Configuration

Everything is toggleable, and General.Enabled = false turns every module off while leaving the measurements running — that is the control case if you want to compare on your own machine. LethalConfig is supported if installed.

The setting worth knowing is FrameBudget.Preset, which trades framerate against load time:

• FpsPriority (2 ms) — generation stays unobtrusive, framerate barely moves, loading gains less
• Balanced (6 ms) — the default
• Speed (12 ms) — shortest load, heavier frames while loading

If anything misbehaves, NavMesh.Mode = Vanilla reverts to stock navmesh behaviour while keeping the loading-speed fix.

Compatibility

Built to sit alongside the usual suspects rather than fight them. It patches four methods (DungeonGenerator.ShouldSkipFrame, RoundManager.FinishGeneratingLevel, NavMeshSurface.BuildNavMesh, DungeonFlow.HasMatchingTagPair) and logs any foreign patch it finds on them, so conflicts show up in your log instead of as mystery behaviour.

• PathfindingLib — recommended. Its NavMeshLock keeps background pathfinding jobs from reading a navmesh mid-rewrite. Without it, the async navmesh path automatically falls back to a safer mode.
• LethalLevelLoader, PathfindingLagFix, LethalPerformance — no overlapping patches. Verified by scanning their assemblies.
• LethalFixes already handles Dissonance log-spam lag spikes; this mod deliberately does not duplicate that.

Deliberately not done: forcing async generation (the game does it already since v80), patching Generator_OnGenerationStatusChanged (fixed in v81), and touching navmesh voxel/tile size — that last one would change navmesh geometry, which feeds synced scrap placement, which means desync.

Source and issues

github.com/mariusvn/LC-DungeonLoadingOptimizer

Reporting a problem

Please include the BepInEx log. Every load prints a report block starting with === LOAD REPORT, and it contains everything needed to diagnose: per-phase timings, frame statistics, and the layout and navmesh fingerprints. If two players in one lobby print different fingerprints, that is a desync and it is the single most valuable thing you can report.

Changelog

0.1.0 — alpha

First public build. Released for compatibility testing on large modpacks only.

What it does

• Frame budget — fixes DunGen's per-frame work budget. Lethal Company sets it to 1 ms and DunGen measures wall-clock time, so the budget is already spent by the time the generator resumes and only one work unit runs per frame. Measured on Titan: 1.00 → 9.53 work units per frame.
• Non-blocking navmesh — the navmesh bake is captured and driven through NavMeshSurface.UpdateNavMesh, reusing the surface's existing data so only the changed regions are rebuilt. Measured on Titan's outdoor surface: 1806 ms blocking → 153 ms, none of it blocking the main thread.
• Phased level finalisation — FinishGeneratingLevel is spread across frames, and the completion RPC is held until the bakes finish so nothing spawns onto an incomplete navmesh.
• Load report — per-load timings, work-unit counts, frame statistics, and layout/navmesh fingerprints.

Measured against a control run on Titan, the worst frame of the whole landing goes from 1815 ms to 106 ms.

Known limitations

• Multiplayer determinism is not verified. The two-client test comparing layout and navmesh fingerprints has not been run. Until it has, treat desync as an open possibility.
• Only tested on Lethal Company v81, as host, on Experimentation, Assurance and Titan.
• The watchdog path (FinishSequence.MaxFinishSeconds) has not been exercised in a real failure.