I hope I’m not being too pushy, but I’ve done some more testing and I still can’t quite manage to fix the issue. I tried replicating the Grip Actor / Drop Actor calls and have them use the Force Client Side Movement option. does indeed seem to make clients able to pickup and drop actors just like the host, albeit with a slight delay and much better syncing afterwards as you mentioned. However, when the client tries to throw the actor it still just drops straight down, whereas the hosts attempts all end up soaring away as you’d expect.
I’m thinking maybe the “Simulate” option for the drop function call might not work as intended for clients in a listen server. Back when we were trying to make our own networked VR gripping system we manually set the items physics to not simulate on grip, and then simulate again on drop. worked just fine for the host, but just like now it made the clients items simply drop straight down from their hands. It seems to me that maybe the momentum or velocity calculated by the physics engine are simply lost on the client side. I used to suspect was some weird property we’d accidentally set somewhere, but in my tests now I made a blank VRGrippableStaticMeshActor in which I only set its mesh, had it simulate physics and generate overlap events, so I’m no longer so sure if it’s caused by something we’re doing wrong on our end.
If it’s the case that momentum/velocity is simply lost or never calculated properly on client side, I’m thinking maybe our only option would be to start calculating each hands velocity on tick and passing these values along to the option velocity paramters instead of using the simulate option. Having it be properly simulated by the physics engine would of course be preferable, but as it stands now it seems that just won’t happen properly on our client side for some reason. Which is odd, as I’ve seen it working fine in other projects.
I also tried updating to the newest version of the plugin (We are using the latest 4.19 preview), but in case the plugin wouldn’t compile. It claimed the “FScopedMeshBoneUpdateOverride” at line 1330 in the VRSimpleCharacterMovementComponent.cpp file was an undeclared identifier.
Finally, wasn’t able to find the part in the exampletemplate where it’s checking for authoritative grips, so my solution was to just RPC all grips and drops as server functions as calling these on the host should have the same effect as calling them on a client. And I’m not quite sure what you meant by :
Its all working correctly for me (aside from needing to change some brackets in the latest patch to cover when not sending the velocities for client auth).
Are you using the optional angular / linear velocity inputs to the drop node? If you have the inputs reversed it would cause it to appear to drop straight down. But other than that it should be working fine, the plugin already sets simulating automatically and no, clients get velocity applied.
The velocity of attached objects aren’t calculated, but i’m not attaching these objects to the hands and even if I was I am reading their physics body velocity not their component one when I pass in the optional velocities and those update anyway.
The point of the optional inputs is so that clients get the velocity of their release applied to the throw instead of relying on the server to be “close enough”.
Also thanks for the heads up on the scoped call, I hadn’t built a non unity build in a bit so it was skipping over that, I updated 4.19 to fix it and ran a full non unity build to confirm (I generally run those near the end of a version update as I am usually the only one on the previews).
I’m currently messing around with expansion to use as part of a hobby game i’m designing for VR. I’m very new to all but so far have found the plugin to be great.
My current issue is that i’m trying to implement a holster system and i can’t quite get my head around why it isn’t working. The just of what i’ve done is on the event of a griprelease of the gunbase it checks to see if the gripped object component is overlapping the holster collision, if it is then attach the gripped object (the gunbase) to the LeftHolster socket attached to the LeftHoster mesh.
I apologise if i’m coming at from the completely wrong way but, like i said, i’m very new to .
If anyone can point out where i’m going wrong i would great appreciate it (or even share some tips on a better way of doing it)
What’s the best way to get the hand and the trigger pull amount while holding a gun?
Such as…when you pull the trigger on the controller I want to move the trigger on the gun.
thank you very much for fantastic plugin! I try to add body tracking following Ghislanzoni’s tutorial
in Super-easy VR body with Arm IK and thumbstick locomotion - Unreal Engine 4 Tutorial - YouTube I’m finding some problems to put both together. It would be of great help some advice to be able to anchor the camera to the bone of the skeleton as it does in the tutorial.
His tutorial is for non roomscale characters, not all of it will apply, attach your mesh to a parent relative component with the bSetToFoot set to true to root it to the camera.
CreateCameraTexture2D generates an empty texture of the right format for the camera (size and format). You call that, then pass it in the GetVRCameraFrame.
So:
AquireCamera - Save out the handle
CreateTexture
GetFrames
ReleaseHandle when done
I could have automated all into a component, but wanted to leave it open and just expose OpenVRs functions themselves.
I’ve got a question though: would it possible for 2 users to grab the same object in multiplayer? I’ve been messing around today a bit, but couldn’t find how to do it. I’ve seen that the default practice is to just “transfer” the object to the other player, when he tries to grab an object already held by someone.
You’d have to change the default BP implementation in the template and then either use the second player as a secondary attachment or run it with physics grips so they both apply forces instead of direct following.
(cut out the Already gripping check and drop logic, late updates would HAVE to be off, likely would want to turn off the defaulted center of mass setting as well)
Anything beyond that is up to you as there is no way of me knowing how you would want that to behave.
I have plans to setup something like anyway eventually using gameplay tags to define an object as multigrippable, but its not a high priority.
There is also a lot of considerations to take into account with multiple players gripping, what behavior exactly are you trying to get?
Thanks for your explanation. I solved it in that way (except that I can not find the variable bSetToFoot but it is resolved anyway) and then I followed the tutorial. Thanks again for great plugin and for explanation. Great job
Apologies if has been asked before, but I haven’t spotted a solution if it’s already been addressed: I’ve set up a damage-dealing volume using a conventional trigger-like structure using begin and end overlap, but the issue I’m facing is that the VRCharacter’s Capsule Component is registering overlap events, rather than the VRRootReference. What do I need to change to fix ?
Damage triggers look like the attached example.
The following code allows the VRRootReference to register damage events, but does not keep the capsule component from generating overlap events as well:
ABFCharacter::ABFCharacter()
: RightHandGun(nullptr)
, LeftHandGun(nullptr)
{
// Set character to call Tick() every frame. You can turn off to improve performance if you don't need it.
PrimaryActorTick.bCanEverTick = true;
GetCapsuleComponent()->SetCollisionResponseToAllChannels(ECR_Ignore);
GetCapsuleComponent()->bGenerateOverlapEvents = false;
VRRootReference->bGenerateOverlapEvents = true;
}
? What do you mean? The root reference IS the capsule component, I change the base class and provide a pointer to it so that accessing the functions are easier is all.
I was able to build a new project in 4.18 with the plugin, but I was hoping to use the example to understand how to use some of the features as I am pretty new to .
However, I am not able to build the example project. I tried dropping in the binary plugins as well and switch engine versions from 4.17, 4.18, and 4.19. I can generate VS files, but I can’t build after that. Is there a known issue right now or am I doing it wrong?
Hmm. Maybe I have my character set up incorrectly, or I’m interpreting what I’m seeing incorrectly. What I"m observing is that if I draw a capsule at the CapsuleComponentLocation, and another at the VRLocation, the former appears at the center of the tracking volume, while the latter appears at the location of my HMD:
So what’s happening is when the CapsuleComponentLocation overlaps a damage trigger, the player takes damage, even though the VRLocation is not overlapping the damage causer. So basically the player takes damage when the center of the tracking volume hits a hazard, rather than when their own perceived location does.
Am I thinking about incorrectly?
Thanks for looking at with me!
Mmmm, overlaps follow the VRLocation now, I changed how they behave around 4.16 or early 4.17 (sending the correct loc)? I did some testing just to be sure but all trigger volumes are working correctly for me off of the offset location, are you on an older build?
The rootcapsule IS the vrcapsule, I change its physics location and render transform to match the VR offset, the actors root location remains the same though, so things directly reading the root loc would be wrong.
Edit You are dereiving from VRCharacter and not BaseVRCharacter right? Because that would be a different story.
Thanks a lot for the suggestions (and sorry for my later reply)! I’ll try modifying the template project as you said tomorrow.
What I would like to achieve is a “collaborative work” thing, meaning 2 guys moving an object together from one point to another, like a heavy trunk that can’t be lifted by one guy alone. I imagine that there will be lots of problems with , but just to be able to let 2 guys grab the same object would be a good start to work with!
Yeah you either need a custom grip and to define how it interacts like that then, or you need to run with physics grips which can allow for mutliple inputs.
Ahhh, I found what was going on. My motion controllers were still generating overlap events, and the usual posture from which I was testing caused the controller positions to coincide with the character origin often enough to produce a result that misled me. Removing collision and overlap generation from the controllers (we’re not grabbing anything in game) seems to have fixed the issue. Thanks so much for looking at it with me!
