tehAon’s SteadyView – Pick a Frame Rate and It Holds It (Client-Side)

A player on Nexus said the memory guard was fundamentally flawed and was hurting performance rather
than helping it. They were substantially right, and the mod's own instrumentation is what confirmed
it. This release acts on that instead of arguing with it.
**Changed — the texture streaming budget is no longer written by default (`MemBudgetCap=false`)**
The premise was that `GetStreamingMipmapBudget() => graphicsMemorySize * 0.9f` — 22 GB on a 24 GB
card, with no reference to system RAM — was pulling resident memory up behind it. Re-reading 7009
logged samples from about nine hours of play says otherwise on every count:
- **The budget was never the binding constraint.** Texture memory never exceeded **6136 MB** against
the 22118 MB budget, and `Texture.desiredTextureMemory` — the streamer's own pre-budget demand —
never exceeded **4410 MB**. Any cap above ~4.4 GB was inert.
- **The memory was not there to reclaim.** Unity's mipmap streaming holds no persistent CPU copy of
streamed textures; mips go from disk to the GPU through a fixed staging buffer, so the budget
governs video memory. The log shows it plainly: texture memory fell **5484 → 2717 MB** when the cap
tightened while resident memory **rose 16706 → 18532 MB** across the same thirteen minutes.
- **A cap below demand costs something real.** In **10% of all samples** the streamer was left wanting
more than it was allowed — Unity dropping mips it had decided it needed and re-reading them from
disk — in exchange for no memory at all.
The lever is kept, off, for anyone on a small machine who wants to experiment, and documented as an
experiment rather than a fix.
**Added — a cap can no longer starve the streamer (`MemBudgetDesiredMargin`, default 1.25)**
When the cap is enabled it is now floored at `Texture.desiredTextureMemory` × this margin, quantised
to 128 MB, and re-evaluated as the world loads rather than only when the pressure tier moves. Values
below 1.0 are refused. A new self-test asserts the floor …

Documentation only for anyone on Linux; a correction for everyone else.
**Fixed — the mod never said its memory half is Linux-only, and one log line claimed the opposite**
Every memory sensor reads `/proc` (`self/statm`, `meminfo`, `self/maps`, `self/smaps_rollup`) and
there is no second source. On Windows or macOS the first read throws, `procDead` latches, and
`Decide()` short-circuits — so the pressure tier never leaves 0, `MemHoldRenderTier` never fires,
and `MemProfile` never runs. That was true in every previous release and was never disclosed, on a
mod whose audience is mostly on Windows.
Worse, the fallback log line told those users the mod was *"keeping the static streaming-budget cap,
which is the part that matters most, and skipping the adaptive half."* That was the claim 0.5.0
retracted, and the cap has been off by default since 0.5.0 — so the one message non-Linux players
ever saw was wrong twice over. It now states plainly that the memory half is inert for the session
and that the render ladder is unaffected.
The README, the config file and the Nexus page all say it now too.
**Unchanged**
No behaviour changes. The render ladder — the governor, the prediction, every quality lever — is
platform-independent Unity state and always has been. It is what the mod is for and it is untouched.

Three releases in one, for anyone coming from 0.5.1. Two of them fix the ladder getting stuck — which
is the complaint that matters most for a mod whose whole job is picking the right rung.
**0.5.2 — a noisy frame time could strand the ladder at its deepest rung indefinitely.** The dwell
clock (the "has the game wanted this for a while?" timer that stops a single hitch from moving the
ladder) keyed on the exact demand *value*, so any change at all restarted it. On a busy frame the
value never held still, the timer never matured, and the ladder stayed where it fell. It now keys on
the *condition*, not the value. The log was also blaming the wrong cause for it. Found in a live
session.
**0.5.3 — running out of memory froze the ladder wherever it happened to be standing.** While memory
was critical the governor stopped moving in both directions. That reads as cautious, but it means the
rung you keep is whichever one you were on when pressure hit — and if that was the ugliest one, you
stayed there. Found by playtesting 0.5.2.
**0.5.4 — a lost connection could leave the client spinning, holding the whole world, deaf to
`kill -TERM`.** A `NullReferenceException` out of `XUiC_CategoryList.OnClose` travelled up every
parent `OnClose` into `XUi.Shutdown` and out of `GameManager.SaveAndCleanupWorld`, so the world never
finished unloading: ~280% CPU, 13 GB resident, ignoring `SIGTERM`. Now caught, plus a fourth net at
`XUiWindowGroup.OnClose` so one window's teardown cannot take the rest of the shutdown with it.
Also corrected in the docs: this hang is **not** only a low-memory failure. The session that found it
had no stall at all — 82 fps one second before the disconnect, worst stall 212 ms. Teardown is
teardown; whatever ends the session reaches the same code.
No change to the memory half's conclusions from 0.5.0: the texture streaming budget cap stays **off by
default**, for the reasons on the mod page. The memory instrumentation remains Linux-only and says so
at startup …

- **Claims game 3.2.0.** `GAME_VERSIONS` widens from `V3.0.0-V3.1` to `V3.0.0-V3.2.0`.
Verified in game on a real V3.2.0 b10 client, not inferred: see `VERIFIED` for what was
actually exercised. No behaviour changed — this release is the claim and nothing else.
## Unreleased
**Fixed — a fourth teardown net: quitting while holding an auger threw an NRE**
```
NullReferenceException
at Inventory.get_Item (System.Int32 _idx)
at ItemInventoryData.get_itemValue ()
at AnimatorRangedHoldState.OnStateUpdate (...)
```
`AnimatorRangedHoldState` keeps a motor tool's idle loop in step with its magazine, and does it by
reading `actionData.invData.itemValue.Meta` **every frame the tool is held** — a read that walks
straight into the live inventory. Quit holding an auger and the animator gets one more tick after
the inventory is gone.
Unlike the three UI sites this does not hang the client — shutdown completed every time it was
seen — but it is the same pattern (something holding a reference the teardown already invalidated),
and it prints at exactly the moment a genuine shutdown fault would be worth reading. Now caught by
a finalizer under `FreezeFix`, like the others, and reported once.
**Fixed — the leak probe's verdict counted snapshots, so it called a reused singleton a leak**
The headline conclusion of the whole probe was derived from the number of *snapshots* holding a
survivor, not the number of *distinct objects* held. A process-lifetime singleton appears in every
snapshot ever taken while leaking nothing, so the count climbed with the rejoins and read exactly
like an accumulating collection. Three sessions of logs said this:
```
leakprobe cycle 3 down — distinct instances still held: World 0, XUi 1, LocalPlayerUI 1, player 0
leakprobe cycle 3 down — stale worlds 3/2 [cycle 1:XUi#827f58(live), cycle 2:XUi#827f58(live),
cycle 3:XUi#827f58(live)] — 3 stale worlds are held — an accumulating root
```
The same `#827f58` three times: one object, counted three times, announced a…

- Claims game 3.3.0. No code changed. Game 3.3 is the stable release now and this mod already works on it, so the supported range widens from V3.0.0-V3.2.0 to V3.0.0-V3.3.0. Checked, not assumed: every game member the DLL binds to resolves against the 3.3.0 (b18) build and every Harmony patch target is still there. (It stands down on a dedicated server by design, so a server boot shows only that it loads.). It has not yet been played on a 3.3 game: no 3.3 client was available when this was cut.