Announcement

Collapse
No announcement yet.

VR Expansion Plugin

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by mordentral View Post

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

    Code:
    // 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!

    Comment


      Originally posted by KevODoom View Post

      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.


      Consider supporting me on patreon

      My Open source tools and plugins
      Advanced Sessions Plugin
      VR Expansion Plugin

      Comment


        Originally posted by mordentral View Post

        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!

        Comment


          Originally posted by Beriol View Post

          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.


          Consider supporting me on patreon

          My Open source tools and plugins
          Advanced Sessions Plugin
          VR Expansion Plugin

          Comment


            Originally posted by mordentral View Post

            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!

            Comment


              Originally posted by mordentral View Post

              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?

              Comment


                Originally posted by Beriol View Post

                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.


                Consider supporting me on patreon

                My Open source tools and plugins
                Advanced Sessions Plugin
                VR Expansion Plugin

                Comment


                  Originally posted by mordentral View Post

                  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!

                  Comment


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

                    Comment


                      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?
                      Attached Files
                      Last edited by Modeus Games; 03-05-2018, 05:58 PM.

                      Comment




                        Originally posted by AlfornoOne View Post
                        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

                        Originally posted by AlfornoOne View Post
                        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.


                        Consider supporting me on patreon

                        My Open source tools and plugins
                        Advanced Sessions Plugin
                        VR Expansion Plugin

                        Comment


                          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.

                          Comment


                            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.
                            Last edited by mordentral; 03-11-2018, 02:00 PM.


                            Consider supporting me on patreon

                            My Open source tools and plugins
                            Advanced Sessions Plugin
                            VR Expansion Plugin

                            Comment


                              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
                              Last edited by Beriol; 03-12-2018, 07:26 AM.

                              Comment


                                Originally posted by Beriol View Post
                                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.


                                Consider supporting me on patreon

                                My Open source tools and plugins
                                Advanced Sessions Plugin
                                VR Expansion Plugin

                                Comment

                                Working...
                                X