thanks for fix, now work perfect, have you planed to implement distance grab for object ?
That is easy enough to do by anyone that wants it, there is also a LerpToHand grip script if someone wants to use that and just set the distance to grip at higher distances.
Though if you click with the laser pointing at something it will fly at you currently.
thanks, thats cool, i really tried to find LerpToHand grip script, but i cant find, sorry for being a noob, i m coming from unity, and i am little lost with blueprint, please can you provided little tutorial, or blueprint screen capture. thanks very much
On grippables there is an array of GripBehaviorScripts that you can add too, they are modular logic blueprints that can be attached and ordered to any of the plugins core grippables. One of those is the LerpToHand one that will lerp objects to their target position if they are farther than that post grip.
Generally you would change the grip logic to select off of a long distance trace instead of a short one.
Granted you are also free to manually lerp objects in to the hand and then grip them when they are near as well.
Hi ,
Is it possible to define different linear drive parameters for the StabConstraint, so it’s easier to push the weapon forward than to remove it from the lodged component?
Thanks!
I specifically left the constraint control out of the melee script itself. You can alter it to your hearts desire as it is just a constraint component.
You can set the linear drive target position to the full penetration depth and set stiffness (it defaults towards 0 as the target), that would apply some inward force towards full penetration and would make it easier to slide in than out. Or even use a second constraint to apply that force, you would just have to be careful with either method that its not so powerful that it overpowers the actual grip and causes jitter. You could also dynamically change the strength of the constraint based on the impulse direction if you wanted too, and map it to a curve even to drive layers of resistance based on depth.
If your goal is something like the inverse to the walking deads setup, they specifically fake the stabbing somewhat and drive the depth from the hands estimated position instead of real physical force.
Yeah, I was thinking in changing the strength of the constraint based on the direction but I wasn’t 100% sure if there was already a way to do it with the plug-in 
Thanks so much !
Yeah about that, I can’t get my hands to replicate, that is the meshes are visible, but no animations.
I’ve ticked “Replicate Skeletal Data”, tried with smoothing and without and all options in the replication type.
I thought it could be my Steam VR input, but I enabled it and it seems set-up right, skeletons are assigned.
It works perfectly fine in VR for the user in VR, both in editor and packaged game.
I’m using steam with the advanced sessions plug-in.
Many thanks, your plug-ins are the best!
You are using the correct animation node right?
Hey . Just started learning the plugin and immediately stuck with the following question: what would be the proper way to connect 2 separated grippable actors to each other in multiplayer? Let say I have a bullet and a magazine. I would like to insert bullets into the magazine (and take them out later), so obvious solution here possibly would be using DropAndSocket function which should do everything on it’s own. Following the “Potion” example it should be straightforward, but what actually happens is that at the moment I insert a bullet into the magazine it starts flying around (like physics or collision is not getting disabled in either a server or client). Experimenting with different settings I found that if set replication into the Client Side Authoritive and disabling the physics and collisions manually it stops flying around but still works unstable.
It would be helpful for me If you could explain what would be the proper flow for things like : attaching N grippable actors into another grippable actor, like inserting rounds into the magazine, magazines into the weapon etc. I would say that it worked properly if I run it offline, but start glitching when I switch to the “Run as client”.
You would want to have bWeld true on the drop and socket, which connects the physical bodies of them together on attachment. If you don’t weld them together then the simulating parent can collide with the child. You can also disable collision on the child to save some perf but its usually not needed.
Unsure what engine/plugin version you are on but I did make some changes in 4.25 where welding is correctly replicated for specifically grippables now (I can’t remember if its back ported to 4.24), the engine itself doesn’t replicate welding in multiplayer (long term bug that I haven’t gotten them to fix yet) so I had to go in and specifically change it for my base classes.
If your bullets aren’t grippables than they would still have welding bugged out as its an issue at the engine level.
Is the skeletal component set to replicates as well as its parent actor? It should be functioning then.
It should also throw log errors if it is running into any.
They are. But, like the idiot I am, I was changing values on the left hand and testing with the right, solid move.
I managed to get it working with hard transforms only, which is not ideal.
I’m including a pic of my pawn tree, maybe something is missing here, I did not copy your pawn from the template as their is just too much going on for me.
My actor (VRCharacter class) is set to replicates, but my VR root reference is not, don’t know if that matters. My motion controller components are replicating as well, I figure I’d get no visible motion controller tracking at all on another client if that weren’t the case.
Thanks!
The steam replication mode uses their function which blends between static poses that they know about on the back end, due to its unusable unless all other players are also running steam at the moment as it can’t translate on their end otherwise.
Repping curls only will work for blending hand animations from open to closed, the hard transforms pathway I made isn’t as efficient as valves (since I don’t know the hard poses on the back end I have to encode more data), but at a sane update rate it shouldn’t be a problem for your project (20-30htz or even 10, with smoothing enabled).
I don’t send joints that don’t need to be sent and I pack the data pretty heavily.
Great, I’ll just run it way then, thank you for your time.
Hey… I’m back lmao.
Could you clarify what method you’d use to keep the capsule from ticking to stop it from adjusting to player real-world movement temporarily? I’ve fumbled through the functions but didn’t find anything that would help me out. Is there something UE native I should be looking for? is of course in reference to allowing a head lean independent of capsule movement. I will follow up with a post if I figure it out. Thank you again
Got it! VRRootReference->SetComponentTickEnabled(false);
Sometimes ya gotta just tap through every single function in the UE API hahaha. Let me know if you want me to remove posts like , but otherwise I’ll leave them up for others to see
At my wit’s end setting up climbing…Is there anything obvious I’m missing? (I know it’s my fault, not the plugin, just going crazy trying to implement in C++ using the BP tutorials Raven provided on YouTube). The present issue is that I’m flying into the f***ing stratosphere as soon as I grip a climbable object. It works trigger-wise, but the movement is calibrated completely wrong somehow. I’m ending up miles away outside the world bounds instantly.
Here’s my code after I line trace for a potential climbable object, bold at the important parts:
if (HitResult.GetComponent()->ComponentHasTag(ClimbableObjectTagName))
{
AActor* HitActor = HitResult.GetActor();
bRHIsClimbing = true;
ClimbingController = RightMotionController;
RHClimbingGrip = HitResult.GetComponent();
**VRMovementReference->SetClimbingMode(true);
FVector ClimbGripLocation = RHClimbingGrip->GetComponentTransform().InverseTransformPosition(RightMotionController->GetComponentLocation());
FVector OtherNightmarishThing = (RHClimbingGrip->GetComponentTransform().InverseTransformPosition(ClimbGripLocation));
MovementToDo = -(RightMotionController->GetComponentLocation() - OtherNightmarishThing);
VRMovementReference->SetClimbingMode(true);**
}
Then in BP, pulling out from the Event UpdateClimbingMovement node, I have it run Add Custom Replicated Movement and the input for that is my MovementToDo vector seen above in C++ (it’s BlueprintReadWrite, I couldn’t find a way to override UpdateClimbingMovement from inside C++). Hope there’s something quick and obvious I’m missing, thanks for the help as usual.
You are relating a relative position on the object to a world space position of the motion controller at the end there. "OtherNightmarishThing should be created with ClimbingGrip->TransformPosition, not InverseTransformPosition, its already been inversed in the step above, you are trying to make a location that is already relative, relative again.
As for the override, you override
virtual void UpdateClimbingMovement_Implementation(float DeltaTime){} // Do nothing by default
in a c++ subclass.