Rendering and display helpers mutate global client state. Treat them as shared engine controls, not ordinary per-view settings. A mod should read capability and readiness directly, but user-facing changes should normally go through the owning settings or loading flow.
Graphics ownership model
| State | Owner | Modding rule |
|---|---|---|
| Graphics preset and option indexes | Settings core and graphics UI | Use owner flows for validation, preview, rollback, persistence, and restart prompts. |
| Window mode, monitor, and resolution | Native display manager | Expect device resets and GUI/layout rebuilds. |
| Dynamic render resolution and color grading | Renderer/settings preview flow | Snapshot and restore temporary changes; never leave a preview mutation global. |
| World drawing and loading visibility | Client loading and space lifecycle | Preserve previous values and do not force-enable drawing during teardown. |
| Hangar subhangar scene groups | Native hangar space and route owners | Borrow through the current hangar owner; do not guess standalone space paths. |
| Space item visibility mask | Avatar/space owner plus native visibility bits | Modify only owned bits and restore them without clearing server-owned bits. |
Capability checks versus mutations
Helpers such as graphics preset lookup, renderer-pipeline checks, shadow/SSAO/decal support, dynamic-resolution state, monitor enumeration, and FPS/statistics queries are useful evidence. They do not imply that a mod owns the corresponding setting.
- Use capability checks to choose fallback visuals or disable unsupported effects.
- Use the settings-core apply path when a user-facing setting must change.
- Respect apply-method results such as immediate, delayed, device-recreation, or restart-required changes.
- Do not call override helpers for ordinary preferences; they are generally infrastructure or emergency paths.
Read by topic
Choose a focused chapter. Complete examples and reference details are preserved on their topic pages.