-
Notifications
You must be signed in to change notification settings - Fork 0
Known Issues
Status: confirmed, not yet fixed (as of v0.6.5 / 2026-07-03).
All six VRControl subclasses (scripts/interactables.gd) — Lever,
TwoAxisGrip, Knob, PushButton, ToggleSwitch, SafetyCover — work
correctly in isolation (tools/xr_interaction_smoke.gd, 14/14 pass). But
the real rig's hand-proximity discovery
(scripts/xr_rig.gd, get_tree().get_nodes_in_group("vrcontrols"), used
in both the grab loop _nearest_control() and the poke loop in
_physics_process) reads from a group that nothing in the codebase ever
populates — confirmed with git log --all -S'add_to_group("vrcontrols")'
across the entire repo history, zero hits.
Practical effect: reaching out with a real hand or controller and grabbing a lever, flipping a switch, turning a knob, or pressing a button in the cockpit does not register. This does not affect gameplay through the thumbstick control scheme (see How to Play) — driving, aiming, firing, reloading, rockets, MG, and restart all work via thumbsticks/buttons regardless.
Why it wasn't caught sooner: desktop/keyboard testing
(scripts/desktop_rig.gd) and the game's own internal/AI/network driving
logic all read and write cockpit controls directly by dictionary key
(cockpit["controls"]["battery"]), never through the group. Combined with
the thumbstick fallback path above, the cockpit felt fully functional in
every test that wasn't a human physically reaching for a control in a
headset.
The fix is a one-line add_to_group("vrcontrols") (in VRControl's
constructor or cockpit_builder.gd's instantiation loop) — intentionally
not yet applied, pending verification with real headset hands, since a
finding this surprising deserves a live check (grab radius, false
positives from both hand-poke loops scanning the same group every frame)
rather than a blind patch.
Hand tracking (no physical controllers) currently supports pinch (fire) and
whole-hand squeeze (grab attempt), via XR_FB_hand_tracking_aim's
per-finger pinch strengths. There's no hand-tracking equivalent for the
physical thumbstick axes, so driving and turret aim require a physical
controller today. On-foot arm-swing sprinting works hands-free either way.
XR_FB_render_model (the zero-asset way to fetch a real controller model
from the runtime) is confirmed unsupported on Quest 3S specifically, even
though it works on Quest 1/2/3/Pro. Worked around with a bundled
MIT-licensed controller model (assets/controllers/), mechanically
animated by real input — but it will render as invisible/absent on 3S if
that fallback path regresses.
Meta's App Lab store-listing assets (screenshots, hero image) need the web dashboard; browser-automation upload hit a hard sandboxing wall when the automation session and the asset files lived on different physical machines. This is a manual step for whoever has hands-on-keyboard access to both the files and a browser session on the same machine — not something worth re-attempting through automation.
If you find something else while using this as a sample project, check first whether it's a thumbstick-vs-physical-control gap like the one above before assuming it's a design bug — several "why doesn't X work" reports during development turned out to be incomplete test assumptions, not engine bugs (see Architecture's QA harness section).