Its a default character movement mode, you can either SetMovementMode (the node) or go into the CharacterMovementComponent’s settings and change the default land movement mode to flying.
Oh, I see, that’s what needed to be changed. Now I know my problem. I was just using the Pawn that comes with the base UE4 VR template, which doesn’t seem to support that mode. Works fine with a character. Thanks a lot!
I’m testing with the Vive (always testing live with the headset and controllers), on Windows.
The problem is exactly the same with the VrExpPluginExample and my own project - however with my own project I’ve seen that the BP continues past changes that should be visible (door handle moving down) without the changes becoming visible.
Again, at from second Grip onwards everything is fine - unless you teleport, then it’s re-set and the first Grip fails again.
I’ve also made all the settings in “VRGrip Interface” (of the Door BP) equal to other objects that do work correctly. No change.
Any tips where I can look next?
Thankyou. is a little over a month of weekends. There’s alot of features that weren’t active in the demo. The code base conforms to just about any kind of gun real or scifi, but is heavily work in progress. I still have much to add to project.
Run some checks on Grip/Drop and see if it is dropping immediately after gripping, your trigger may be pulsing input.
We need to figure out if it is the input system forcing it to drop again or not.
You can also check IsHeld on the object itself and keep checking it, or HasHeldObjects on the controller.
Edit I had one other guy tell me he had it happen before, but that it wasn’t consistent or re-producable (would happen once then not again) and that it never happened at all in a packaged game.
Default vr template pawn has no movement component at all (ie: no movement).
Pushed 4.20 patch live to Default branch and locked 4.19 to a sub branch. Patch notes for 4.20 below, keep in mind that the majority of engine upgrades work was on the back end as they made significant navigation and character changes (most ported in from Fortnite)
Plugin Changes
Updated openVR property strings
Full removal of the Interactible Settings from the plugin.
BP grippables using them will need to be revised to use sliders or custom grips instead.
Base framework for GripScripts created, not live yet though.
Changed all Expansion classes to use Generated_Body and not Generated_UClass_Body
was past due.
Added VRPlayerStart actor which retains the foot = floor level for spawning and doesn't require Z adjustments.
Added OnGripOutOfRange delegate to the motion controllers.
If event is bound to then the motion controller will no longer auto
drop the grip if it goes out of its drop range and will fire event instead
to let the user control it.
If not bound to, then the normal auto drop logic runs.
event is called on all connections, so if you intend to drop it, you should
filter behind a "HasGripAuthority()" check first.
Fixed several things to allow nativization of the plugin now that an engine bug has been fixed.
Fixed network character smoothing, no longer runs when rotation is happening, should be stable. Still defaulted to off for now.
Ignore NoRep grips replicating down from the server.
is to avoid having to make another list and fixes a bug with them and the server.
Cleaned up swimming movement mode for VR, it should be fully functional
It likely "worked" before, but now it accounts for things it needs too.
Template Changes
Added a filter to "CanBeClimbed" to always ignore grip interfaced objects.
Added a VRPlayerStart to the template level in place of the PlayerStart that
was there before.
Changed drawer actor to use sliders and the new momentum settings
Changed the player controller to wait around for tracking before
spawning. Checks for valid tracked position and if it isn't valid yet it
waits before sending the players HMD info to the server (so server delays itself).
I can now confirm that the issue is caused by a drop fired immediately after the grip. Here it happens consistently - every time and with the editor as well as a packaged game. I’ll play with a counter on the input trigger and come back with some results…
Edit but as said before it happens only with some objects (door / drawers) and not with others (pickup cube, gun, bottle) so I find it hard to see the reason on the side of the Controller side…
Well both of those use manipulation grips while the others aren’t, however the length calculation should be the same.
So I checked what I could find… The “Event On Child Grip Release” in the DoorBP is called immediately after everything connected to “Event On Child Grip” has finished. However, on the PawnCharacter side, no InputAction(Release) is called - so it seems that the Grip Release is spontaneous (or maybe caused by something else, like the controller location being temporarily updated?).
Any clues what to do next?
Edit A new hint! It turns out that Teleporting is somehow triggering the behavior. If I’m starting close enough try the door without having to teleport, there is no issue. If I use any of the other movement modes, there is also no issue! Even with the “Navigation” mode and “Out of body Navigation” there is no issue. So whatever value is out of place, Teleporting sets it, while the others don’t.
Edit The cause is somewhere in the function “Perform Move Action Teleport”. As soon as I take that function out of the BP, the problem disappears.
Change the break distance to be really large on the door and see if it still does it.
It sounds like it is auto dropping the object, you didn’t change world to meters scaling or pawn scaling or the door scaling did you?
Something has to be off about your setup, because it does it for no-one else. If it is a distance issue I can solve it, but I need to know what is causing it.
Edit NVM I found a re-production, i’ll look into fixing it, its the Justteleport flag not getting cleared if your hands are empty, manip grips by default drop on teleport.
I guess not many of us use teleportation 
or if we do, we don’t use manip grips right after, i’ll have the fix up after my 4.20 at home finishes compiling shaders and will port it back to 4.19
Re-edit Fix is live on 4.19 and 4.20, thanks for reporting, and thanks for mentioning teleporting, it brought me to the fix
Thankyou. is a little over a month of weekends. There’s alot of features that weren’t active in the demo. The code base conforms to just about any kind of gun real or scifi, but is heavily work in progress. I still have much to add to project.
And yes. The cube is alot of fun but it has alot off issues and causes alot of lag.
Also now that 4.20 is live i plan to port over and set roots in it. Are there any magor changes or game breakers i need to look out for. Im still deaply imbeaded in the 4.19 template character. something i need to work away from still.
4.20.0 is in a far better state that 4.19.0 was IMO. Usually I say to wait till .1 or so but its been stable for me since preview 3.
how should i go about updating my project with the plugin. ive never been through the process.
Delete entire plugin folder and replace it with the new one, then switch project to 4.20 by right clicking on the .uproject and compile.
You need to upgrade to visual studio 2017 in 4.20, they removed 2015 support.
i am using 2017 and getting the same problem. im really not sure whats wrong.
YES! That made my day. Thanks so much for your help!
Note: I upgraded to 4.20 now and also had issues compiling as mentioned above (access issues with the build.bat file). My solution was to simply take the VrExpPluginExample, run that one, then copy the contents of the Plugin folder to my project. Not a very clean solution, but it worked for me (so far ;)).
Hey,
is there the possibility to define a custom gripping region? I dont want my pawn to be able to grip anywhere where the mash has a collision, but only at one end.
How could I do that?
Thanks!