If you are manually moving your character then its not going to sync with the server unless you use a movement component compatible replication method (like the move actions). Making the movement entirely client auth “works” but is far from ideal obviously.
Also I meant turning off walking mode when leaning over a ledge so that it doesn’t trigger the falling movement mode, you could also adjust the VRCapsuleOffset with a detected lean to push the capsule back farther, or disable ticking on the capsule for a moment.
They use VREPhysicsConstraintComponents so its actually pretty simple, one of the additions I added to my subclass is GetCurrentLinearDistance which is the distance in world space from where the constraint (hand) wants to be and where it actually is, you can check against that and some threshold that you set to trigger the lerp to hand event. You can also sweep to check for collisions between the two and trigger it earlier.
Typically it should already be using touch based and not press based inputs.
Which controller are you using? That just comes down to rebinding some inputs, depending on if you are launching in steam or oculus or oculus over steam how the bindings have to be different. I tried fixed the native rift controls but if you are running through steam it may need input re-mappings (steam input doesn’t generate correctly and needs manual adjustment).
If not in steam it can all be changed in the project settings / input using the cap touch inputs instead of button press, if over steam since it doesn’t generate the defaults correctly you have to go into the overlay and rebind and save over the defaults, I’ll run over them again soon and check if any changed between 4.25 and .26 and needs adjustment, my primary test controllers are the index ones so those should be fine as is.
Edit Yeah the start movement inputs reverted to thumbstick and not captouch, I fixed it and uploaded. Latest template should have it working as expected for you.
Got it, thanks. So what then is causing my add movement input driven character’s Walk Speed to be throttled at like 250 when it’s much higher and works properly when the pawn has authority, but not when it’s a client? It seems like it thinks I’m moving unexpectedly fast and holding me back
Sounds like you are setting the walk speed on only one end? those don’t automatically replicate.
That or you are doing something only on the clients ends that is causing rollback, you can bind to the OnCharacterCorrected event to print out when a correction happens.
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.
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?
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
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.
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.
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.
