For some reason the plugin is completely ignoring what settings I use for a Grippable static Mesh actor in the VRGrip Interface settings. I set the Grip types to whatever and once I grip the actor with GripObjectByInterface or GripActor and read the SlotGripType its always setting it to Sweep with Physics… Any idea why might be happening?
Nope, shouldn’t happen at all unless you are passing in the wrong thing, are you sure you aren’t passing in the component and not the actor?
Climbing seems pretty much done. Great work. Is there anything else you are planning on adding to the plugin? Other than really game specific stuff I can’t think of anything “general” you haven’t covered. Maybe Flying or webslinging (grapplehook)? Those might be too game specific though.
Where do you plan on going from here?
The default flying movement works fine so I don’t really need to touch it. Webslinging / grapple would be fun, and would actually use the climbing movement mode I think so its something to consider.
I think I was going to tackle armswing and running in place motion next, I don’t really like either of them but they are quick to implement and I know that many do like them (again though, they are a purely blueprint implementation, not really a plugin addition).
Other than that i’m starting to run out of things to add 
Most of the things left are just gameplay concepts, not really related to the plugin itself.
Pushed a commit to the template and plugin for the 4.15 alpha branch ( will break projects but is a simple fix)
Made base characters and base movement components hold more of the logic for the VR characters
change allows blueprint characters to be abstract between VRChar and SimpleVRChar and switch between the two (so that I don't have to duplicate nodes and code
between the two base classes).
It also causes less code duplication and clarifies class roles more.
change moves the VRForwardVector / Right / Location functions into the character itself for the VRCharacter, like the simple character already had it.
lets me develop features entirely using the VRCharacter, and simple duplicating it and reparenting to the simple character everything should work, it was too tiresome to duplicate code changes between the two manually. It also makes more overall sense and makes it easier for people to change between them if they decide to.
Projects using the VRCharacter will need to pull VR forward/right/up/location vectors from the character itself now instead of the root component. Everything else should just work
Hi,
just a quick question as i´m working on something right now using your great plugin.
How can i “deny-gripping” one mesh when another mesh (wich is a child from the first one) is moving in my scene ?
Thanxx alot =)
If the actor is a grippable actor then set bDenyGripping to true in the interface properties. If it isn’t but still uses the interface just return a boolean from the denygripping function. Either way you can set it dynamically.
Pushed another patch to both the template and the plugin, left some control booleans true for the VRCharacter that are intended just for the simplecharacter. Sorry to anyone that got instantly sick from the broken neck effect.
Its definitely the Actor.
I have an Actor thats a child Blueprint of the Grippable Static Mesh Actor, lets call it “Item” for now. Before grabbing it I cast it to a Grippable Static mesh Actor, then I use the GrabActor function(or whatever it’s called, sorry on my tablet atm) with it as the target and use the Interface Function to get the Grip type information and the Grippable Static Mesh Actor I got from casting my Item.
No clue why it’s happening.
Hmm, do me a favor and don’t cast it and pass it in, let me know if it works. Sounds like the cast is re-initializing the vrinterface struct somehow.
Played around with a server browser to test multiplayer with in the template will upload to the 4.15 alpha template tonight, it WILL be buggy due to rushing through implementing it.
is an un-edited template, just with a server browser to load into servers with. Most of the objects aren’t currently set to replicate movement so they will be un-sync’d with the server to the client (including the moving climbing wall). But it can be polished from here.
was about an hours worth of work (only spent on the server browser really) don’t take it as an indication of what it will be like eventually as most objects need to be edited to allow for multiplayer.
Very nice.
Is why when I start VR Preview, my pawn is tilted sideways until I teleport and then it straightens up.
It seems like if I am angled down looking at something in the viewport and then I enter VR Preview, my pawn and chaperone boundaries come in angled (Broken Neck?) as well until I teleport and then it straightens out.
No, that wouldn’t be why, and I have never seen that before. I assume that you are spawning the character from a spawn point and that it has a rotation correct? I think you are applying an actor rotation to the character which you shouldn’t do, teleport with 0 rotation would fix the rotation problem.
Thanxx, will try it out =)
Yes please to the above. I suspect I’m not the only one who’d like to see you cast your wizardry in area!
Your work is amazingly good. Thank you muchly.
Another question,
can someone please explain how to get the hand-animation back ?
I need it urgently and cant figure out how, my try to copy the blueprint functions from the original ue-vr-template does not work at all and i´m afraid to screw up everything in my project =/
A step by step or a vid would be awesome !!
Thanxx
Andy
The repository doesn’t include climbing yet. Am i missing something? also great work man is a life saver!!
Its 4.15 Alpha branch only currently, due to the engine header change in 4.15 I split the plugin again (like I had to for 4.12-4.13 due to massive navigation system changes).
I didn’t want to keep engine #define checks around for the life of the plugin compiling different code just for 4.14. normally isn’t required, there have just been two major engine base overhauls recently that screwed with version compatibility.
When 4.15 officially releases I am going to merge that alpha branch into the master one. People wanting the climbing system in 4.14 going forward could manually pull in the commits related to it if they wanted to.
You can get seperate downloads for each branch at the following locations
Plugin
https://bitbucket.org//vrexpansionplugin/downloads?tab=branches
Template
https://bitbucket.org//vrexppluginexample/downloads?tab=branches
You likely need to re-implement overlap detection, I use spheres on the hand, I think the template uses the hands themselves (don’t remember)? It shouldn’t be too hard to transfer over though.
Pushed a new commit to the plugin and the template for 4.15 alpha branches
Some of these things still need some additional testing, may roll out another commit tonight after I can fully run through them.
Fixed Important bug in DropGrip with the optional velocity variables and their order of use
Added naive Lerped smoothing to motion controller replication, bSmoothReplicatedMotion controls it,
should not be used if the expected FPS frame time is smaller or equal to the motion controllers update rate.
Added bReplicateWithoutTracking to use for FPS or testing characters to allow replicating custom controller movements.
Added climbing movement toggle directly into Movement Component, now is injected into FSavedMove and replicated with stored movements
should remove any hitching when moving between climbing or non climbing movement modes as a client.
Removed FBPReplicatedTransform's use of a packed BYTE for replicating controller ROLL, was not accurate enough. Now uses a packed SHORT just like the other two axis's
Added an Unpack() function to FBPReplicatedTransform, used to pre-unpack location / rotation so the new lerp is less CPU costly
(at the cost of a FVector / FRotator extra per motion controller in memory).
Edit Tested, appears to be working fine, I did switch all enums over to the new style in a seperate patch though.