VR Expansion Plugin

Ok, how long is the file path you have the project at? it can fail to generate files if the file path is too long.

Otherwise you might want to try with a clean build again or by deleting the saved folders since you changed some things.

I put my comp on building a fresh copy from the template download just in case this morning and it loaded fine.


Wow, that was it! I tried around for hours, even changed to a pc with different admin rights, but it seems as if my path was always too long. I didn’t suspect this at all since I’m only a few folders deep, but it works if I try the same steps directly in the D: folder.

Thank you so much for your help! I’ll try to play around in the scene now.

Its one of the hold overs of the OS that people keep running in to, the warnings it generates are really obtuse, think you are the 5th person where that was the problem.

Pushed another commit to the plugin

 Fixing another bug introduced with the new rotation correction system   
 (this was kind of unrelated, forgot to replicate a value with teleport). 

Thanks for the stability testing reports, it is easy to oversee a few things when making a change this big. Hopefully that fixes the major missed items.


Sorry if my problem will seem obvious, I just started to use the template and I have a lot of things to discover.
So I created a C++ project with the plugin and I imported the assets from the template example level. Everything works fine
for the movements, teleportation etc…

But I can’t grip anything. I just tried to test it with a BP_PickupCube instance and it doesn’t work at all. When I dug into the blueprint
code itself, I found that in the function GetNearestOverlappingObject called when trying to grip something, the nearest object found is
always… the Vive pawn itself! I really don’t understand why, especially because when I directly test the example project it works perfectly.

You didn’t move over the VRTrace tracing channel, I use a seperate trace channel so I can deny things from even being hit when checking for grips.

You can change the channel in the BPs and set the actor to ignore it, or you can import the channel from the template.

Also you might have forgot to migrate the gameplay tags.

You can hit yourself btw because if I ignored the actor entirely it would also ignore attached components that you may want to grab.

Thanks for a great plugin - certainly puts the default VR template to shame!

I’ve been fiddling with the teleport system to ignore the nav-mesh, and to instead consider any static mesh surface with less than a given inclination to be a valid target.
This means that you will often not have a valid target (unlike the original system which pretty much only had no target if you aimed off the edge of the world).
This is fine - I’ve tweaked things so that the beam arc is still shown whether the target is valid or not (but the destination cylinder isn’t), so you can see where you are hitting.
All pretty simple stuff, and so far so good.

However, when the target isn’t valid, I’d like to display the beam in a different color.
Should be simple, surely…
I see that M_SplineArcMat is the material applied to the arc, but I’m still in the early days of Unreal, and I can’t figure out where this is actually applied.
The arc mesh appears to be made of BeamMesh instances (which has a default material applied).
If I select M_SplineArcMat in Content Browser, then right-click ‘Reference Viewer’, it says that it is used by BP_Teleport_Controller, but I cannot find where it uses it.
I must be missing something really simple, but I’ve been searching for ages and just cannot find it.

Can anyone give me a nudge in the right direction, please?


How can I hide vive controllers, and replace them with Mannequin Hands?

Well, the gameplay tags were the problem. I didn’t forget to import them but I did it after the blueprints, so they could not be set up. I specified them
in the pawn blueprint and now it works perfectly. My bad !

There is a section of the character showing the model loading code, you can delete it and the manniquin hands should already be there.

When Epic finishes bug fixing their model loading I’ll be deprecating all of that anyway.

It is spawning spline mesh components to follow the curvature of the spline, you’ll have to set the material (or a material property) for them.

ok so i have a strange bug. i had had a project… have issues. so i rebuilt it from a fresh template and migrated custom content over.
im not sure that that has anything to do with it. and ill explain why, but im not sure what the problem could be.

from this point forward every gun i spawn in a world. original code or my edited code. doesnt matter. when i pick it up it points strait down. previously placed guns work fine. even the migrated ones that are custom. but newly placed does not.

have you ever seen this, and do you know how to fix it


Big fan of this plugin. I’m mainly integrating it via C++ and found I needed the following changes.

I think my approach has maintained the patterns you have. But correct me if I’m wrong :slight_smile:


When this function eventually calls GripComponent it passes NAME_None as the socket name. I needed to add an optional socket name parameter to this function and pass it. Now grips at the socket location.


I create a BP that inherits a grippable static mesh. The secondary grip event wasn’t being fired. In other functions you test for the interface on the component and if that fails you try on the Owner. I added that same pattern here. Now works.

i just tried it for 4.19. But somehow the plugin is downloaded for 4.18 ( And when i open my 4.19 project, the plugin shows 4.18 indeed. And i am not able to get the whole map in the project. It just opends as a blank project. I can remember that the first time i did this, that your whole example project opened. Do i make a mistake?

4.18 there was me forgetting to update the plugin information file, it is ignorable as the actual template is on 4.19

As for a blank project, are you sure you opened the correct one / the correct map?

No I have never seen it, I would expect it to be a socket offset but can’t really tell remotely.

Replies in quote above.

Suggestions and ideas are always welcome, no matter my response above, thanks for suggesting!

it was socket. it was rotated 70 degrees down. strang. it looked like it before. but i may could have messed it up. even though i really dont know why i would have touched that setting or why it only struck new instances with that issue.

thankyou. its fixed now

thanks man. It works fine right now. Started just new project with your template. Few months of fun, thank you!

Pushed a new commit to the plugin

Took a pass over the capsule height replication, had to fix it for simulated clients Also wanted to clean it up and its use.

Moved the VRReplicateCapsuleHeight boolean to the character instead of the movement component as it makes more sense there.

Use SetCharacterHalfHeightVR() node to properly set capsule height for replication.

If you only need two states, crouch and standing, its better to still use the Crouch commands as they are more efficient