Is there a way to simulate “lag” when gripping an object? I would like to grab a sword and make it so the sword lags a bit behind the controller position to simulate weight and also to make collisions more stable.
Also, is it possible to create two grip points per hand? I find that weapons behave best when double handed, I guess because just a single spring joint creates a lot of unstability when you move the sword fast enough. The idea would be to create a secondary grip every time I grab a sword with a less strength than the main grip but enough to stabilize the sword.
Have you looked at the example melee weapons in the example template? They already do all of that. How much latency the weapon has will be dependant by its mass and constraint damping with those, also the two handed on them is two entirely seperate constraints with different settings depending on if it is the “primary” or “secondary” hand position (more forward or rearward, depending on the setting selected).
For that matter, they also have spline based gripping on the shafts, penetration / stabbing, and hand repositioning.
Thanks ! I did take a look at the template and implemented part of the melee system in the game already Daggers and 2h weapons work fine, but long swords don’t feel right imo, at least using the defaults, but maybe I’m doing something wrong:
I’m able to generate “lag” but to do so you need pretty high values of weight and damping, making the whole thing feel like I have the weapon grabbed with a spring. What I’m suggesting is something similar to just lerping the controller position. Not sure if is how they do it in games like Blade and Sorcery or Saints and Sinners but the lag there feels much more like a lerp than to a spring.
I already use the 2 hand grip on a single weapon, but what I’m asking is if it is possible to create two grip points on the same weapon using a single controller. is because long swords don’t behave very well and kind of “bounce” on impact, and I find they behave much more realistically when I grab the weapon with two hands.
Sorry if I didn’t explain myself well in the previous post and thanks for your time!
again the bound part is your settings being off, if you want full literal control you can set it to set the COM (center of mass) on grip and then you will have really good control over the object. Its disabled by default as generally that is too much control on long weapons for one hand. The long weapons are intentially unwieldy in the template and expected to be used with two hands, the one handed settings are set so that they don’t behave well.
B&S doesn’t lerp afaik, it literally handles mass and COM and constraint settings. the same way, however it has softer constraints (more damping) on the rotation than the linear movements…
Saints and sinners does some actual lerping in that they use an arm IK with a scaler delay input and change that delay, they don’t run things through physics very much at all in that game actually.
If you want to lerp though it is easy enough for you to make a grip script that applies a constant scaler to the motion and place it after the melee script in the list of them, it will set the target transform of the grip to something that you define. You are actually looking at less realistic behaviors like that, but more controllable yes.
I’m dealing with an issue where the VR camera keeps rubber-banding back to the origin. It’s reminiscent of the same rubber-banding you get with networked regular multiplayer where a collision is detected. Except, I’ve removed all collisions with both the VR pawn and the immediate environment (gravity set to 0). So it shouldn’t be stuck on anything.
The issue only exists on the client side. If I were to spawn in as VR on the host machine, it would operate fine. The host machine doesn’t see any of the client VRs rubber-banding. The VR pawn remains in place (with the rotational transform replicating fine).
So it -looks- like the translation transformation isn’t being sent to the server to me, but I don’t see a setting for . I’m not well versed with working in the UE4 source yet, but I see OffsetComponentToWorld = FTransform(CamRotOffset.Quaternion(), ->GetActorLocation(), ->GetActorScale3D()); captures the camera rotation and actor location, but I know the actor location and VR location aren’t consistent.
Should be the replicated camera’s location instead? If not, do you have any advice on how to track down?
Which base character are you using there? Generally with the std VRCharacter head only movement shouldn’t be causing any rollback unless it is hitting something, I don’t roll back “IRL” movement as its client authoritative, I only enforce world collisions.
The simple char is a bit different, which is why I am asking which base class you are using.
Have honestly never seen anything like what is going on there aside from some guy that had an entire level in a collidable volume and was climbing every time he hit a button.
Yeah it was simple character. I went back over things again yesterday and swapped to the VRCharacter as the base and horizontal movement works fine without the rubber-banding. Although the client VR head is locked along a horizontal plane so all vertical movement is lost.
Looking through the code I see some ConstrainLocationToPlane usage that might be the culprit, but also I still have gravity at 0, and collisions disabled so it might think it’s in permanent freefall which could affect things. is probably an issue with me on my end.
What engine version are you on? The replication on the simple char was broken for a week when 4.26 first came out, but should be good in current releases.
Is there an easy way to modify the VRBaseCharacter to change the spawned GrippableMotionController class to a different class inheriting from GrippableMotionController without modifying LeftMotionControllerComponentName/LeftMotionControllerComponentName?
The reason is that I’ve written a lot of code to handle hand tracking and controller switching that I am separating out of my character class into a new blueprint that extends GrippableMotionController.
I’m having weird collision effect when using the plugin on swords ( is on Quest2, but on PC happens the same thing albeit a bit less pronnounced). It’s like if I swing fast enough the weapon “pre-collides” with the object at a distance from where the real collider is, the controller gets “stuck” in the air as if there was something preventing movement, and then collides again where the real collider of the table is. If I move the weapon slowly it doesn’t happen.
Big objects like the mace don’t have effect, but maybe it’s because they move a bit slower because of the damping.
Have you seen before? Any idea why is happening?
I’m on UE4.25.3 with substepping enabled (async = false, delta time 0.016, substeps = 6)
Thanks so much for your help. (the first and last time I hit the table does the precollision effect)
That looks like CCD bugging out, when it can’t entirely prevent tunneling it can freeze like that “stuck” in penetration (assuming you aren’t stabbing by accident that is), also a physx issue AFAIK, unknown if it will happen in chaos still as I still can’t run good tests against chaos until its working properly).
Handling the mass and setting the constraint coefficient on the grip settings (to 1 normally and adjusting stiffness to account for it) can remove that. Also making sure that the edge on the blade isn’t super thin.
I also have a setting to increase CCD steps in the project settings that I added, I normally suggest that people avoid using that as its possible to work around these issues by better balancing the physics settings on the object itself but in a few cases people have increased that to help.
Thank you very much , I didn’t know about the CCD Steps setting, will give it a try although I’m targeting Quest and I’m not sure if I can take any additional performance hit
Will play with the constraint on the grip too and hopefully it will go away with it.
You amaze me with your attitude and effort towards project.
I was wondering if there is a branch for ue5 and now I just saw that you updated it a minute ago.
I really hope that I can somewhen and somehow give back to you the value of what you give out to me and the community.
I’ve recently upgraded my project from 4.24.3 to 4.26.2 and I’ve found that some of my grippables no longer work. I’ve had a look at the migration docs, but I’m not seeing anything I think could be the issue.
In 4.24.3 I could have a normal Actor with a Grippable Static Mesh as root and that in turn could have a child Grippable Static Mesh which could be gripped and moved independently of the parent. What appears to be happening since upgrading is these grips are dropped immediately after the grip happens, as they are firing the Drop event.
I’ve tried with a Grippable Static Mesh Actor, adding a child Grippable Static Mesh, the parent actor is now gripped as expected, but in case the child component is dropped as soon as it’s gripped.
All grips are going through Grip Object By Interface, I check for hand overlap of components before actors when gripping, so components take proprity.
Is there anything obvious I might be doing wrong composing these objects as described?
Am I missing something between 4.24 and 4.26 about how child grips are handled?
Daggers and 2h weapons work fine, but long swords don’t feel right imo, at least using the defaults, but maybe I’m doing something wrong: