VR Expansion Plugin

[mordentral]

@mordentral

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.

[mordentral]

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.

[dborry]

Hi,

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.

[mordentral]

Hi,

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.

[spaceWumpus]

Hi,
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?

[39lamp]

Hello.

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

[dborry]

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.

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 !

[mordentral]

Hello.

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

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.

[mordentral]

Hi,
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?

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.

[sphinix257]

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

[Bino]

Hi,

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

GripMotionControllerComponent::GripObjectByInterface

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.

GripMotionControllerComponent::AddSecondaryAttachmentPoint

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.

[wontonanimalchin]

Hi,
i just tried it for 4.19. But somehow the plugin is downloaded for 4.18 (https://bitbucket.org/mordentral/vre...gin/downloads/). 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?

[mordentral]

Hi,
i just tried it for 4.19. But somehow the plugin is downloaded for 4.18 (https://bitbucket.org/mordentral/vre...gin/downloads/). 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?

[mordentral]

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

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

[mordentral]

Hi,

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

GripMotionControllerComponent::GripObjectByInterface

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 tend to prefer using direct transforms of sockets now instead of the SocketName parameter, it is more flexible and user controllable (GetSocketTransform - pass in as relative grip transform). It also lets the user directly make use of my new controller profiles system to alter socket grip transforms per controller type. Rather than adding the SocketName parameter to a new location, I would favor removing it from its current locations instead.

The example template never uses the socketname parameter anymore, it only passes in transforms.

GripMotionControllerComponent::AddSecondaryAttachmentPoint

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.

Those secondary cases are for looking for the interface, then it switches to an actor / component grip based on that. If your "actor" wasn't receiving the secondary grip event it was because the "child" grippable is the one being gripped and it was the one that received the event (as it should).

The plugin grips both actors and components, and components have priority so you can separately grip components in a grippable actor. The correct way of receiving your secondary attachment notice in the actor would have been to add an "OnChildSecondaryAttachment" event and fire it off on the owner / parent component as well. However generally two handed interactions are done with actors and you can subclass a grippable component and pass the event up to your custom actor anyway so I don't feel like it is worth the interface bloat to add another event case for this.

Replies in quote above.

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