Changing animation by updating angle between objects

0 favourites
  • 10 posts
From the Asset Store
Simplistic hyper-casual game with nature elements. Tap to switch between the 4 elements and reach a better score.
  • .CAPX:

    With the use of the mouse object, I'm using angle(F89.X, F89.Y-30, Reticule.X, Reticule.Y) and it's always-updating angle in order to set the proper animation for the gun-toting Foxtrot-89 character.

    There are 8 facing directions (360* / 8 directions = 45*).

    I discovered that when testing for angle ranges (ie: 22.5* to 67.5*), that any angle above F89 is counted as a negative value. So it ranges from 0 to 180 or 0 to -180.

    Every angle test works (animations are updated correctly) EXCEPT for the transition from the top-left (-112.5* to -157.5*) to neutral-left (-157.5* to -180*).

    In my capx file, at event lines 19 and 20, you'll see I had to use the two lines to test for the full 45* because of the horizontal divide from the negative to positive value angles. Once I move the angle to 157.5* to 180* (positive values, or down-left facing), the proper animation (neutral-left) goes into effect, but it's not taking into account the full 45* range. When transitioning from an up or down right-facing angle to facing neutral-right, there's no problem. ONLY when moving from up-left to neutral-left.

    Can someone help me see what I am missing, please? Thanks!

  • If you want to make the angles positive, you can use this :


    Then it might be easier to check the angles.

    I tried changing your conditions, and I was able to fix your issue by using that.

  • Thank you, For clarification, where would I place that, exactly?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • It just makes sure an angle is positive if it is negative, so you'd use it wherever you get the angle using angle().

    You can use it when you set your AimingAngle, so that the AimingAngle is always positive.

  • Oh okay. Thought that was it. Thanks again! God bless you, sir!!!

  • I spoke too soon. I still couldn't get it to work and I tried a few different implementations of your advice.

    Could you send me a copy of your edit so I can see how you did it, please?

  • Ashley, if you have a spare moment, could I get your input, too, please?

    Namely, some deeper understanding of why the return value for the angle( ) is giving negative numbers. I'm afraid I'm at a loss for why that is. Thank you, sir!

  • It shouldn't matter that angle() returns something like -90 instead of 270. If your math correctly takes in to account the cyclical nature of rotation, they are identical. Usually people get this wrong because they treat angles as linear numbers, e.g. trying to use lerp between angles, where lerping 50% of the way from 30 to 350 degrees will go the long way round to 190 degrees instead of the shorter way round to 10 degrees. In other words, the normal lerp expression doesn't take in to account angles wrap back around. (This is why the anglelerp expression exists - it uses different math to solve this problem.)

    While solutions using things like (x + 360) % 360 can work for some cases, that does not usually solve wrapping problems, since it's still linear math.

  • Thank you both.

    In this case, Ashley, the angle is updated based on the angle because the character and the mouse object - no lerping (but I do believe I understand what you're saying). It's strictly that one condition that goes from testing between -112.5 & -157.5 to -180 & -157.5. It's that crossing the -157.5 line that the system doesn't get.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)