Hello, I am relatively new to unreal engine compared to the amount of experience I’ve accumulated in unity, so I’m a bit confused as to why this plugins “Pawn Class” if that’s the correct term for it, seems to be falling through the floor.
I checked the capsule collider on the pawn actor, and all but WorldStatic was set to ignore, however world static is set to block. I’ve set the floor to BlockAll as well for testing purposes, which seems to force it into WorldStatic
I checked the position of the collider and the camera positions, and it seems that it’s not a matter of relative position changing, but the whole actors position
I set it to print a message if any collision was detected on the pawn, however none displayed
I’m a little stuck as I am unsure as to whether its an editor specific, or plugin specific issue
– edit: Oh man, turns out its a situation where I knew the answer and forgot. It was because I forgot I had to change the play mode to VR Preview
When attaching the lever in a BP using a Socket, everything works fine unless the socket contains a rotation. In that case:
When using ‘Set Lever Angle’ with LeverRotationAxis Z, ‘Get Lever Angle’ returns the same value as I’ve just Set, just as you would expect.
When using ‘Set Lever Angle’ with LeverRotationAxis Y or X, ‘Get Lever Angle’ returns different values. Setting to 85 returns 117, for example. ‘Get Lever Angle’ also only returns hole numbers so it appears to be rounded.
Is this behaviour expected? Is it something that can be fixed? For now the only workaround that I can see avoiding rotation in the Socket attachement.
If you are during play attaching or moving the lever to something you need to call ResetInitialLeverLocation so it re-calculates its new relative world space.
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.
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.
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.
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)
(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
