“Secondary Attachments” are a modifier to a grip, they add a reference point that the grip attempts to also keep oriented towards, they are not a full grip in themselves. You can use tick on the bow or the character, or a timer, to update the hand meshes relative position on the string as I assume that is what that tutorial is doing.
Or you can snap to a bone socket on the string and it will auto follow that.
The only grip mode that specifically has its own tick is “Custom_Grip” as that throws one after the controller moves so that you don’t have to play around with trying to sync timing.
You can SetLeverAngle on the deadbolt on begin play based on the doors current locked state so it will auto setup the lock setup, it should handle itself then.
For a container you can either use a lever as the top and hinge it at the back, or use a physics constraint and just handle it physically by having the lid be a grippable component and using a manipulation grip type.
has been an amazing experience learning throughout the process. I’m fairly certain that without your plugin would’ve taken me another 3-4 months to complete.
project will end up being a gift to my family, siblings, and something we’ll be able to keep and share with our littles.
I managed to get it working by extending the system slightly. Although solution isn’t ideal as it doesn’t use the entire functionality your plugin provides it does fit it’s purpose so I thought I’d share it here for everybody that needs it! :).
I use the plugin functionality to grab the object normally, but then my actor has a ptr to the gripped object, and when I pulse the trigger key on my secondary hand I check if the secondary socket is in range and if so I manually call Trigger logic or whatever I wanna do with it, without relaying on the plugin to do the work for me. way I manage to bypass the logic and I successfully trigger the use functionality with my secondary hand.
Ideally, a proper implementation would just rely on the use of gameplay tags to determine if the secondary hand is the one using the object or not but I didn’t have the time to dig deep enough to be able to make those changes. solution was hacky but simple enough to introduce, hopefully it helps somebody!
Hey,
Thanks for the plugin it’s been a great help
I was wondering if there’s a way to allow rotation of a hand relative to a grip?
For example:
I have a lever switch and I want the hand rotation to not be locked to the switch rotation but be able to rotate along one axis
If isn’t included functionality whereabouts should I add ?
Also I was thinking about having fingers snap on to buttons, where I would rotate the index finger so that
if you’re near a small button it would snap on. It’s implemented in The Lab and I thought it was pretty useful. If I wanted to implemented that where should I do that?
Hey,
is anyone else having problems with creating a grippable skeletal mesh actor? If i create a BP using a grippable skeletal mesh actor an try to compile the created BP (no changes made to it whatsoever) i get a compilation error right away, saying that the BP is not valid. happens with the newest template project taken from https://github.com//VRExpPluginExample as well as a version some weeks older. Building the solution after DL the Git project worked fine, also creating e.g. grippable static mesh actors works without problems.
Cheers for any input on that!
You can implement the hand rotation in the animation blue print or as physical constraints or generalized logic, and yes, you are correct, the grasping hand is an example of core features, its intended to be expanded on or referenced, not used as is without changes.
You would want to add a data layer on top of the hand to handle custom posing and limits. Its not really a plugin related concept, I try to keep the plugin to core features and leave the gameplay elements free form for the end users to not limit them any, the template content is examples of how to use the core plugin features (in the grasping hands case, the welded body driver and decomposing grip transforms to attach correctly).
As for the finger auto targeting a button, CCDIK should work fine for that (or another IK setup though CCDIK is fast and has rotation limits) and already has examples for FPS pawns, you would just want to range limit to to a zone from the fingers base pose forward vector and only ik chain the finger itself instead of an arm.
It does it for a normal SkeletalMeshActor as well, not just a grippable. It will let you compile it if you assign a physics asset to the skeletal mesh.
I don’t remember ever running into before so I assume it is a 4.25 quirk.
The enemy character mesh is making a grip system.
I am trying to use a grippable skeletal mesh component, but if the setting value is similar to other grippable objects, only a simple ragdoll is executed and handling is not.
Do I need to refactor part?
You need to use the PerBoneGripping setting, you can also enable the advanced option of not setting physics enabled so that you can choose which bone chains get simulated OnGrip.
Per bone gripping takes in the bones transform instead of the actual components and the name of the bone to target. In the template it is just turning on the gameplay tag, in custom solutions you’ll need to pass that in manually.
Thanks for answering. That’s a cool system. I have one more question. When the bone is gripped, the lerp to hand script does not seem to respond if the default script and lerp to hand script are used together. It seems that the start point of the lerp always finds the location of the root bone, not the bone to be gripped. Is a bug?
mmm, yeah that script was sampling the gripped object for its initial transform, i’ll make it check by bone too if one is referenced in the grip information.
It will be up in the repo release in a couple of minutes, need to test it.
Edit its live, let me know how it performs for you.
Also you don’t need the default grip script specifically added to an object unless you want something else to run first (usually not the case since default also overrides the grip transform).
Hello,
We’ve run into a snag on our project. We have upgraded from 4.24 to 4.25. In the patch notes for the latest, it says that the slide component was switched to using absolutes to avoid confusion. Unfortunately, it has more or less destroyed the setup for the slides and bolts on our guns. Many of them are completely reversed now with no obvious way to return them to the way they were. Also our method of locking the bolts has been compromised. The scripting with the weapons is more of my dev partner’s wheelhouse so I can refer to him if you need any more details on the issue, but from what he tells me, everything’s gone awry. Would love to know if there is a way to revert (can we remove the absolute from the code and recompile?) or if there’s a workaround for ? Thanks!
You could remove the change sure, but it was done specifically because people were putting in negative values which were bugged, several features just didn’t work with negative values. Now it would work correctly with them.
If you were trying to “lock” values just setting the correct values so that it can’t move would work, it sounds like you were relying on the bugged logic not working correctly.
Edit I spoke with your partner and added a legacy mode to the sliders to not break behavior for people relying on it being bugged for whatever reason.
Hey Mord, thank you for your reply. We very much appreciate you helping us out with that legacy mode. Forgive me for not being up to date on all as I know you were having same conversation with him and also others in the discord - but as I understand it my dev partner was unknowingly exploiting a bug to lock the slides or bolts back. Is there currently a better way we should be doing , or if not, are you introducing capability soon? From what he tells me I think we will attempt to correct all the math and do it all the right way once we have a solid way of doing .
He could have just set the current position as the new base and locked min/.
But I’ll be adding a cleaner direct lock soon yes. Also I believe that it was mentioned to him that gun slides are actually easier to script with the interactible library functions rather than trying to hack around the slider itself.
Hello , am trying to import a skeletal hand mesh to be used instead of the mannequin’s skeletal mesh for PhysicsHands with Curl. Up until now everything is fine but, i got to the point where i simply cannot understand how the earth you 've done the physics asset for the hand! You got simple convex collisions, but it seems to my knowledge impossible to transfer those to the root bone!
So i tried adding capsule shapes as it’s quite close to the what i need for a humanoid hand. Now i see that capsule although the naming is correct ( index_01,02 etc ) and location/rotation, i get offsets while testing inengine
The Rootbone capsule for hand/palm collision seems to be the only one working as it should, but fingers get strange offsets. Maybe has to do with the location of the rootbone?
Thank you!
**EDIT **: ok i couldnt find how you did it, but i’ve imported UCX for the hand on a static mesh and imported them for the root bone. My offset issue was caused on grasping hand bp, when it sets welded bone driver, also removing it seemed to fix the physics hand jittering on grabed objects. In case anyone had that issue here it is
I applied the latest version code and tested it. We confirmed that the gripped bone name and transform are returned well. However, as a result, lerp to hand did not work normally. As a result of checking with the “vr.DrawDebugCenterOfMassForGrips” command, even though lerp to hand was executed, the lerp start point was seen as a motion controller. And when you override ClosestGripSlotInRange and forcefully perform slot grip with “neck_01” transform, bone grip does not work.
I think the reason why Lerp to hand didn’t work properly is because GetGripSlotInRangeByTypeName function doesn’t respond to bone grips. To bone grips with current logics, it must not necessarily be slot grips. When the slot grips come over to true, the bone grips do not work.
When bone gripping, it must be initialized with newComponentGrip.RelativeTransform = FTransform::Identify to operate normally. But as a result, the result that I want to get is bone grips through slot grips. If the slot is found correctly, but COM is Slot, the bone will not be handling. Can you give me some advice?
I’m really sorry for super basic question but am at a total loss.
Problem: on a gun, when grabbing with second hand, primary hand is forced to drop.
The BP is a child of a Master BP (altered version of the gun from the sample project).
I have several OTHER guns as child blueprints that use the exact same Master and work fine with the secondary grip, so it’s oddly unique to one child BP.
The mesh has a socket VRGripP1 and VRGripS1, just like the other guns do
Differences… gun has a lever attached, others have a slider. Secondary socket is also a lot farther forwards?
Where could it be calling to drop the primary grip for one particular BP?
Thanks in advance!
So i’m playing around with the plugin for my project and i’ve migrated the example character over to my project. I’ve also tried using the button actor that came with the example, when ever I push the button down my fps drops to 15 for some reason while in the example it was fine. Any ideas what could be causing ?
