DungeonLoadingOptimizer

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.

• 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.

• 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:

| Titan | Stock | With the mod |

|---|---|---|

| Work units per frame | 1.00 | 9.53 |

| Level finalisation | 2.06 s | 0.37 s |

| Outdoor navmesh bake, blocking the main thread | 1806 ms | 0 ms |

| Worst frame of the whole landing | 1815 ms | 106 ms |

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 statist