mirror of
https://github.com/bearstonem/openmohaa-vr.git
synced 2026-10-24 03:00:26 +02:00
bearstonemandClaude Opus 5
013b2f5bbf
Three things, all found by running it. The mission briefing was drawn onto the player's face. VR_UseScreenLayer only asked whether clc.state was CA_ACTIVE, so a fullscreen menu that comes up while the player is still in the world skipped the quad layer and was drawn as screen space 2D into both eye buffers - at the near plane, a hand's width away, with no disparity to fuse and each eye warping it through its own asymmetric frustum. That is exactly what the panel exists to prevent; nothing in-game was reaching for it. It now checks UI_FullscreenMenuUp as well. The log said so before the headset did: "view3d 0" with the eye passes still running means the 3D scene is not being drawn at all, which only happens when a fullscreen menu is covering it. map in autoexec.cfg never had a chance. That file is exec'd during Com_Init and the game's own startup - the intro stages, then the menu - runs afterwards and tears down anything loaded there. vr_startMap now waits until the client is sitting idle at the menu and loads it then. vr_testStart also prints unconditionally: a hook that silently does nothing is indistinguishable from one that never ran, and telling those apart has cost enough already. vr_captureEye is a plain archived cvar rather than a VR_TuningCvar. Those force their default at every start, which is right for a value still being argued with and wrong for a switch - it made the config's own setting impossible to honour and cost a device run to notice. The handoff warns about this exact trap. vr_traceFrame is off in the shipped config: three lines a second rolls anything that prints once out of logcat within a minute. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>