VR Expansion Plugin

[waslegit]

Hey mordentral,

I've been working on implementing a custom static mesh to your grasping alyx hands and have been running into issues similar to ones I've read on here before. I've got the right one working really well but the left one is giving me troubles. I'm aware of the issues with inversely scaled hands so I've been just trying to edit the GraspingHand_Left blueprint with my own custom meshes but not having luck.

What is the proper workflow for setting up a custom mesh with them? I saw that you had a community member mirror the hand, is this something you can do in Engine or was the mesh mirrored in Blender or something and reimported as a whole new object? Would doing this mirror the bones, animations, and collision physics?

Also I saw you mentioned before enabling mirroring on the left hand, I can't seem to find that option anywhere.

Thanks and let me know, really dope plugin!

[thelazylion]

Shouldn't have anything to do with the plugin unless I missed a super call somewhere, and then you would never have mouse input at all.

That line in VRBaseCharacter is unrelated as it is just casting the character type for future reference, though I would like a copy of that crash report if you get it again, cast shouldn't crash there.

I reverted back so I'm not sure i can get that specific crash again.. I'll let you know if I run into it again.. For now I have duct taped a solution together.. Works fairly well for now.. Will let you know if anything else comes up..

Going back to melee weaponry..
Wanted your opinion on how you would handle weapon gripping on NPC's.. Since they shared the same character base as the vr character on our project, would it be viable to let them artificially use the inherited motion controllers attached to their hands, to "grip" their weapons, therefore allowing the player to parry their swords/melee weapons around..

However I was thinking the weapon would be gripped to the Hand, but the IK of the hand would also have to grip and follow the sword's movement as it gets pushed around by the player, this would cause an infinite loop between the two moving each other I'm guessing..

Was there a better way to handle this? I couldn't find too much useful info on how Blade n Sorcery handled it on their end.. The default way would be just to attach the object to their hand and set physics on, but it doesn't sound like it would let the player push the enemies blade around.

Any info is always helpful and appreciated

[3agle]

Hi all,
This may very well have been covered before in this thread but it is very long and I haven't been able to search for it effectively, so I apologize if it has been covered.

