Looks like you are using the secondary attachment on the back hand there, I’m not entirely sure what your grip setup is but you would just always want the secondary attachment property to be on the rear hand grip and targeting the front hand as the attachment point.
If you are using the template gun, it switches primary hands when you drop the rear if the secondary is attached, it then switches back to the rear as the primary if it is gripped at the socket, it may be that you changed the socket setup of your gun and its not performing that flip.
Since that part is all in the bps you can freely change the logic to correct it for your use case.
Oops, I actually missed using the secondary grab logic completely! I’ve been using the “GripObjectbyInterface” function for both primary and secondary hand grabs.
However, I still prefer method as I personally like how the weapons sockets essentially glue themselves to the GripMotionControllers.
When using “GripObjectByInterface”, do you know if there’s a way I can tell the logic that " is my primary hand" so it knows which rotation to follow?
Thats the thing, using multi grip with full grips doesn’t, you would need to unlock an axis of constraint in order for it to rotate like that with a physical grip. Also it doesn’t “glue” to the motion controllers at all, it would be finding a median between the two controllers, in fact it shouldn’t by default be behaving correctly for you at all without tweaking so it may be not even having a rear grip for you currently (multi grip would have to be on).
For it to function somewhat like that, you would just need to figure out which hand you want to be rotation free and call SetPhysicsHandleSettings and set the axis that you don’t want to be constrained on that hand to off.
With a gun tools script active the weapon orientation component will dictate what direction the constraint is facing, you can use that to make it easier to know which axis’s to turn off. The melee tools grip script does that by figuring out which hand is in the rear and which is in the front and handling constraint limits based on that.
If you wanted a literally accurate version you could also just use a physics prop script on the weapon and you would have to face both hands in the same direction and align them to aim the gun, no free rotation around a hand at all.
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.
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.
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.
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.
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.
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.
