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 something you can do in Engine or was the mesh mirrored in Blender or something and reimported as a whole new object? Would doing 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.
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, would cause an infinite loop between the two moving each other I’m guessing…
Was there a better way to handle ? 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.
Hi all,
may very well have been covered before in 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 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 ( 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 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 is not a plugin issue, I just want to establish what the plugin *should *be doing, if possible.
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,
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.
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.
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 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+
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.
Hello .
I wanted to implement 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 interfere with the plugin? Thx in regards!
Ue4.24.3 has a bug where the motion controllers position are offsetted by something around meter on the x axis.(forward) The solution that epic suggested was to download the source version of the engine and add 2 missing brackets in the source code. That fixed the bug. But since your plugin is working without problems in version i thought that maybe you worked around bug inside the blueprints.
I don’t use their controllers, I use my own subclasses. I was aware of a ResetOrientationAndPosition issue with the steam input module but it should be fixed in 4.24.3, where did they have you add brackets that they were missing?
Ah, no that should also be in effect in my plugin, its a problem with the new input module for steamvr.
However it would only come into effect when resetting Orientation and position, and I do not do that in my template as its fully roomscale. That is the bug I was talking about in my earlier post.