I've encountered this plugin in a project I'm working on (I didn't implement), and I am experiencing a problem with HMD position replicating across the network (this functions fine), causing the local position to jitter at high ping. I am under the impression from some of the code paths in UReplicatedVRCameraComponent that the sending client should not use replicated values, yet that does appear to be happening (the higher the ping the more jitter when laterally moving the headset). Turning off replication on the component results in no lateral movement of the HMD in the world. Is this expected behaviour for the plugin? I would have expected the local player would always update using the transform given by the HMD. Could it be that there is some sort of authoritative HMD position flag somewhere?

Also the code is based on plugin version 4.22 and there have been modifications to it within the project, so fully willing to accept that this is not a plugin issue, I just want to establish what the plugin should be doing, if possible.

[mordentral]

Hey mordentral,

I've been working on implementing a custom static mesh to your grasping alyx hands and have been running into issues similar to ones I've read on here before. I've got the right one working really well but the left one is giving me troubles. I'm aware of the issues with inversely scaled hands so I've been just trying to edit the GraspingHand_Left blueprint with my own custom meshes but not having luck.

What is the proper workflow for setting up a custom mesh with them? I saw that you had a community member mirror the hand, is this something you can do in Engine or was the mesh mirrored in Blender or something and reimported as a whole new object? Would doing this mirror the bones, animations, and collision physics?

Also I saw you mentioned before enabling mirroring on the left hand, I can't seem to find that option anywhere.

Thanks and let me know, really dope plugin!

If you aren't using physical hands then it is a non issue, you can simply spawn another right hand with the scale inversed and it should work as is. Its when simulating that it gets to be a big deal since the engine incorrectly translates the collision and orientation of the object when constructing its simulating body.

I would consider using the animation mirroring plugin to make life easier for you, it should be able to work with a left hand setup if I read his feature list correctly. Other than that, yeah you would have to have a new AnimBP for a mirrored hand, the one in the template is actually incorrectly mirrored and has a bit of an offset and one of the animations is lined up incorrectly, mirroring the actual right hand over and keeping the same facing would probably work best.

In the end the seperate manniquin hand isn't ideal in the first place since its pointing Y+ with some pitch, an X+ version would be easier to manage,

[mordentral]

I reverted back so I'm not sure i can get that specific crash again.. I'll let you know if I run into it again.. For now I have duct taped a solution together.. Works fairly well for now.. Will let you know if anything else comes up..

Going back to melee weaponry..
Wanted your opinion on how you would handle weapon gripping on NPC's.. Since they shared the same character base as the vr character on our project, would it be viable to let them artificially use the inherited motion controllers attached to their hands, to "grip" their weapons, therefore allowing the player to parry their swords/melee weapons around..

However I was thinking the weapon would be gripped to the Hand, but the IK of the hand would also have to grip and follow the sword's movement as it gets pushed around by the player, this would cause an infinite loop between the two moving each other I'm guessing..

Was there a better way to handle this? I couldn't find too much useful info on how Blade n Sorcery handled it on their end.. The default way would be just to attach the object to their hand and set physics on, but it doesn't sound like it would let the player push the enemies blade around.

Any info is always helpful and appreciated

Use the physical animation component in your NPCs, and use two physics constraints with hard settings (not soft) to lock the palms to the weapon at the correct locations. Pushing against the blade would push the physical arm back as well then, same goes for if you wanted physical arms for the player as well, it would be best to throw out the custom grip logic and go hard constraints and manage the constraints on the arm bodies instead.

You can just "attach" if you are using one handed with welding enabled and that would work as well, but constriants will let you be more flexible going forward.

[mordentral]

Hi all,
This may very well have been covered before in this thread but it is very long and I haven't been able to search for it effectively, so I apologize if it has been covered.

I've encountered this plugin in a project I'm working on (I didn't implement), and I am experiencing a problem with HMD position replicating across the network (this functions fine), causing the local position to jitter at high ping. I am under the impression from some of the code paths in UReplicatedVRCameraComponent that the sending client should not use replicated values, yet that does appear to be happening (the higher the ping the more jitter when laterally moving the headset). Turning off replication on the component results in no lateral movement of the HMD in the world. Is this expected behaviour for the plugin? I would have expected the local player would always update using the transform given by the HMD. Could it be that there is some sort of authoritative HMD position flag somewhere?

Also the code is based on plugin version 4.22 and there have been modifications to it within the project, so fully willing to accept that this is not a plugin issue, I just want to establish what the plugin should be doing, if possible.

Turning off replication will not effect the local movement of the HMD normally no, it sounds like your client somehow set it up so that the player is not fully possessing the pawn and is receiving camera replication on the camera they are using for their local view. The clients send their local camera transform out to the server via RPC and it is returned back to all (non owning) clients via a replicated variable.

Not entirely sure how that could happen, it would take some effort to break it as much as that. Its possible that they removed the Cond_SkipOwner part of the replicated variable?
I still have users in multiplayer in 4.22 so it is highly unlikely that a feature back port broke any of that (still possible, just very unlikely).

The camera updates its local position on GetCameraView, which should set later in the frame than replication, so the mostly likely outcome is some sort of setup where they aren't fully controlling their pawn somehow.

[CokeKuma]

hi. morendetral.
I am currently modifying the climbing logic a bit and I have a question to ask.
Climbing actor was implemented through on grip and on grip release event, but when climbing mode is applied through on grip, there is no collision reaction with climbing actor.
Are there any variables that can change this setting?

Climbing actor used "grip type - events only" to make use of only the necessary gripping events.

[3agle]

Turning off replication will not effect the local movement of the HMD normally no, it sounds like your client somehow set it up so that the player is not fully possessing the pawn and is receiving camera replication on the camera they are using for their local view. The clients send their local camera transform out to the server via RPC and it is returned back to all (non owning) clients via a replicated variable.

Not entirely sure how that could happen, it would take some effort to break it as much as that. Its possible that they removed the Cond_SkipOwner part of the replicated variable?
I still have users in multiplayer in 4.22 so it is highly unlikely that a feature back port broke any of that (still possible, just very unlikely).

The camera updates its local position on GetCameraView, which should set later in the frame than replication, so the mostly likely outcome is some sort of setup where they aren't fully controlling their pawn somehow.

Fantastic, thank you for the information. No doubt it is something that is broken in the project, this will help greatly with the search

[mordentral]

hi. morendetral.
I am currently modifying the climbing logic a bit and I have a question to ask.
Climbing actor was implemented through on grip and on grip release event, but when climbing mode is applied through on grip, there is no collision reaction with climbing actor.
Are there any variables that can change this setting?

Climbing actor used "grip type - events only" to make use of only the necessary gripping events.

I set MoveIgnoreActor on actor grips so that pushing them into the body doesn't stop the pawn from moving. You can either delete the entry again by calling MoveIgnoreActors.remove the actor, or grip a component inside of your climbing actor instead.

I will also change the source so that event only grips don't do that step, it was an oversight on my part that they are.

*Edit* Changed to no longer ignore movement on events only in 4.24+

[thelazylion]

Use the physical animation component in your NPCs, and use two physics constraints with hard settings (not soft) to lock the palms to the weapon at the correct locations. Pushing against the blade would push the physical arm back as well then, same goes for if you wanted physical arms for the player as well, it would be best to throw out the custom grip logic and go hard constraints and manage the constraints on the arm bodies instead.

You can just "attach" if you are using one handed with welding enabled and that would work as well, but constriants will let you be more flexible going forward.

That sounds perfectly viable, I'll give that a try using two constraints.. Thanks again..

[CokeKuma]

I set MoveIgnoreActor on actor grips so that pushing them into the body doesn't stop the pawn from moving. You can either delete the entry again by calling MoveIgnoreActors.remove the actor, or grip a component inside of your climbing actor instead.

I will also change the source so that event only grips don't do that step, it was an oversight on my part that they are.

*Edit* Changed to no longer ignore movement on events only in 4.24+

Thank you for your answer. I am using version 4.25.
The notifygrip and Drop_Implementation function still have the part that handles MoveIgnoreActors.

[mordentral]

Thank you for your answer. I am using version 4.25.
The notifygrip and Drop_Implementation function still have the part that handles MoveIgnoreActors.

You have to update, I changed it after replying to your post to skip that step for event only grips.

[NebulyDev]

Whenever i grip something with the grasping hands, the hanbds phase through the level geometry. Is there a way to make the hands count as collision for the gripped object. IE them getting blocked on the level along with the held object?

[mordentral]

Whenever i grip something with the grasping hands, the hanbds phase through the level geometry. Is there a way to make the hands count as collision for the gripped object. IE them getting blocked on the level along with the held object?

In the SetupPhysicsIfNeeded function you would want to make the DisablePhysics node enable instead. You would also likely want to them setup the welded body driver on the non simulating hands as well as I am not since they weren't colliding.

[The VoiD]

Hello mordentral.
I wanted to implement this plugin to my project. But I'm using the source version of 4.24 and already added the missing brackets in the sourcecode so the vr hands are not offsetted anymore. Will this interfere with the plugin? Thx in regards!