The CVar has been registered and read since the filter policy landed, and
last commit put it on the Graphics Preset ladder — but a player had no way
to reach it. The reference's own `OptionsFrameSliders` declares the row at
index 7; ours left that index a hole, so the only route to anisotropy was
`/console anisotropic 16`, and a player whose preset reads Custom (the
seeder never overwrites one) never met the setting at all.
Seated where the reference's own slider order puts it: after Brightness,
before Weather Intensity. Three things it does differently, each stated
beside it:
- The groove runs 1 to 16, the CVar's own `ANISO_RANGE`, not the stock
table's 1 to 4. That ceiling was the reference *slider's*, not the
CVar's — its callback parses 1-16 (`0x689110`) — and both the High and
the Ultra rung ask for 16. So the row carries literal bounds and stays
out of `BENILLA_GRAPHICS_SLIDER_ROWS`, exactly as `RowRenderScale` does
for a CVar the stock table never had, which leaves `OptionsFrameSliders`
verbatim for any addon that reads it.
- `1` reads out as "Off", not "1x": the reference writes filter mode 5
only at 2 and above, so 1 is the feature off and not its weakest stop.
- The description is ours. 1.12's own OPTION_TOOLTIP_ANISOTROPIC describes
a four-stop slider, and this one is sixteen.
Deferred to Apply, as Vertical Sync and Render Scale are: a sampler is
baked into each `Image` at load, so the write cannot reach a texture that
is already resident. The tooltip says so in the row rather than leaving a
player to wonder why the ground did not change — the same thing the
reference's UI means by "enabled upon restart".
Verified: `benilla-app --lib` at the exact 269-failure data-gated baseline,
set-identical by `comm`, with the new row's own test and the two census
counts (tooltip keys, raised plates) moved 116 -> 117 as the row asks.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
1c786b7ecb