I am having this exact same issue.
@Proteus have you encountered this as well? Any work around?
Worked like a charm, thank you!
@Diem
Not figured it out yet. I thinking of making the collissions bigger than the wall to work around this problem.
@VRVisuals using this solution doesnt change anything, if the player continue to walk through the wall then he will trigger the endOverlapp event from the other side 
In the documentation regarding making an object “grabable” it says
"Click on Create variable “Mesh Socket” and Create variable “Socket Name”
I do not see where to do this at?
Any ideas?
Thank you
First of all thanks for making this template! Even though i´m a bit of a noob on UE4 i got my project up and running and it´s working well. I am using the prevoius version of the template and want to try the new one in my current project. Can i just copy the new files to the plugin folder and overwrite the old ones? If not, do i have to create an entire new project in UE4?
@Ingemar see note 1 @nhs right click on the variables, create variables, there is 2 of them @Naduct The lightsaber packaging problem is fixed in 1.9.2
@space326 You have to compile the plugin before packaging. see Note 2
Version 1.9.2 – UE4.11.2: May 31, 2016
- Exit moving platform [FIXED
- Teleport Method #2 [FIXED]
- Drop function of conductor baton [FIXED]
- Lightsaber settings lead to failed cooking [FIXED] — attention settings asset has to be wiped from the level/folder if packaging with OFR version to cook succesfully - see Note 3
- No HMD enabled with packaged level [FIXED]
- Teleportation on platform follows the axis of play area
- Scalability settings adjusted
- Translucent materials removed, changed for masked materials
- New settings
- Option to enable Oculus Forward Renderer
- Updated docs
Note 1: To enable the template within an existing project:
The safest way to do this is to migrate the Vive_Map and Vive_Pawn into your project, then eventually delete the assets you don’t need. Also:
• Be sure that the SteamVR Game Mode (SteamVR_GM) and Steam_player_controller have followe if not recreate them.
• Delete references to the proto vehicles in Vive_Pawn construction script and event graph, also (not required) unneeded settings values in settings and Vive_Pawn construction script
• Check in project settings if correct SteamVR settings are setted
• Copy and paste event graph and scalability settings in your actual maps, enable 3 interfaces and nodes in each grabbed objects
• Be sure to have the latest grab plugin in the plugins folder, and enabled
Note 2: To package your project:
Don’t forget to File/New C++ class, None, Create Class before packaging, if not the plugin won’t follow. Be sure to have a working copy of Visual Studio 2015 enabled.
Note 3
**To increase the performances nearly 2x, compile via the Oculus Forward Renderer **(instructions soon)
I’ve uploaded 2 packaged versions for test. The previous built missed the function to enable it, now it’s there.
Also, it seems that this version doesn’t like Struct variables (Settings). It was a problem with 4.10 that was somewhat resolved around 4.11.1, but it seems that this version branched before the changes. So to build with this version you need to delete all references to Settings parameter. When everything is removed, the packaging can do his thing. I’ll investigate further / find a solution for the OFR version. It’s okay with standard 4.11.2
If someone still has a FPS problem after this, free beer on my tab:
1.9.2 with Oculus Forward Renderer
1.9.2 Standard
to follow tomorrow
I want to make a flashlight grabbable but only at the handle just like the pistol in the template. If i just replace the gun static mesh with flashlight it does not work. What more do i need to do? There must be some setting i have to add what part of the object is grabbable i suppose?
@Proteus How do you safely disable the grab plugin without compile errors? I tried removing what appeared to be related but it still wouldn’t compile. Although my project doesn’t need it the option of a simple physics grab would be nice. The ability to use both controls to manipulate objects like the lab is something we should be aiming for.
This may have been fixed already but i noticed with the default teleport you can click a good location on the ground and release in a bad location that shouldn’t be allowed like the air or the side of a wall.
What exactly are you looking for with “the lab” like grabbing? There isn’t much to it in the lab, they are just parenting objects at grip points for the most part. If you mean like the bow then that is a custom interaction with the arrow, the labs actual gripping style is extremely limited and non interactive.
Im talking about free physics style grab where you can pick up an object from any point. In the lab with things like the clipboard you can pick it up and reposition it easily by using both controls to grab and let go as needed. It feels good the way they’ve it.
Nice work though so far. I just don’t need attachment style grab in my project so prefer to disable for now.
The plugin defaults to that style of pickup, I haven’t used the template since ver 5 as I modified it too much but Proteus must have it only using snap points right now.
This is the default behavior for it:
https://.com/watch?v=itIyzvqTiH4
If you don’t pass in a snap point that is how it should work as is.
Hmm that looks exactly like i hoped but unless im doing it wrong or using a slightly older version that’s not how things behave for me. Turning on physics and grabbing a small sphere doesn’t work. I’ll be honest i haven’t experimented with it much as i don’t need to right now.
Though im still wondering how to safely disable plugin if need be?
Well you’d have to get rid of the templates references to the modified grippablecontroller component to decouple it so it would be a re-write of everything to do with gripping. It doesn’t “hurt you” to have it enabled regardless, there isn’t a better solution in engine currently and you could just ignore it and use physics handles if you wanted to, the only plugin downside currently is that when 4.12 comes out I’ll have to modify it to include any relevant code changes to the motion controller component, that being said as it is its own class updates shouldn’t ever actually break the plugin as it doesn’t rely on in flux classes so updates should be seamless.
As far as gripping your sphere, like I said I haven’t kept up on the current state of the template but I think he is using a gripping interface that the object has to inherent now as per my suggestion that you’d have to add to objects you want to be pickable. This way the gripping function knows if the object wants to be a snap to point object or a free grab object (like you want) when attempting to grip it. Without that interface you would have to check objects for the correct subclass and have default static gripping parameters, with the interface you just allow picking up whatever has the interface and the object itself says what it wants to behave like.
@magneto If you look at the hat, it should be that style. Unless you specify a mesh or skeletal socket, you will grab the object anywhere along its collision capsule. As already discussed it I think to have something like 2 hands on the same object you would need physics handle and circumvent the plugin, but you’ll loose all the advantages of the latter. As with the physics it’s difficult to grab objects when physics is enabled at start, even if I put a feature in the object grabbed function to disable physics while grabbed (if not the object whobble, because it’s in constant collision with your hands). I also put a switch in the settings to enable physics at drop (linked to plugin drop function).
@ 12.0 is out as this morning. I can check what I can do to update it but it would probably more efficient if you kindly find few minutes to have a look for 12.0!
@magneto I think its easy to remove the plugin, after wiping all references to it (the 2 grip controllers and grab/drop functions) and replace controllers with the stock MotionControllers. I’ll try it out.
It shouldn’t require updates to work (though it will need a binary recompile to work without a compiler).
I won’t be able to get to it until tomorrow though to rebuild / see if anything is new in the stock controller.
Actually I was wrong, Epic changed how you gain access to the IMotionController so I had to change a section to get it to work. I wrapped it in a version check #define so hopefully the plugin remains backward compatible with 4.11 for now.
The plugin is updated though.
I’m having problems with lag with the chaperone bounds - they seem to move slightly behind the rest of the scene. I have found other people discussing this but no proper solution… Just wondering if this is happening to anyone else with this template?
Just wondering with the release of 4.12 today will this template still be good to use on that engine version?