Your right; I wasn’t thinking about how these same physical grips would clash with each other and they did clash, haha.
Thanks for the advice on the physics handle setting node and the weapon orientation component. With , I was able to lock/unlock each hand rotation depending on what was forward and back on the weapon.
I’ll keep looking through the grip scripts, but as always, I appreciate your support. 
Hello,
short question: Why has the GrippableCharacter no OnGrip or OnGripped Events?
Cant find any documentation about that class. Im trying to make enemies grippable, so my goal is to stop animation and movement when the enemy is grapped or at least play some specialized animations. Also maybe activate physics like the grippablemanequin example.
Thanks for you help.
Getting some weird behavior in the example template, while testing multiplayer.
While using grasping hands (Physics or normal) everything works as intended for the host / listen server. However, remote clients (Play as client) will get a weird offset when they grip an object. The gripped object seems to move / snap a couple of units up. Weirder still, respawning the default controllers in the same session, will cause them to also experience issues, despite working previously.
Is a bug or are grasping hands not multiplayer ready out of the box?
The mesh is the grippable part, and it does, but due to how the engine handles overridden base components it doesn’t display the mesh as the correct type in editor. I have a note to go in and add a GrippableSkeletalMesh reference to it so that its easier, but in the mean time you can cast the skeletal mesh to a GrippableSkeletalMeshComponent and manually bind to the events.
Grasping hands were not built around multiplayer right away no, for one, their functionality is going to be very expensive for multiplayer (the overlap lerp with multiple players). Generally for multiplayer you would be better off with pre-built poses for grasping things.
An offset like that would be strange in VR, were you testing in FPS where I don’t have the controllers using the controller profile directly?
I see, it’s a shame they are not entirely multiplayer ready, but what you say make a lot of sense. Was hoping for a quick way to get hand collision with the environment, but at least it’s a good suggestion with pre-built poses.
I did some more testing to confirm the issue and it gets weird, but makes sense if they’re not entirely multiplayer compatible. I did the tests with remote client (Play as client).
I did a test with the FPS pawn with grasping hands and things seem to work as expected, funnily enough, although with the expected lag.
For the original test, I was using the VR preview with a HTC Vive headset. I changed hands using the screen in the template map. I don’t know if I was using the controller profile directly, but by default it displayed the default device controllers.
I initially reported a strange offset during grip, but it seems to be the physics scene which is weird for the remote client. The physics grasping hands will push objects a meter away and generally seem to be desynced from the server in some way when playing in VR.
In any case, thank you for the suggestion and time.
Its entirely solvable for multiple in the general sense, but would require some teaking of how the initial spawning and setup is handled is all.
Normally I store player state variables in the PlayerController where the input handling is done, but I see how in the case of VRE, the input handling is done by separate characters (one for keyboard/mouse). Would you recommend I store game state variables (i.e. health) in either the player controller or within the vive pawn character?
Hi, I’m responding to earlier thread with Stanzzz about running into difficulty turning off visibility for the hand colliders.
I looked into further, and it seems something is indeed overriding the visibility settings. Any component, such as the hand, cannot be hidden either.
I tested in a new unmodified project, and as you said, it takes seconds to disable the visibility of any of the components.
However, in terms of our project, I am baffled as to what is the cause of our issue. Visibility is fully off for all components in both the Vive character and the FPS character. Yet full visibility persists.
I did a check in Windows Explorer for any hidden files, but all I came across were some redirectors, which I easily fixed in UE using Fix Up Redirectors.
So I don’t really see any source for what could be the cause of , and on a bigger scale, is concerning me that could be leading to other issues down the line.
(For example, when starting the game, sometimes the hands start farther away on the floor, instead of in front of the player, and am wondering if glitchy-ness is related to the same issue)
Any advice on looking for any potential hidden duplicates or ways the blueprint behavior could get overwritten would be greatly appreciated, thanks!
Entirely depends on your game design, considering how you are directly working with tracked devices though, and they are generally either directly inside of the pawn or attached too it. Its cleaner in more cases to handle the input there in VR than in the PC. Variable storage is more of a “where and when” you want access to it kind of thing, health on a PC would include the assumption that it would carry over across multiple bodies, also in the player controller it won’t exist for other players if you are doing multiplayer so you would have to have a duplicate health value that is replicated instead of just using the same one for instance.
Its common to have input and variables in either PC or char, or spread across both, your application should dictate which combination you should be using.
Hands starting farther away is either the tracking not having kicked in yet so they are stuck at zero, or you are using a re-zero’d base with 4.25 and the steamvr module which is bugged currently.
As for the grip sphere visibility, literally just loading up the editor, setting one of them to IsHidden in the blueprint editor and starting in VR works fine for me.
I have been working around with the raycast in the project, where we can pull a object towards you if you have the raycast pointed at it and clicking the back trigger. Is there a way to turn off the coloring of the raycast and still have it work? What my goal is with the raycast is to have it casting without color then when it hits a objects that I can interact with, it will have a highlighted glow to it, so I know which object it interactedable.
That is just the laser beam for widget interaction, it made the most sense to throw on a brief targeting concept to that.
Just use your own trace and highlight and don’t rely on the laser beam. You can cut the code from the BP_TeleportController and move it to your own control component or function somewhere. All of the actual “when/how” to do stuff for everything in the plugin / example is public facing and open to changing by the user.
I try not to bake control logic into anything when i can help it.
“Event on used” **works inside grippable static mesh actor **but not with grippable static mesh component. Did I forget something?
That plugin must be implemented strangely if it needs an entire base actor class to pool with, you should easily be able to create your own pool system, they are very simple, its just spawning as needed (need more than current pooled count) and not deleting but deactivating and re-using.
Regardless, you are likely dropping it, default settings will drop on trigger release which will override the use command.
Set drop on grip or something else so that it doesn’t try to drop it instead of use it.
Hello,
Whenever i migrate the vive character to a new project (collisions and all game settings working correctly) the grab sphere gets spawned at the wrist rather than the physical root (which is in correct position) when using physical grasping hands. Likewise when i create a child of the existing grasping hands (no edits). The physics root is in the correct position and when spawning just grasping hands it is in the palm. Any suggestions? Kind Regards
Not sure, sounds like a linking issue where its not going back to the character correctly? BP migration is a bit finicky, did you open up the grasping hands and re-compile them and fixup any redirects?
I apologise, I did not realise a socket was determining the location, I thought it was the grab sphere on the vive pawn character. I had not set the socket on my replacement skeletal mesh.
Hi everyone !
I try to have my motion controller have physics collision with walls to prevent it from passing through them but I don’t find any tickbox or solution to do that, someone has a solution ?
Thank you by advance for your help !
You’ll have to use a mesh with collision then and enable it to block channels. Then you need to decide if you want to constrain the controller mesh to something to have it physically blocked, or if you want to manually sweep check it against geometry.
Motion controllers themselves have no collidable body, they are primitive components with no primitive.
Hi I have a question regarding overriding the holding hand’s effect on the gripped object, more specifically the objects rotation.
I grip a bow in my left hand, and the bow string/arrow with the right. Depending on where the right hand is while gripping the string, I want to rotate the bow accordingly.
So I do a setActorRotation on it directly. However, the bow-gripping hand overrides my setActorRotation and tries to align the bow back to the gripping hand’s rotation - creating wild jittering - as two processes fight between them to set the bow’s rotation. How can I alleviate behavior?
Quick question… hope things are going well on your end…
What do you think would be the best way to go about disabling the trigger from being able to activate the Use event on a held object if a button/bool is pressed on the controller?
and instead, perform another grab?
Sorry if was worded weirdly, let me know if I should rexolain better in more depth what I’m trying to achieve.