Hello ,
I have just checked my project and everything is set 0,0,0.
There is nothing in the event graph it is a Vanilla SimpleVRPawn Class with meshes attached to the montion controllers. And im still experiencing the same problem. Please Help
Sorry Guys! I got to work. I had the blueprint set to Controller. DOH!!
Could you do me a big favor and edit your posts to remove the images as they didn’t end up having problems in them? Will remove some of the clutter.
Hi all, i see shadow of the capsule root item only my right eye sometimes. Especially when i bring a PickupCube(or sm else) closely for my face(HDMI). shadow replaces a cube shadow. How i can fix ?
Nice job!
Does it include a climbing system?
It will have a climbing example, soonish. I’ve been trying to figure out the cleanest way to handle it in multiplayer where d’sync won’t happen. Single player you just add an actor offset of the hand motion, multiplayer you need to replicate it alongside the character movement so that the server and client get the same motion updates.
I have it working with a couple of different methods but neither have quite hit where I want yet.
Edit for that matter it seems to be almost where i want it to be now, I can probably clamp down on my perfectionism and release it in some sort weekend.
New commit for the template and the plugin, in 4.15 alpha branches.
Adds in direct replicated movement functions and a basic climbing movement system for the std character (still need to port over to the simple character).
Good stuff man.
I’m a bit of a noob but defintely loving plugin. Trying to figure out how to use VR Character and get it in the level. I duplicated the SteamVR motion controller pawn and changed the Parent Class to the VRCharacter Pawn (Not sure if is how you set it up?). I had to change the Auto Posses Player to Player 0, because it wouldn’t use the VR Pawn/camera as the start point, but now my hands in VR are offset a bit and I’m not sure how to fix it.
@mordetral Impressive work so far 
You can literally just open it up in the template and right click -> migrate to another project. That being said I like to warn people that its generally best to remake it to suite your gameplay plans and use functions from the template as a reference for how to do some things, its not exactly set up for a full scale project due to wanting it to be as generic as possible.
Hey ,
Great plugin! Is it compaitble with Oculus CV1? Asking because you’ve mentioned OpenVR in the title. Thanks!
It has a few OpenVR specific functions but they now compile out in incompatible platforms. It should work for any VR build that Epic allows currently, also for the record CV1 still works with OpenVR anyway ;p
Edit that being said I didn’t upgrade my dk2 to a CV1 (went vive instead) so if you DO run into issues let me know so I can fix them.
Pushed a new commit to the plugin and the template (includes yesterdays ones)
Template Change Log
**01/30/2017**
(Template is now under 4.15 due to incoming version lock because of engine changes, these changes are up on the current 4.15 alpha branch)
Updated to latest plugin version
Added a basic climbing system to the template (as a movement mode) (currently only on the STD VR Character, simple will get it added soon)
Added a fallback overlap detection to the grip trace to cover when the trace fails because of initial interpenetration.
keeps the traces better detection of fast moving objects but covers its weakness when interpenetrating.
requires that objects have "OverlapEvents" ticked on in collision properties for the fallback to work (otherwise is just the trace).
Plugin Change Log
**01/30/2017**
Added AddCustomReplicatedMovement node to the character movement components, adds a vector that will be processed during the next CharacterMovementComponent tick and apply as an actor offset (swept movement) and is replicated with the movement sub steps. I had as a velocity injection but that ended up unsuitable for climbing due to rubberbanding, I may extend in the future due to swept movement not handling floor detection on its own.
Fixed a name conflict that was caused while implementing the above
Fixed a random bug that I can't remember anymore......long weekend.
Edit Btw the fallback was added because I was flinging myself around with the climbing system and kept having my hand fly through walls and not grip, plunging me to my death 
Yeah, you can use a physics constraint on the mesh and constrain the meshes to the controller component. I don’t know how much you want to do that considering the “wrist breaking” effect, I would normally suggest just denying gripping while interpenetrating. (you would also want to add the controllers to the additional late updates array that I added to the controllers so that they wouldn’t lag behind when moving fast).
You could also “grip” the meshes using the controllers and skip the first grip during operations, one of the grip types (Interaction Physics with sweep) would just stop on the wall when trying to go through and wouldn’t have all of the physics jittering and flattening to the wall that you would get otherwise.
Thanks so much! I don’t know why I didn’t think of doing before. One more thing, when I add a vr pawn to my map and click to preview in VR, it doesn’t use that pawn as the starting point and instead puts me wherever I am in the preview window. I checked my game mode and it is set to use that vr pawn by default in both world and project settings.
When I change it to posses player 0 under the pawn settings, it seems like it fixes it but it also seems like its offset for some reason. Am I approaching adding a VR pawn the wrong way? I’ve followed numerous tutorials on how to do , but none of them really explain on starting you off where the pawn is placed.
You may have already fixed these, but a few bugs I found the other day
4.14 version
-I noticed that the gun collides with something as you try to walk through an open doorway.
-you can walk through the door if it is open, even if your hand isn’t effecting it (I haven’t looked at how you did the door but I assume it is supposed to be physics driven right?)
-The drawer labeled as physics doesn’t seem to conserve momentum when you let go (maybe is on purpose?).
I’ll try the 4.15 version here in a bit!
edit: I tried out the 4.15 version and the climbing is excellent! Do you have plans on handling the “Getting up on top of things” part of climbing? With a teleportation mechanic solves itself, but with traditional controls you will need some sort of button press or combination movement? I have been able to get up on things sometimes by using both hands and slinging myself into the air. I wouldn’t recommend anyone that is susceptible to motion sickness try that though.
Getting on top of things is generally easier with proper level layout, if I had the direct movement not using sweeping then it would naturally find the floor with the movement components tick but I was noticing rubber banding then due to kickback with interpenetration. I am likely going to go over it more in the next few days now that it “works” in multiplayer and refine things.
Yeah the door frame doesn’t have proper collision, it is one large simple collision box and blocks simulating objects, I never bothered to fix that.
The drawer is set to un-simulate on release, if you remove that from the OnRelease event it will retain momentum, Its all up to preference really.
The door itself turns on player collision when it stops simulating, I don’t have it on during simulation just to avoid annoying banging, that is also something that is easy to adjust to your liking.
I wouldn’t leave one in the level, I would spawn one where you want it and possess() it.
Cool, yeah I already tweaked things and it works great. Does the door frame need the simple collision or can I use multiple boxes for it. Just curious if it is somehow involved with stopping the door.