Announcement

Collapse
No announcement yet.

Rotation Overlap Event Not Working

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

    Rotation Overlap Event Not Working

    I'm trying to get a record to start spinning when I go over trigger. Can someone help me with this as this isn't working.

    #2
    What exactly does "isn't working" mean? It should rotate slightly, once, based on the code you've provided.

    Comment


      #3
      When I walk in the trigger it doesn’t trigger the record to spin. Nothing happens,

      Comment


        #4
        I can see in the blueprint that the overlap event triggers when I walk through the trigger box, but it doesn’t make the record spin. If I add an event tick instead of a begin overlap it will spin fine, but I want to trigger this via the trigger box

        Comment


          #5
          I would dare say it is moving, but extremely slightly. Pay close attention to your situation: tick spins it, onBeginOverlap doesn't seem to. Tick is fired every frame. onBeginOverlap is fired once. Whatever your speed variable is set to, must be a fairly low number for tick to have worked well without spinning it incredibly fast. Whatever that very low number is, you're adding z-rotation to the record once in your onBeginOverlap. It's not continuous -- that event is fired only upon first overlapping.

          You need onBeginOverlap to set a variable that the record should spin (ie. boolean "shouldSpin" = true), and onEndOverlap to set it so the record should not spin (ie. boolean "shouldSpin" = false). Then, spin it in tick so long as that variable is true (ie, branch on "shouldSpin", fire the spin logic off the "true" pin). Also, I wouldn't use a hard set "speed" variable for the z rotation. This will mean lower framerates see it spin slowly, higher framerates spin it faster. Set the number of revolutions you want the record to make per second, multiply that by the frame delta (delta float input from tick), and that's the value you should rotate it by. That'll consistently give you x revolutions per second regardless of client frame rate.
          Last edited by One Mode Only; 03-16-2019, 10:21 AM.

          Comment


            #6
            Thanks One Mode Only. Yes I do want it to spin continuously without stopping when i go over the trigger. So this ^ is what I would do in order to accomplish that?

            Comment


              #7
              Thanks that worked!!

              Comment


                #8
                Awesome! I'm glad you got it figured out

                I would like to reiterate that with your present solution, it will spin based on framerate. If you limit your framerate to 20 for example, you'll see it spin much more slowly than if your framerate is uncapped. For a consistent spin, you'll need to take your delta into consideration. Some easy math would be treating your "speed" variable as the amount of revolutions per second you'd like to achieve. Then, applying delta. Example: speed * 360 * delta. That would mean you'd rotate the record speed times per second. Forgive me if I explain something you already know, but delta is the amount of time which has passed between each tick. This number is essential to consistency in any on-tick operations, allowing you to provide a solid experience for end-users which does not require a locked framerate.

                It may be of no concern to you, which is totally understandable. I thought I'd bring it up again just in case, and hopefully help anyone hitting this page in the future via searches. When we begin to work on traps or similar mechanics which may rotate to provide challenges to our players, it's imperative that the challenge is not greater for those who run at 144hz/fps as opposed to those who run at 30. In a more pessimistic paradigm, this also prevents players from limiting their framerate to a low number to bypass challenges more easily.

                Judging by your use-case, it doesn't appear that a record's rotation rate would fall within this category. I'm assuming it'll only provide some visual ambience, but even then consistency is great.

                Another point of interest may be that in lower framerates, the rotation will be "choppy" when taking delta into consideration. To alleviate this, an rInterp will resolve this issue by providing a smooth rotation at greater disparity between target rotation value and current rotation. Combining the delta-based rotation with a rotation interpolation will help ensure (though, no guarantees once we dip too low in frames) that the record plays smoothly, at the same rate, no matter the framerate. Food for thought
                Last edited by One Mode Only; 03-18-2019, 12:08 PM.

                Comment


                  #9
                  Just to add, when One Mode Only says "delta" that means the green wire coming out of event tick node or the "get world delta seconds" node (they are the same).

                  Comment


                    #10
                    Originally posted by NotSoAccurateNo1 View Post
                    Just to add, when One Mode Only says "delta" that means the green wire coming out of event tick node or the "get world delta seconds" node (they are the same).
                    Great point, thanks for filling in the gaps!

                    One more point I forgot to mention, for anyone who is troubleshooting issues like this. When stuck, throw in a bunch of Print String nodes. To troubleshoot this in particular, I'd throw in a print to ensure that the overlap event was indeed firing off (just a simple "hello" in the onBeginOverlap). As silly as that sounds, it's super easy to have custom collision profiles in place and totally space the fact that your collision object may not ever detect an overlap with whatever actor you're working with. Then, if it was printing, I'd print the rotation of the object before and after the rotation. When the print only fired once, it'd be an instant lightbulb moment where I saw that small rotation happen only once. Software Engineering is often one part writing code, and three parts troubleshooting (in my experience). It's rare that something works exactly as intended right from the first attempt (but those moments are glorious). More often, I get the general concept down, and iterate over it as I realize the little things I didn't account for. Getting into the troubleshooting paradigm will save you from lots of frustration and headache down the road. Logs are truly a dev's best friend, and utilizing them will step up your game tremendously.

                    Comment

                    Working...
                    X