You can create and load custom Controller Profile’s to offset the controllers to match a stock, or add a relative offset in the grip step to the target grip transform. Both function the same.
@mordentral
Found a bug.
I have downloaded the latest version of the demo project GitHub - mordentral/VRExpPluginExample: VRE Example Template
If you set the AttachmentGrip mode for the Gun Base blueprint as in the screenshot, then if you grab the weapon with one hand and hold it down to exit the running VR mode via Esc, you will get an exception as in the screenshot.
It looks like the problem is in the C++ code of the plugin. Because I tried to directly attach a weapon using the GripObjectByInterface method, bypassing the extra code, as in the screenshot, and ended up with the same error, stack overflow (((
And this problem is only with the AttachmentGrip mode.
Any ideas, a quick way to fix this? I need the AttachmentGrip mode because… with it, the weapon behaves as it should and does not twitch/catch up with the hands when the character moves from side to side.
Sounds like the engine issue with attachment ensures, not the plugin itself.
You can use physics only or the hybrid with sweep grip modes as well though, they also won’t have latency.
Edit Also what engine version? appears to work correctly in 5.3
I’m using version 5.3.2 of Epic Launcher.
It might work on the C++ version of the engine, but I don’t.
Im using the launcher as well, and no such issue. Also your crash is in the scene outliner, not the game logic.
I’m using oculus quest 2, connecting via air link and then launching VR preview.
OpenXR plugin included.
It’s very strange that we have different results on the same version of the engine and plugin…
Question:
As I understand it, in order for any object to be held with both hands, it must be either a static mesh or a skeletal mesh.
But what if an object, for example a weapon, consists of several parts. skeletal mesh part with a handle and magazine, there should be a Primary Grip and the second part of static mesh is the barrel, which you need to hold with your other hand.
What to do in such a situation?
I tried GrippableActor and added a skeletal mesh and a static mesh to it, but it didn’t work.
UPD:
Is it best practice to use this?:
Create a GrippableActor and add a collision to it as root.
Add skeletalMesh and StaticMesh to the collision, arrange them so that the parts become one whole weapon. Align the collision so that the weapon fits completely into it. Add two HandSocketBases to the collision, position the HandSocketBases in the right places on the weapon.
This design seems to work, but I’m not sure if this is the best solution and whether it will work correctly over the network.
If its using physical grips (physics based) you can use multiple full grips across the entire weapon and be fine, and grip sub parts of it as well. If using logical grips that is a different thing all together, which is why secondary attachments exist, to give logical grips something to “rotate towards”.
And no it doesn’t need to be static or skeletal, it just needs to be a primitive period. The plugin can’t infer which sub component you actually want to hold and children can’t move their parents in engine.
If you want modular weapons then sure, what you described would likely be easiest for you to do as it lets any grip method work with it. You would just have to have the baked collision to match the sub parts ready.
Thanks for this plugin.
I wondered is there a way to determine what type of HMD is in use in UE 5.3?
I want to display a different guide image for the controller buttons for VALVE Index, HTC VIVE and Oculus.
GetHMDType returns DT unknown for my VALVE index
Any ideas? it seems that detecting the HMD is the most complex thing ever, even tho’ XRDeviceVisualization can display the correct controller mesh, I can’t figure how to get this info out of it.
GetHMDType returns which runtime is being ran, if you are on openXR that is a moot point.
You likely want to use GetXRMotionControllerType from the openXR expansion function library.
Also the engines UHeadMountedDisplayFunctionLibrary has a GetHMDData that returns the hmd name.
Thanks for getting back to me.
I have tried ‘GetMotionControllerData’ that worked until it decided not to just this afternoon. Get HMDData just says ‘Steam VR/Lighthouse’, not much use. I tried ‘GetXRMotionControllerType’, sadly that fails.
So my question now is , if it’s working for you, what’s has happened to my VR setup this afternoon, that has changed how it works, when all I did was to calibrate the HTCVive trackpad.
Sounds like you are running steamvr native now instead of openxr?
GetXRMotionControllerType would be failing because you aren’t on openXR now. I have a steamvr expansion plugin that is removed in current versions but had hmd types over steamvr in builds before 5.0.
However you really don’t want to be native steamvr, you really want to be working through openXR.
Thanks for getting back to me, ok so I’m running SteamVR, (which incidentally updated yesterday to 2.3.5), I see under OpenXR tab that Current OpenXR Runtime: SteamVR
Is this correct?
(Used to be that running an Oculus HMD, I had to swap to Oculus to be the OpenXR runtime in the Oculus App.
THEN swaping to an HTC VIVE HMD set SteamVR to be Open XR runtime in SteamVR App)
If you have openXR as the default (highest priority) hmd runtime in engine then yes that is fine.
Thanks! that seems to work!
(i opened BaseEngine.ini from
C:\Program Files\Epic Games\UE_5.3\Engine\Config
and set HMD priority like this:
[HMDPluginPriority]
; Since SteamVR also works with the Oculus Rift, give priority to the native Oculus plugin before trying SteamVR.
; OpenXR is production ready and, if enabled, should be the priority plugin. For 4.27, we still need to prioritize
; the native plugins due to runtime features that are not yet supported in OpenXR.
OpenXRHMD=40
SteamVR=30
OculusHMD=20
Likely final list of changes prior to 5.4 coming out (I assume it will be soon)
Hello @mordentral
We’re having an issue getting the velocity of the client player.
Our game is multiplayer and LBE, so no movement done with input, only with real physical movement.
We are trying to get the velocity of that movement to drive the animations on the client.
Currently, we get the component velocity of the replicated camera of the vr character. This however returns a valid velocity on one frame, but then a zero velocity and the 2 next frames.
Due to that, our animation looks jittery and buggy.
Is there something we’re missing? Is this a known thing?
Thanks in advance for your time.
You are likely hitting a smoothing stop where its waiting for network updates. I don’t know what smoothing you have set on the camera but if its fast enough that it outpaces the network sends then it won’t have any velocity between updates.
You may want to use a running average on the velocity output.
Thanks! Doing that worked for me ![]()


