Graphics & Display State overview

Space readiness and world drawing

Geometry progress is not always visual readiness. Current loading flows combine space-load state with virtual-texture completion before revealing the world. A screenshot tool, overlay anchor, or local scene feature should wait for the same owner-level readiness instead of assuming that a space ID is enough.

  • Read the current space from the live context, not from a cached previous battle.
  • Require both the relevant space-load state and visible-world readiness when visuals matter.
  • Treat worldDrawEnabled as global state; preserve and restore the value you found.
  • Use ordinary owned callbacks for delayed work. Do not remove all idle callbacks from a shared idle controller.
  • Yield large loops across ticks instead of blocking the frame while the renderer is already under pressure.

Display modes and reset-sensitive UI

Resolution, monitor, fullscreen mode, graphics device recreation, interface scale, and color calibration can all invalidate measurements or cached view state.

  • Recompute overlay bounds after resolution or scale changes.
  • Re-read the active monitor and current resolution after display-mode changes.
  • Clamp saved panel positions against the new viewport before showing them.
  • Rebuild texture, model, and render-target assumptions after device recreation.
  • Keep temporary calibration and post-processing previews inside a clear apply/revert lifecycle.

Resolution option indices depend on the staged monitor

The resolution option builds a sorted, deduplicated list of width/height pairs for each monitor, then interprets its integer value as an index into the list selected by storage.monitor. That is not the native video-mode index. The same option value can select different dimensions after the staged monitor changes; resolve it against the intended monitor rather than carrying an old index across monitor selections.

SettingsCore gives monitor, resolution and refresh-rate options the same video storage. Resolution selection stages a width/height pair; the refresh-rate option separately stages an integer refresh value. During apply, video storage searches the target monitor's mode list for an exact width, height and refresh-rate match. A size alone does not identify that full mode.

If no tuple matches, the inspected selector returns the monitor manager's current mode when the target is the active monitor; for a different target it takes the first entry in that monitor's list. It does not rank the closest size or refresh rate, and the latter branch assumes a nonempty list. This is selection before native application, not proof of successful display mutation; re-read actual state after the owning apply flow.

Current Python source and selected controls used synthetic monitor/mode lists, inert storage and a recording FOV substitute. They checked monitor-relative indices, duplicate dimensions and refresh-sensitive exact/fallback selection. No monitor enumeration, display/FOV APIs, settings application, hardware or Python 2 client runtime was exercised.

Native hangar scenes and subhangars

This section summarizes the graphics boundary. For the complete space, vehicle, group, route, camera, CGF, and cleanup lifecycle, see Hangar & Garage Runtime.

Hangar variants are often assembled by native scene groups inside the current hangar space. A subhangar group can own lighting, cameras, CGF objects, selection components, and route-specific setup. Treat it as a borrowed native owner, not as a background path that can be loaded or replaced directly.

  • Resolve the active hangar space from the lobby owner and wait until that space is initialized and not loading.
  • Activate and release native groups through the hangar group's lifecycle instead of guessing a standalone scene path.
  • Release borrowed ownership before routes that need their own camera, lighting, vehicle placement, or preview state.
  • Schedule transform, camera, or visibility adjustments after native route changes have had a tick to settle when immediate work races lighting teardown.
  • Restore vehicle transforms, hidden native objects, callbacks, subscriptions, and wrappers on every exit path.

Replacement or synthetic hangar spaces

Using a battle or authored map as the normal garage is not the same problem as borrowing a native subhangar group. The mod becomes responsible for both the initial hangar-space selection and the native routes that expect the standard hangar systems to exist. A map can render beautifully as a garage while still lacking the camera, armor, operation, or route-specific CGF systems that other lobby views require.

  • Prepare default-space overrides before the account GUI resolves its first garage space; a late override may only take effect after a later scene switch.
  • Keep every hangar-space owner in sync. If the client has both event-hangar paths and a hangar switch controller default, updating only one owner can load the custom space and then snap back to the native default during vehicle loading.
  • Copy the current default hangar configuration as the base for a synthetic config, then replace only the space path, visibility mask, vehicle anchor, and camera-relevant fields the feature owns.
  • Use the map's normal visibility layer for the target mode instead of enabling every layer; broad masks can reveal mode-specific objects that were never meant to be visible together.
  • For routes that require native hangar systems, clear the map override before navigation and defer the original route event until the native hangar space is initialized and not loading.
  • If the replacement space lacks a usable native hangar camera system, use an owned lobby camera with explicit input subscriptions and cleanup instead of switching the garage into a battle freecam model.