XR Slider

Category: Executor Tier: Pro

Purpose

A grabbable slider control for in-world XR panels.

Runtime Behavior

Host Node3D (in practice the handle mesh/body). The handle’s parent defines the track: the parent’s local +Y is the travel axis, and the handle’s authored local X/Z are preserved, so the track can be moved or rotated with its panel and the control follows.

Inputs None. The brick polls its configured hand each physics tick; it requires no Listener or Gate wiring.

Why no Listener/Gate: an earlier attempt routed slider input through the shared XR grab gate (switching it AND → OR and adding trigger listeners). That stopped the grab executor dispatching entirely — the grab listener still fired but no executor ran. Slider input is therefore deliberately kept off that pipeline.

Properties

  • variable (Variable Name, default ""): Variable that receives the slider’s value. This is what the control actually drives. Empty = the control moves but publishes nothing.

  • scope (Enum, default "Global"): Global, Local. Where the value is written.

  • value_min (Float, default 0.0): Value published at the bottom of travel.

  • value_max (Float, default 1.0): Value published at the top of travel.

  • travel (Float, default 0.12): Half-length of the track in metres. The handle slides ± this along the parent’s local Y.

  • ease (Float, default 0.5): Smoothing applied to the handle. 1.0 follows the pointer exactly; lower values take controller tracking jitter off it without adding visible lag.

  • aim_radius (Float, default 0.12): How close the pointer ray must pass to the handle to engage it.

…

Generated UI Mockup — showing expanded properties
XR Slider
-
x
Name:
Label this brick...
Variable:
v
Scope:
v
Value Min:
v
Value Max:
v
Travel:
v
Ease:
v
Aim Radius:
v
Hand:
v

Properties

This brick does not expose a generated property table yet. See the source specification for implementation notes.

Notes

  • Travel is a single axis (parent local Y). Two-axis pads are not covered by this brick.

  • The handle is positioned directly by this brick each tick while engaged; do not also drive it with a Transform3D brick.

  • aim_radius is a ray-proximity test, not a physics query, so the handle needs no collider for the control itself to work.