We’re using only core functionalities of your plugin and that would be a lot of rework with no pros at all
If you u plan to upgrade it, pls keep current interface alive
As in you don’t use the Onused events? Or as in you don’t need the extra options the re-work would provide?
Because if I did “upgrade it” I can’t keep the current interface as is, it would be besides the point.
If you don’t use the OnUsed events, and you don’t have c++ classes implementing the interface, then it would be no work at all.
we definitely use “on used/end used/etc” events and we don’t need extra function that new interface would provide
our opinion btw 
I’m in-between projects which gives me the luxury of a little time. I fully support making all 4 of the proposed changes.
No pain, no gain.
I’m trying to create my own grippable actor and I’m having trouble with the socket snapping. Everything else works and I can’t seem to figure out where and how to apply the socket information. I read the wiki and I don’t understand where the grip function happens. With context sensitive on the grip function doesn’t appear for any of the components I try to add it to. Did I miss an example in the project? Can anybody point me in the right direction?
Quote Originally Posted by Link_AJ View Post
How do I add the VRExpansionFunctionLibrary to a Pawn? Isn’t it supposed to be a component? I can’t access the functions.
Its been a while since I used plugin. I just updated it to 4.17 and the ability to add OpenVRExpansionFunctionLibrary to a pawn is gone. How do you do it now?
Just add a socket to the mesh, the static meshes now can have sockets as well since like 4.9 or something. Then you name the socket either VRGripP1 or VRGripS1 (Primary grip #1 / Secondary Grip #1) and it will use that location.
You can check out the gun in the example template, the mesh for it has several sockets in it.
The names are prefixes so it knows if the socket is for primary grips or secondary, the number afterwards is just so that they have different names.
Nope! Since 4.16 Epic finally updated to a newer Steam version on the backend, means that I no longer have to manually load and call .DLL functions for that utility library.
All nodes are now static and can be used from anywhere without a component.
I suspected that and set up my static mesh with a socket named exactly what was used on the gun example. I created a socket using VRGripP1 but it doesn’t snap. Just to be clear, I’m not using any of your grippable components. I only created an actor blueprint , static mesh component and added the Vr Grip Interface. I’m not sure what I’m missing here.
You will need to fill in the “GetClosestSocketInRange” function in the interface then, there is a default helper node that you can just connect to it.
The reason it is overridable and in the interface and not just searching, is for hot swapping locations or “snap when active, free grip when not” kind of things.
So far input in here and in the support discord has been varied enough that I will be re-shelving thoughts of re-factoring the suggested areas.
Going to make a video going over the interactibles tomorrow, intended to do it today but life got in the way.
Cool, I look forward to it!
You rock, I love plug-in!
Little go over video of the two new interactible components and something special using them and 4.17.
As the Weapon Master VR Dev, I would like to comment on ; the reason I did things the way I did is 1.) I am not yet comfortable with interfaces coming from an inheritance background and 2.) I didn’t want to “Copy” anyone’s logic and get in trouble (really worried about all the time). I assume for me to do what you wish I would have to make all of the events that pass on to the weapons generic and in identical to yours? What about variables passed through that you don’t current pass with your grip logic? I am actually looking at changing to interfaces when we do our multiplayer update (version 2.0) later year. When we get around to that would you be willing to help test the integration? I may even look into it for version 1.2 (1.1 is too close to being finished and released to go back to the drawing board).
I have mentioned in our thread that the best (current) way to combine Weapon Master and plugin is to uses plugins locomotion and our grab/weapon logic. I would like to make it clear that we have NOT integrated The OpenVR Expansion Plugin into our internal Weapon Master builds yet. Its something I really want to do but with about 20 features currently on the list of things to add, I simply haven’t had time.
Thats said our actual game will be an amalgamation of WMVR and OVREP. Your locomotion is just far superior to ours due to the hoops we had to go through just to implement the stuff we wanted through blueprint (Yay c++).
I think my biggest worry is to “step on your toes” in some way but if peeps really want it I am willing to make big changes to what we have to make it better. Including your idea for generic interfaces.
No, nothing needs to be identical to another system in order to be generic enough to be used by it, that wasn’t my point. My plugin isn’t the only interaction system out there that isn’t easily compatible with the gun (and other) packs out there.
All of the clip / damage / aiming logic can literally be the same, the issue is when the actual interaction is hard coded into things it isn’t flexible enough to quickly switch out. There should be fallbacks from the hard coded systems or direct methods to tie in without large re-writes.
IE: Giving clips a bindable event they fire off when ready to “dock” instead of actually performing it themselves or using any particular system, giving any system the ability to drop or correctly use the right logic on that occurrence. Its not specific to your pack either, I wasn’t trying to insult you.
Right now most of the VR stuff is “use it as is or recode it” and that limits a lot of potential for interchangeability (like using one melee system with another gun system with a custom interaction system that was in the project already).
Edit Missed the testing integration stuff and “Step on toes”
There is no stepping on toes here regarding my work, its open source and MIT and I don’t sell the plugin itself. Also I am more than willing to assist people in correctly using it when they have need 
Pushed a new commit to the plugin and example template.
Plugin
Fixed a bug with HasGripAuthority where the server was being assigned as grip authority
for the Client_Auth grip on its end.
Added a 1 frame delay flag after teleport where grips won't check the constraint for
if it is outside of the auto drop distance. is to allow for the constraints localpose to
held object to be recalculated. Otherwise it could rarely drop the held object on teleport with
small auto drop lengths.
I could manually set the constraints local pose instead, but would rather have the delay anyway.
Template
Added preliminary examples of Mixed reality support to the new video camera testing actor.
Edit I generally leave locked branches alone, but 4.16 was recent enough and the HasGripAuthority is important enough that I merged that commit back into it.
Hi, sure is for noob practice. But latest template doesn’t run for me with 4.17.1.
At the beggining says not compatible, and after rebuild crash the editor in launch time
You’ll need to re-build it, 4.17.1 is treated as an entirely different version.
Opened without issue at second try. Had been rebuilted, but crash it at first opening time. Thanks.
Did some new testing with the camera actor, using the good groundwork of the nice community members over in the mixed reality thread.
