VR Expansion Plugin

Development Platform & Builds XR Development
1415

First of all, thank you for the plugin. I’m currently testing out the plugin and, if I end up using it in my game, I will for sure send you some money.

My question is about the use of the LeverActor. When I add the LeverActor to my level and use it at the default angle, which is to have the base on the bottom and the lever point upwards, everything works fine. When I rotate the lever 90 degrees, so that the base could be mounted on a wall with the lever sticking out away from the wall, I am no longer able to move the lever. I’m suspecting that there are some calculations somewhere that are not taking into account the relative position of the lever, as if it’s always assuming the lever is in the default orientation of base on the bottom.

Where should I look, how can I modify the actor so that it would work when mounted on a wall, or any other orientation?

1416

I wouldn’t bother with that lever yet, while I had made it work correctly with rotations the c++ version is nearly done and is better in just about every aspect (the template lever isn’t actually part of the plugin, just example content).

The blueprint lever actor was a basic example of functionality, the new c++ lever (component) is fully featured and is not an actor so it can be used at will (like the c++ button component).

It should be added early next week after I run some quality passes over it (its functional but not perfect yet).

1417

Understood. Thanks for the reply.

1418

Pushed a new commit to the plugin master branch and sync’d it to the 4.17 branch


Replaced some overzealous uses of FORCEINLINE with inline instead. One instance in particular was causing some massive stalling when
UBT was compiling the precompiled headers for some reason. 

Thanks to: Makoto Nokata
For taking the time to run down what was causing UBT to stall during initial precompiled headers compilation in engine.
 commit should significantly speed up initial compilation.


VRLeverComponent is now fully functional, still would like to clean up angle calculation
some and reduce overhead on it but it is useable in its current state so i'm pushing it live.
Further optimizations and features will be added over time to it now.

( component took longer than expected due to REALLY wanting perfection for the most part).
1419

Is there a way to make the player pawn collide with the root component of an object if they are gripping a grippableStaticMesh component of the same object?

For example - the desk in the example project by default has custom collision which has pawn set to Ignore. If I set the pawn checkbox to block, the player can no longer walk through the desk - but they still can if they are holding onto a drawer. Is there some other setting i’m missing?

1420

Its because of


OwningPawn->MoveIgnoreActorAdd(root->GetOwner());

On grip currently by default the gripped object is auto ignored for movement. is to prevent the character from colliding with objects he is holding and moving around since they aren’t attached to him (ie: the fling yourself into the air syndrome).
It also turns off collision with just the held component but obviously if others are attached to it in the actor they could still collide with the character without that line.

I can add a toggle for it to the advanced physics settings? 99% of the time its best as is. You found one of the few times it isn’t.

Edit I am loathe to reverse default behavior because of how many setups it could break and I really do think that turning capsule collision off to the actor on grip is what people would want most of the time.
So I just added a boolean for it to the AdvancedPhysicsSettings and enabled it by default to the doors and drawers in the level.

1421

Pushed a new commit today, the above MoveIngore change was added in as I was pushing changes anyway


Added calling controller capability to the GetClosestSocketInRange interface functions.
Can be used in overridden versions to check the hand / other info about what/who is checking
for a socket in range. **- Will require c++ changes in anything that manually implements the interface**

Defaults to a nullptr, but a motion controller can be passed in and used on the implementation side.

Template will have it filled in.


Made bHadRelativeMovement publically readable in blueprints
While misnamed, is true if we collided with a wall/obstacle due to the HMDs movement in  frame (not movement components)


Removed MotionControllerLocDelta from TickGrip
Not only can you manually calc it (and probably should) with custom grips.
But being in worldspace the offset could be wrong due to character movement.

Better to let items calc it themselves and store the variables for more advanced use instead.
I don't think it had much use in its current state.


Now I am only calling move ignore actor if the held
object is an entire actor. If the grip is on a component only it does not perform
it for the entire actor, just for the held component.

If for whatever reason someone needs an entire actor to be uncollidable with a component
grip they can do it themselves.

Added somewhat working dial component - needs full testing
1422

You know what, I had a better idea regarding that move ignore setup. I’ll be reverting the new boolean tonight and just setting it only on actor grips instead. That makes a lot more sense and should work as is.

Edit Changed today’s commit as per below


Removed DoNotMoveIgnoreEntireHeldActor

