Is your feature request related to a problem?
just tested on anewer build, much like desktop has auto hold we could use it for vr as well. Here's everything you need to hand to the Basis creator. The VR-hold feature is entirely in one Basis package (com.basis.framework/Interactions), and the old (un-reverted) copies are in your HubOne project.
The old scripts (file paths)
C:\Claude Projects\HubOne API Upgrade\Basis (HubOne Client)\Basis\Basis\Packages\com.basis.framework\Interactions\BasisInteractableObject.cs
C:\Claude Projects\HubOne API Upgrade\Basis (HubOne Client)\Basis\Basis\Packages\com.basis.framework\Interactions\BasisPlayerInteract.cs
What the change does
It makes auto-hold (sticky pickup) work in VR, not just desktop. Stock Basis only keeps an object held-after-release on desktop; this adds an opt-in VR mode plus a clean way to drop it. It's fully additive and backward-compatible (the new enum value is appended, so existing Yes/No serialized values are unchanged).
- BasisInteractableObject.cs — three additions
a) New enum value (in BasisAutoHold, appended last):
/// Like Yes, but auto-hold also applies in VR — the object stays held after the grip
/// is released, until the dedicated drop button (see IsHoldDropTriggered).
/// Appended last so existing serialized Yes/No (0/1) values are unchanged.
YesIncludingVR
b) IsAutoHoldActive() — the device-aware check:
public bool IsAutoHoldActive()
{
switch (AutoHold)
{
case BasisAutoHold.YesIncludingVR: return true; // everywhere
case BasisAutoHold.Yes: return Device_Management.BasisDeviceManagement.IsUserInDesktop(); // desktop only (historical)
default: return false;
}
}
c) IsHoldDropTriggered() — overridable VR release hook:
/// Base returns true. Override for objects with specific hold/drop behavior.
public virtual bool IsHoldDropTriggered(BasisInput input)
{
return true;
}
- BasisPlayerInteract.cs — use those instead of the desktop-only gate
The grab/release logic was changed to call the new methods. The key line:
// BEFORE (stock — VR can never auto-hold):
bool autoHold = BasisDeviceManagement.IsUserInDesktop() && interactInput.lastTarget.AutoHold == BasisAutoHold.Yes;
// AFTER (the edit):
bool autoHold = interactInput.lastTarget.IsAutoHoldActive();
bool holdDropTriggered = interactInput.lastTarget.IsHoldDropTriggered(interactInput.input);
The same IsAutoHoldActive() / IsHoldDropTriggered() pair is then used at the other grab/hover decision points — in the HubOne copy these are around lines 216–217, 364, 391–399, and 455–501. Easiest is to diff the two BasisPlayerInteract.cs files (HubOne vs current) and hand the creator that diff.
The ask, in one sentence
▎ "Please add first-class VR auto-hold to BasisInteractableObject: a YesIncludingVR enum value, an IsAutoHoldActive() helper, and an overridable IsHoldDropTriggered(BasisInput) hook, and have BasisPlayerInteract use them so sticky pickups work in VR with a dedicated drop button."
One clarification on scope
There are two layers to "lock to hand," and only the first belongs to Basis:
Sticky hold (stays in your hand) → Basis — the AutoHold/VR change above. This is what the creator needs to implement.
The weld (pins the pose rigidly to the hand) → ours, already done — RetroArchVRHandWeld.cs (controllers) and MameLightgunControl.BindGunToWrist (lightgun). Those live in our packages, not Basis, and don't need the creator.
So once Basis supports VR auto-hold again, our retro controller (RetroArchVRPickupController.cs:1463) and lightgun (MameLightgunControl.cs:406) — which set AutoHold = Yes — would lock to hand in VR again. If you'd rather not wait on the creator, the other path is to point those two AutoHold = Yes lines at YesIncludingVR and ship the Basis change yourselves, or do the package-side option (B) we discussed. Want me to prep that diff too while you talk to the creator?
Describe your preferred solution
much like desktop vr allow vr to have auto hold as well, I'm currently binding it to a drop function or a controller lock function that allows me to drop it, so I have it configured to push in on the right joystick to come out of lock mode which also grants me the ability to drop the object again.
Describe any considered alternatives
not sure
Additional Context
No response
Is your feature request related to a problem?
just tested on anewer build, much like desktop has auto hold we could use it for vr as well. Here's everything you need to hand to the Basis creator. The VR-hold feature is entirely in one Basis package (com.basis.framework/Interactions), and the old (un-reverted) copies are in your HubOne project.
The old scripts (file paths)
C:\Claude Projects\HubOne API Upgrade\Basis (HubOne Client)\Basis\Basis\Packages\com.basis.framework\Interactions\BasisInteractableObject.cs
C:\Claude Projects\HubOne API Upgrade\Basis (HubOne Client)\Basis\Basis\Packages\com.basis.framework\Interactions\BasisPlayerInteract.cs
What the change does
It makes auto-hold (sticky pickup) work in VR, not just desktop. Stock Basis only keeps an object held-after-release on desktop; this adds an opt-in VR mode plus a clean way to drop it. It's fully additive and backward-compatible (the new enum value is appended, so existing Yes/No serialized values are unchanged).
a) New enum value (in BasisAutoHold, appended last):
/// Like Yes, but auto-hold also applies in VR — the object stays held after the grip
/// is released, until the dedicated drop button (see IsHoldDropTriggered).
/// Appended last so existing serialized Yes/No (0/1) values are unchanged.
YesIncludingVR
b) IsAutoHoldActive() — the device-aware check:
public bool IsAutoHoldActive()
{
switch (AutoHold)
{
case BasisAutoHold.YesIncludingVR: return true; // everywhere
case BasisAutoHold.Yes: return Device_Management.BasisDeviceManagement.IsUserInDesktop(); // desktop only (historical)
default: return false;
}
}
c) IsHoldDropTriggered() — overridable VR release hook:
/// Base returns true. Override for objects with specific hold/drop behavior.
public virtual bool IsHoldDropTriggered(BasisInput input)
{
return true;
}
The grab/release logic was changed to call the new methods. The key line:
// BEFORE (stock — VR can never auto-hold):
bool autoHold = BasisDeviceManagement.IsUserInDesktop() && interactInput.lastTarget.AutoHold == BasisAutoHold.Yes;
// AFTER (the edit):
bool autoHold = interactInput.lastTarget.IsAutoHoldActive();
bool holdDropTriggered = interactInput.lastTarget.IsHoldDropTriggered(interactInput.input);
The same IsAutoHoldActive() / IsHoldDropTriggered() pair is then used at the other grab/hover decision points — in the HubOne copy these are around lines 216–217, 364, 391–399, and 455–501. Easiest is to diff the two BasisPlayerInteract.cs files (HubOne vs current) and hand the creator that diff.
The ask, in one sentence
▎ "Please add first-class VR auto-hold to BasisInteractableObject: a YesIncludingVR enum value, an IsAutoHoldActive() helper, and an overridable IsHoldDropTriggered(BasisInput) hook, and have BasisPlayerInteract use them so sticky pickups work in VR with a dedicated drop button."
One clarification on scope
There are two layers to "lock to hand," and only the first belongs to Basis:
Sticky hold (stays in your hand) → Basis — the AutoHold/VR change above. This is what the creator needs to implement.
The weld (pins the pose rigidly to the hand) → ours, already done — RetroArchVRHandWeld.cs (controllers) and MameLightgunControl.BindGunToWrist (lightgun). Those live in our packages, not Basis, and don't need the creator.
So once Basis supports VR auto-hold again, our retro controller (RetroArchVRPickupController.cs:1463) and lightgun (MameLightgunControl.cs:406) — which set AutoHold = Yes — would lock to hand in VR again. If you'd rather not wait on the creator, the other path is to point those two AutoHold = Yes lines at YesIncludingVR and ship the Basis change yourselves, or do the package-side option (B) we discussed. Want me to prep that diff too while you talk to the creator?
Describe your preferred solution
much like desktop vr allow vr to have auto hold as well, I'm currently binding it to a drop function or a controller lock function that allows me to drop it, so I have it configured to push in on the right joystick to come out of lock mode which also grants me the ability to drop the object again.
Describe any considered alternatives
not sure
Additional Context
No response