VR Expansion Plugin

[KevODoom]

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

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!

[mordentral]

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

[FrancescoDeso]

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

[mordentral]

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.

[KevODoom]

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.

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!

[FrancescoDeso]

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.

Good to know!

By "physics grips" you mean like the "manipulation grip" type?

[mordentral]

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.

[FrancescoDeso]

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!

[Rogue Programmer]

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

[Rogue Programmer]

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?

[mordentral]

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

Message me your discord tag

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?

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.

[Rogue Programmer]

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.

[mordentral]

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.

[FrancescoDeso]

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

[mordentral]

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.