VR Expansion Plugin

I did a search in here but couldn’t find something (not sure what wording would be best)

Using some of the stuff from the plugin’s Vehicle in a very modified version…
Not 100% certain what specifically is limiting the player’s head movement.

Best way to set a specific area that the viewer should be able to move around inside the vehicle? Need essentially standing room (so, full height, down to floor, plus a bit of lateral movement – essentially a capsule)…

Thanks in advance whomever may have some suggestions!

You’ll need to change in the car where it sets the seated movement mode.


Turn bZeroToHead to false and it will use the AllowedRadius only in X/Y for where they can move their head.

Awesome, seems easy enough.

And will the Zero stuff still work? To recenter the camera?


You aren’t doing anything wrong, I just have input gated to walking mode in the template by default.

You would want to change this section of the HandleCurrentMovementInput function so that it still checks input when falling.

You can likely clear the movement mode checks out all together if you want and just always allow it, it was a perf check since some of the movement modes sample velocities on tick.

Its debatable that it should be setup like that, I should probably filter it by not doing it when seated or climbing instead. I’ll look at it later.

Thank you so much!

If anyone migrates content from the example project to his own be careful if you copy the config files.
You have to remove in DefaultEngine.ini →

This part or it will give you an unknow cook error message… kinda spend a lot of time figuring out why I couldn’t package even after I deleted all the content.

Hay, can I have a socket for each hand?
when A “VrGripP” socket on an object it works and grabs the object from the socket, but the location of the socket is only good for the right hand, I want another location if grabbed with the left had. is that possible?

In the template flagging the objec with the PerHandSocket gameplay tag will make it search for VRGripLP and VRGripRP instead

So I’m getting some weird behavior with the climbing in the example template. For some reason I can only use my left hand to climb if I grab underhand and I can only use my right hand to climb if I grab overhand. I did completely cut off (but not delete) some of the pin connections for things I wasn’t using in the Vive Character pawn like teleportation so maybe that affected it?. Does anyone know why this is happening?

check your collision sphere locations, climbing initiates off of overlaps / traces with those.

I’m trying to get the 2DKeyboard widget to work inside a widget, but I can’t figure out how to get the input from keyboard to editable text box?
How do you transfer the keypresses from 2DKeyboard to input for text boxes?

Am I trying to do it totally wrong here?


You should just be able to Append that text output to the string, and you can switch on the KeyType (Special Key Type) to do the append on type None, or handle what you want to do on backspace (trim 1 letter, or w/e) / enter, ect.

I know most of my interactions are in discord now, but wanted to make a note on the thread that 4.26.1 version was updated yesterday to fix a type introduced that prevented packaging against the latest version.

I cant get motion controller attached actors to collide or generate hit events with anything. Do i have to use grip motion controller components then?

Sounds like you just have collision settings wrong, grip controllers don’t change how the controller moves so it wouldn’t help there.

Sorry for the late reply, forum never showed me this post.

For the spawning, if you want to make it super easy on yourself you can have a grippable collision component with grip type set to “EventsOnly” that will only throw the OnGrip and OnGripRelease events and you can use those to trigger your spawn. Gripping the spawned object then can be done normally by calling GripObjectByInterface with the calling grip controller that is passed in with the OnGrip event, the basic gripping section of the website tutorials covers that.

You can also call one of the example pawn functions to grip the object but hand coding this section into the spawner base class may be better for your uses.

Bow and arrow works essentially the same as the vr template. For the rear string you can just have a grippable component there to drive things off of if you want. If you want the bow to orientate with the rear hand (rotate) you can AddSecondaryAttachment when gripping that. You could also just have it be a secondary attachment socket on the bow bone there and drive everything off of OnSecondaryAttachment events, really up to you.

1 Like

Pre-built binaries have been uploaded 4.26.2.

I am unsure if this will be seen as my threads are ended in oct 2020 and appear to have been partially wiped…

Engine Crashes with collision set to “Use Complex As Simple”

I’m seeing engine crashes when using the plugin with collision set like this: the moment the VR player interacts with the SM component, the engine crashes. When collision is set to project default, everything works normally. The crash happens with Grippable Static Mesh Components but in my testing the VRLever and VRSlider seem to be fine.

I’m still on 4.26.1, with the plugin from January so it’s possible this was already fixed.

There is no fix for this, you cannot simulate UseComplexAsSimple meshes or the engine crashes.

The plugin isn’t actually crashing, it is intentionally throwing an assert with the message to fix your collision settings specifically to avoid the engine crashing without a message.

The reason the levers are fine are because they never physically simulate. Generally if you are trying to use complex as simple ever with simulation you are approaching it wrong and should generate some high quality physics assets instead to save perf.

I mention this as I haven’t checked with Chaos and it may allow this, but last time I checked their (chaos) ComplexAsSimple non simulating collision is a direct copy of the vertices and that would be very inefficient when simulating (or period).

Alright, that clears it up… Thanks for the detailed reply!