I had a better solution come up. Now I am only calling move ignore actor if the held
object is an entire actor. If the grip is on a component only it does not perform
it for the entire actor, just for the held component.

If for whatever reason someone needs an entire actor to be uncollidable with a component
grip they can do it themselves.
1423

I did a quick search and didn’t see it mentioned anywhere, but how would one go about combining with the “weapon master VR” kit from the market place. I want all the movement from you plugin with all the gun mechanics from his. Also I heard that combining them was in the works already. Any news?

1424

Lots of manual work, I know of “two?” people combining them already in my support discord. It doesn’t work right out of the gate because the version that they (weaponmaster devs) use for themselves using my plugin isn’t the marketplace version. Also they don’t have any multiplayer support so if you want that then it will take a decent amount of re-factoring to get working correctly.

That being said if you don’t care about physics based grips or the replication/multiplayer you can just literally use the weapon pack with the movement parts of the plugin and ignore all of the interaction stuff that the plugin provides. Its not mandatory to use the GripMotionControllers special features, or even use a hybrid where it uses their stuff for guns and the grip controllers for other things.

Honestly I really wish that some of the gun pack devs would just start making generic interfaces for their systems so that they could tie into anyone’s interaction systems. Out of the three (or four) weapon systems on the marketplace / available none of them provide generic interfaces to tie into systems people already use, instead they all rely on straight coding in the interactions themselves, I feel like is a major mistake that they are all making as if it was done correctly someone could make a pack that could tie in with any project already in the works.

1425

You are awesome! Thanks!

1426

I was one of two that did the conversion (I think Im the only one that completed it so far). It takes a bit of work because the toolkit has some functionality pushed through the pawn to weapon, and some from controller to weapon. When it was all said and done the toolkit ended up just being a reference point for setting up gun modularity but the interactions need to all be re-done from scratch, new inputs, and you gotta add that new collision channel. The way interaction is done is just so different, but it ended up much cleaner after the conversion. I also went with trace shooting instead of actual projectiles because I want it multiplayer.

1427

what I’m working with right now is sort of like nazi zombies meets left for dead and dead rising. So i do need multiplayer and replication, i need the guns to work, and I want the locomotion from the plugin. Trace shooting seems fine for me too.

So how would you recommend I do ? I’d be willing to throw some money down on getting a bare bones copy of what you have.

1428

Just rebuild the guns using the example gun in the plugin, and write the logic from the toolkit in there. Just need to do it once because all other guns are just child actors you can change settings on like in the toolkit.

1429

Pushed a new commit to the plugin repository tonight.

Thanks to SlimeQ for being annoyed enough to report it and make me look into it, sometimes that is just the motivation I need.



New UpdateOverlaps override, should correct multiple issues / problems with how
overlaps have been working with the VRCharacter Capsule.

Some things like overlap spam on character capsule and overlap offset have been around for a long time but were mostly forgotten about.

Thanks to SlimeQ for bringing them up again so I remembered to look into it.
1430

works like a charms, ty so much!

just another little minor unuseful issue :D: any way to get rid of these warnings?

UnrealBuildTool: Warning: Plugin ‘OpenVRExpansionPlugin’ does not list plugin ‘SteamVR’ as a dependency, but module ‘OpenVRExpansionPlugin’ depends on ‘SteamVRController’.
(same problem for advanced session)

I think plugins are supposed to add explicit dependencies in 4.17…

1431

Are you trying to use the 4.16 branch in 4.17?

Because I did that day 1 in the 4.17 migration.


	"Plugins": 
		{
			"Name": "VRExpansionPlugin",
			"Enabled": true
		},
		{
			"Name": "SteamVR",
			"Enabled": true
		},
		{
			"Name": "ProceduralMeshComponent",
			"Enabled": true
		}
	]

If you are using 4.16 for 4.17 I don’t think the project should even compile though, I had to change multiple things.

1432

Oh yeah i forgot there’s an example gun in there. Thanks man, that actually shouldn’t take long at all…

1433

wouldn’t it just be easier to modify the vr pawn to be able to pick up the already made guns?

1434
  • might be due to having an old version or something, but when I play in VR, I get what I think are supposed to be the basestation bounds and something to do with the controllers, but they only appear in one eye or in different places for each eye (black box and squished black sphere). Sorry for the rubbish screenshot:

1307×767 173 KB

I meant to mention it earlier but have been doing testing mostly on monitor.