Download

VR Expansion Plugin

Hi,

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 this.

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:


// draw capsule location & size
    const FVector& CapsuleComponentLocation{ GetCapsuleComponent()->GetComponentLocation() };
    const FRotator& CapsuleComponentRotation{ GetCapsuleComponent()->GetComponentRotation() };
    DrawDebugCapsule(
        GetWorld()
        , CapsuleComponentLocation
        , GetCapsuleComponent()->GetScaledCapsuleHalfHeight()
        , GetCapsuleComponent()->GetScaledCapsuleRadius()
        , CapsuleComponentRotation.Quaternion()
        , FColor::White);

    DrawDebugCapsule(
        GetWorld()
        , GetVRLocation()
        , VRRootReference->GetScaledCapsuleHalfHeight()
        , VRRootReference->GetScaledCapsuleRadius()
        , VRRootReference->GetComponentRotation().Quaternion()
        , FColor::Magenta);

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 this incorrectly?
Thanks for looking at this 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 this, 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.

Should be solvable.

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 this game) seems to have fixed the issue. Thanks so much for looking at it with me!

Good to know!

By “physics grips” you mean like the “manipulation grip” type?

Manip and interactive with physics, though the latter needs some changes to work really well with it.

Alright, I’ll look into it, thanks again!

Patreon support here and I’ve lost my link to the discord invite. How do I get back into the discord chat channel?

I’m having a problem in multiplayer dropping a gripped object programmatically. In my character blueprint I have a function that will drop the specified held object from my hand. This is not using the normal routing because it is triggered via a menu, so not using grip release buttons. My blueprint calls CallCorrectDropSingleEvent and passes in the controller and grip parameters. It works on the client as expected and it works in stand-alone as expected, but the listen server doesn’t work.

I can see in the c++ code where it is failing, but having a hard time resolving the issue. The GripMotionControllerComponent: DropActor call is returning false after outputting the log message “VRGripMotionController drop function was called on the client side with a replicated grip”. I checked the condition that results in that message and found that my listen server is being detected as NM_Client. I don’t see how this is possible SinceTryDropSingle is a server RPC and the listen server execution path does indeed call through SinceTryDropSingle when debugging. There is no RPC to client after that, at least not that I can see.

To clarify, I’m not saying that I can’t drop gripped objects using the motion controller buttons. It is only when I call the CallCorrectDropSingleEvent from my own function that I run into problems.

What am I doing wrong?

Message me your discord tag

You totally sure that its not calling “TryDropSingleClient”? Server should never detect as a client

I can debug this easier when you enter discord after pming me your tag. Easier to share SS’s, i’ll check tomorrow for your message I am out
tonight with a severe cold.

My problem was in the implementation of a UI component. I had to go over with a fine tooth comb the various places where I’m spawning a UI actor and make sure the UI’s owner was set to the correct player. Somehow the UI was pointed to the remote other player instead of the local listen server player. Anyways, thanks for the response.

Have some update notes coming out this week of various bug fixes and additions, been really sick again (nasty winter) so haven’t been able to push any major lately.

Been planning out some possibly architectural changes for the backend though, should be pretty good stuff if I work out a viable method of shoehorning them in to the ECS of UE4.

I’ve got kind of a problem: when I package the template project (or use the last packaged version that you posted here in this topic) the starting direction of the pawn is different from the “player start” direction (it points towards my actual “forward direction” that I set during the setup of the Vive), and I can’t understand why. Any ideas?

EDIT: maybe I was a bit confusing. Basically, when I play in VR preview and I look towards my default “forward direction”, it points towards the direction the “player start” actor is facing.

If I play the packaged version and I look towards my default “forward direction”, it actually points in the opposite direction with respect of the “player start” actor.

EDIT 2: Also, in a packaged game, when a user joins a session he actually has the same orientation as the “player start”…

EDIT 3: Actually, it happens even in editor without using VR: if I rotate the “player start” and play with a server + client, the server will point towards the “player start”, while the client will always have the rotation vector equal to 0

I need to add a delay to the client spawn to wait for their tracking information to be correct, just haven’t bothered with it yet. Initially on launch it can be early enough that the game doesn’t have a valid HMD location/rotation so it doesn’t spawn them with the correct rotation offset.

It doesn’t have to do with your calibration direction though, the pawn spawns with a zero transform which is world X forward.

You can go into the player controller and see where it spawns the pawn and modify behavior there, that is just a template setup so that 2D pawns can be used for testing.

Got it, thanks a lot!

Hello, can you help me? I followed official manual and added plugin to my project. After restart (both plugins are enabled) i see only C++ files. How can i get blueprints like people in this thread? Did I missed something?

The template has a bunch of the plugin implemented as examples, if you don’t want to reference the template though you can just create blueprints with those c++ classes as their parents (or in grippable component cases, just add them to an actor).

How can I detect/request if an actor is grabbed?