Thank you for your Light !
Pushed a commit to the master (4.19) branch
Adding Ids to the grip structure, need to expand on their use
it was possible to drop the wrong grip if it is replacing one that had the same
object.
Should also start limiting how fast someone can grip/drop something
Hashing the ID was overkill, incrementing a uint8 now, which should be fine
as I can't see anyone going over 256 concurrent grips per hand (if they do...well they will have
to make it a uint16).
works because the uint8 will wrap around back to 0 when it hits Max_Value + 1
due to the modulo operation that is performed. Apparantly is NOT undefined behavior
for unsigned variables like it is for signed..live and learn.
Also set the drop to pause a grip instead of removing it from the arrya, which rarely caused some
corruption. lets normal replication remove it from the array instead.
Also now searching for other grips with the same object in both arrays, if one is found then it
skips some of the init dropping functions that would screw with the other grip ( shouldn't happen
but who knows...)
Adds new GetGripByID node, is safer than GetGripByObject if you are referencing a grip already.
TL;DR when picking up and dropping items as fast as you could (like…really fast, 1 grip/drop per frame levels of speed), it was remotely possible to get a client to receive a drop and grip notice for the same object at the same time since grips were defined solely by the object they were holding, could result in deleting a fresh grip and the client having an empty grip array and the server having a 1 grip array (server thinks that the replication is done and doesn’t update the client again).
Now it only drops if the Incremental ID matches, and the drop RPC in the template passes that ID in instead of the object as well, also I am no longer forcing a drop client side (early out to stop tick grip happening on it after drop if the array hasn’t repped yet), now I am just pausing the grip since that functionality exists now which lets the server fully auth the grip array
Man why is 60% of everything in template needed for climbing? can you please make different templates that only have the required functions for the specific thing 
for example 1 template for movement with controllers only, no grabbing or nothing, and one template for climbing only, one for grabbing things and so on, like making it more easy to get started. I really want to use your plugin but i cant get started cuss its a mess in the template and unreadable i don’t know what is needed for what or anything, would help so many beginner VR developers to get started with your plugin.
With all due respect, the plugin in general isn’t intended for beginner devs, and upkeeping multiple templates is outside of my time constraints.
The template is typically showing some of the more complicated features and how to implement them, for experienced devs. Very basic stuff is attainable without all of the framework, but I don’t have time to specifically tutorial out each element at time.
You have been complaining about my plugin for months now, months you could have used to either learn enough to use it, or move on and do something yourself instead,
You also seem to be heavily confusing the TEMPLATE with the PLUGIN, which are not the same thing, And climbing in general does not take “60%” of the template to use, it is two functions and some control variables.
i love the plugin but wish there was more tutorials / documentation
Pushed a new commit to the repository (minor)
Split grip IDs between local and remote for clients
Client local grips run 128 - 255
Client remote grips run 0-127
lets me use the same variable but not overlap IDs across client controlled
local grips and server controlled remote grips.
Server doesn't care and uses full scale between them as it is authority
for both local and remote grips for its own pawn.
Grip IDs are local to the motion controller they are being used for, there can be ID overlap across motion controllers
(to keep replication costs down).
Made the button components IsValidOverlap function blueprint overridable so people can allow set objects to toggle buttons
instead of just things attached to / held by the motion controllers. Fixed a bug with button overlap filtering that wasn't
allowing some held grippables through for overlapping.
Added a bSkipOverlapFiltering option to the button component that skips all
filtering and just lets collision channels handle what can toggle the button.
Pushed a new commit to the repository
Fixing Center of mass with scaled root bones and scaled meshes
Also now using the full root bone transform instead of just rotation for correction.
( fixes cases where weirdly scaled / transformed root bones were screwing up physics grips).
Using the actual body instances rotation for the center of mass calc now instead of the
calculated world transform one (in case they differ).
Added cvar to turn on COM visualization for grips
"vr.DrawDebugCenterOfMassForGrips"
Pushed a new commit to the repository
TEMPLATE
Removed the Interactible.Door/Lever/Dial gameplay tags, they aren't needed for the template.
Rather people define their own categories if they use them for that.
Removed UseSeperateTouchSockets from the gameplay tags and from being used in the BP character.
Now that BP controller profiles exist I would rather that they be used instead as they do in a better
manner anyway.
Set the FPS test pawn to the Oculus_Touch controller profile so that objects align correctly.
PLUGIN
Adding log message warning of interactible setting deprecation when trying to grip an object using it
Think 4.20 is the patch that I finally remove capability and force interactibles
and custom grips instead.
Added events that are thrown on the motion controllers for when an object is
gripped and dropped. is useful for feedback like hand attachment and
hiding or specific operations based on what was gripped. (ported back to 4.18 as well)
Renamed DenyGripping interface event to "IsDenyingGrips" for blueprints.
Having the node show up as a callable node was not considered when it was originally added.
The function name remains the same so C++ should require no changes.
Hi ,
While updating my setup to 4.19 for my Vive Pro I noticed that in your latest template version there seems to have an issue with double gripped scaling where the secondary grip location seems to use the primary gripped location or something to that effect. To be sure it’s in the template and not something with my setup, I downloaded the version of the template from today ( bcdec50 ) and checked in there directly by scaling the console actor you have in the level, and it has the same issue as my scalable objects. If you try scaling the console actor there, you’ll see what I mean. It’s somehow scaling towards the primary gripped location currently and not a spot between both grips.
I started listen client without HMD by using -emulatestereo in commandline. causes all connected clients are not working correctly (goes out from character’s body and teleport turned off).
Same behavior if used dedicated server.
Why? Are there ways to fix it?
mmm, just noticed that too, i’ll fix it.
Edit Yeah fixed, it was a bug from changing a bunch of the BP nodes in 4.19 to smooth out some logic, accidentally was passing in a null transform.
The latest version of the 4.19 template has it fixed now.
No idea, that was kind of vauge as to what the issue is, but emulate stereo isn’t that good to begin with, you can emulate a headset in the SteamVR drivers themselves with some config edits.
Thanks for the fix. I think I just found another little bug with “Event Tick Grip” in the interface. That event doesn’t seem to be firing any more. I noticed my VR sliders setup wasn’t behaving the same as it was before so I put a print statement after “Event Tick Grip” and it doesn’t print with the new template. Checked and made sure my tick was enabled etc.
No it fires, if it didn’t then none of the interactibles would work anymore, it requires the Custom grip type or you ticking on AlwaysTickGrip in the motion controller settings.
Hey,
I’ll be using fantastic plugin in very short time for a demo I’m developing…I checked your patreon and notice that the goal for the tutorials was reached, but ( at least on your youtube channel ), there’s nothing, so are those available only for Patreons or are still in standby?
I kinda had my way around all the features, but I notice lately a lot of request for tutorials, so I was wondering if you’re planning some
I only went over one so far (custom grips), lost 90% of my free time over the winter after that.
I’m planning on going back to them again, first up is I wanted to go over the general concept of the interactibles that are in, and a very very basic gripping setup.
Regardless, don’t expect a ton of tutorials from me, its a lot of time investment for something I am not all that good at, I want to keep them mostly to the hardest to grasp concepts.
The Q&A I did ended up being far more useful as it directly answered peoples questions live and I could show examples, I would like to do more of those.
Ah ok, thanks it’s firing and printing now for some gripped components after checking “always send tick grip” on the motion controllers, however it still isn’t firing when gripping my vr slider component… i made sure all my overlap/collision settings etc are the same on the slider component. Is there anything else I need to do to get it to work for specific components like the vrslider?
I perfectly understand that, so for me the important thing is the update of the plugin itself and the bug fixes, so tutorials are not vital, but Q&A is also a nice addition 
It fires for VRSlider, otherwise the slider wouldn’t move, you are likely confusing where to expect the event. It is fired on the gripped object itself, not the containing parent, so if you are expecting to work with it from a slider then you need to subclass the slider itself and use it in there.
If you were to grip the actor itself though, then it would fire in the actor context. I also wouldn’t enable GripTick globally unless you have a very good reason to, it is just additional overhead on most grips. Its fairly useless unless on a custom grip as you can use ticks or timers for normal grips, the only special thing about GripTick is that I fire it off in the controllers ticking time so you don’t have to worry about tick order with it and when the player / controllers move.
Hi , here’s the crash report for the steeringwheel issue. Thanks again for your help, I will support you on patreon end of month.
For other readers, is about an issue I posted about in the comment section on youtube: Weekend project - Car - YouTube
The issue in short: Replace mesh of steeringwheel in Sedan blueprint -> enter play mode -> grab steering wheel (works fine) -> release steering wheel results in hard Engine crash everytime.
A current succesfull workaround is to add a staticmesh component to the steeringwheel inside the blueprint, change the mesh in there and leave the steeringwheel itself alone (apart from making it invisible).