Just have the water volume not block VRTrace? That is the only channel that the gripping should be checking against. That or modify the blueprints to still switch nodes.
The template isn’t intended to be used without modifications, or as is at all really.
I couldn’t reproduce those results, let alone that a new mesh component that isn’t built in has no ties to the character and wouldn’t have anything special going on.
Thank you for that confirmation, it helped me better narrow down what I may have done to cause , and turns out the uPhysicalAnimationComponent was set to replicate causing delay/lag on the physics… Turning it off has lessened the effect by about 75%… Still get random spikes of drag/lag, gonna keep tinkering.
Strangely enough now, the effect now happens only when rotating camera around. When the mesh faces “straight” forward/default rotation, it’s smooth, if the player rotates the cam any direction, the previous lag/delayed results begin … Very strange… I have no code tied to “rotation” of the mesh in sample. Maybe something to do with Fabrik’s or something in the AnimBP tied to camera control, not sure anymore…
[video]https://streamable.com/vn4up8[/video]
In the video, the massive drag happens after I move the mouse a bit on the smaller window… The drag/lag doesn’t happen on other clients, only visible to the local player and their character. Really annoying
Here’s a better example.
[video]https://streamable.com/x8ngpi[/video]
Same results with uPhysicalAnimationComponent disabled or enabled.
Could be something with the Replication Type setting under VRGrip settings… But I’m not sure to be honest. Do those trigger only on grip or always?
Thanks again, and I know might not have anything to do with the Plugin, but if anything comes to anyone’s mind, lemme know.
Are these grippable skeletal meshes? If so, the only time that replication is altered is in ClientAuth grip mode, and only after a grip (if client auth throwing is enabled it stays around for a little bit).
Regardless, the character itself does not get any changes, and jittering wouldn’t be the effect of that anyway.
A little curious why replicating the animation component was even doing anything though, since its not moving itself.
Yeah the Body meshes are uGrippableSkeletalMeshComponent… The character itself isn’t getting jittery or artifacts in movement. Its the Body Mesh attached to Parent Relative Component, as it follows the PRC it drags behind as though its still following the Servers position of the PRC i guess, I can’t tell.
As for the replication effect on the PhysicalAnimationComponent, im guesing has something to do with “animation targets”? The target of where the physics are trying to be constrained to animation wise… The physical animation “target” i think if replicated, causes it to follow the servers version of the target rather than client… Again , just guessing, ones stumped me.
Here it is, more clear on whats happening. Full body physics on, and off, pelvis set to simulate as well time… https://streamable.com/cgw5qu
It seems server/clients all see each other as normal, only issue is the client’s own body… Might have to find a way to duct tape solution , by hiding the body and leaving a false non physics based body for local clients own view, but having the VR player interact with them physically (such as grabbing their hand and aiming their gun at a teammate as they fire) might be difficult to pull off way.
I have tried changing the priority of the physics volume from 0 to -100, -1, and +1, +100 but the player and controllers are still getting stuck, unfortunately. I am fairly new to UE4 and also from a level designer/artist background, not a programming one I am afraid. It would be a shame to have to remove all of the grippable objects from the water volume just to try and make things work. We could do with having a good programmer onboard who has UE4 experience i know, but we haven’t been able to find anyone who is available yet, unfortunately…
I will just keep playing around with things anyway and see what else I may be able to come up with
Many thanks once again for all of your help, and cheers!
So I ended up just setting everything to kinematic for the clientside view and only simulating on grip, or on enough damage to warrant a movement input disable, allowing the player to stumble realistically. It’s not ideal, but it still looks good for the VR player and thats the priority… Thanks for the help… Just to pick your brain real quick though, regarding blade melee physics. I saw your MeleeBase actor, was wondering if you could elaborate a bit on the blueprint work you had in there?And how does it tie in to the GS script?
Personally I was planning on going the walking dead method, and having a constraint spawn on impact point based on velocity, then only allowing movement on the X(or whatever the blades impale axis is) axis…Disabling collision between the meshes too. Though, i’m not sure how I’d add a resistance to the push or pull, or whether I could add wiggle room for the other axis’ based on how much the grip is pulling or pushing. Your input would be interesting…
And thanks again for the help on the other topic, if I manage to fix the actual issue, i’ll let you know of the solution incase it has anything to do with the uGrippableSkeletalMeshComponent
The melee base example blueprints for stabbing do just that, constrain to the surface hit with only the leading edge free. It uses an array of stabbing components that you can assign to provide different angles and forces to trigger a stab from.
Resistance to the push/push can be done just by adding some damping to the constraint holding them together, though if you want it more like WalkingDead they actually fake the forces for a lot of it and tie the visual arm to the weapon and have an invisible arm that they drive things off of. You could certainly do something like that, or you could drive the constraint stiffness off of the constraint impulse and when it hits a threadhold loosen it up to “break through”.
The grip script is mostly being used to calculate the velocities and handle the hand switching and movements, you could do away with it entirely, its a tooling class to take some of the effort out. I didn’t want to bake the actual constraint part into it as that would lower flexibility where people likely want it the most.
As for the grippable class, no it wouldn’t have anything to do with your issues (which I couldn’t reproduce btw, unsure what you are doing with your setup). Outside of when gripped the grippable class doesn’t do anything. The only thing I could see causing that is your client receiving corrections from the server due to improper movement setup. In that case the non default skeletal mesh doesn’t force teleport physics so it could hitch like that.
Hi, I posted question in the main VR thread but got no reply there. It occurred to me that I may be better asking here as I am using the VRE plugin to build my game.
I was wondering if there is a way to allow the player to teleport and walk on walls/extreme sloped surfaces, roof surfaces - basically ignoring gravity, so whatever surface you are standing on becomes the new floor?
Any idea on any methods I might try to achieve and where I could possibly slot in to VRExpansion?
There are a lot of forum threads about altering the character movement component to handle any gravity direction, none of them are going to be easy / bug free solutions though, even more so in VR / multiplayer.
Its on my (very) long term list of things to look at, but considering how much would have to be re-written in the character and tested to really ensure it works correctly multiplayer its nowhere near to something i’m tackling soon.
Also for that matter, that kind of movement mode it fairly relative to the users implementation, its hard to make a truly generic version that people can use for most any case.
That being said, if you aren’t looking for full gravity and aren’t looking for the full walking movement mode with surface redirection, then just setting the movement mode to “custom” you can align the character however you want to anything and run the logic yourself.
There used to be a good wiki page on it but its gone now. That blog is half correct, you do need to get the input values if trying to locomote from it and the networking should sort itself for the most part.
Thankyou - Will have a look. If I get something working I will send it your way to look at, although I somehow doubt you need the help!. And thanks for VRE - really helping my project come together.
I have done exactly what you said and the goods news is that the player is no longer getting stuck and the controllers now cycle through their settings correctly which is fantastic! However, neither the player nor any of the other movable objects either seem to be affected by the water physics volume settings at all, unfortunately.
It is possible that I have missed out on something stupid, but I have double-checked everything in a regular template and the physics volume works fine there, so I am not too sure exactly what the problem could be time…
Once again any help at all would be very much appreciated, thank you!!
Hi again, I have completed all of the steps in blueprint now and compiled etc + also added ‘DPad Press - Snap Turn’ to the MovementModes enumeration file, however when I cycle through the controller’s modes in-game the snap turn option still isn’t showing for some reason?
Would it be possible for you to help me with also, please? Thank you
Snap turn isn’t one of the default movement modes, generally you should be picking one movement mode at a time on the back end, letting it get set via a settings menu or something, and binding whatever key you want to the snap turn action.
The movement mode scrolling only exists in the template for people to play with the different options.
I have finally been able to get it working , thank you
I have attached a copy of the blueprint edit here in case anybody else may need a similar solution at all.
Also, I now have a mystery object which has suddenly started appearing every time I spawn!! If anybody knows what might be (see fig.2) or how to get rid of it then I would very much appreciate the input thank you!!
That is another pawn being spawned in, likely because you set it in game mode.
Those velocity settings in the snap turn node handle how character velocity is dealt with when snap turning by the way. You can have it re-direct to your new orientation if you aren’t using instant accelleration or if in a flying mode or something else that conserves momentum.