Detecting Redundant Value Changing

[FeralJr (captain)]

Context

I am trying to script a relatively simple animation system where when the player jumps, two things happen:

• A one-frame animation of the character rising up plays (While rising)
• A one-frame animation of the character falling down plays (While falling)

I decided to achieve this by logging the HumanoidRootPart.AssemblyLinearVelocity.Y, which mostly works, however brings up one problem.

---

The Problem

It made sense to me to simply have a function detect when the Y velocity was above 0, and then detect when the Y velocity was below 0. The problem with this is that all of the methods I have attempted to do this with fire for every “number” the velocity goes to.

Example: (The velocity decimal is simplified using math.round()) (Animations not scripted in this gif)

I use terms like “numbers” and “scrolls” for the sake of simplicity

What I’ve done here is using the rounded Y velocity, I use a GetPropertyChangedSignal() on the HumanoidRootPart.AssemblyLinearVelocity.Y to play the rising animation while the Y is above 0, the falling animation while the Y is below 0, and the idle animation when Y is at 0.

However, this causes problems because, as stated before (and as shown in the gif), the animation would play for every “number” the velocity “scrolls” through. With this, the animation would jitter, constantly playing itself, as well as the falling animation. Even being one-frame animations, it still makes it look weird, and causes other problems as well.

(Testing the animations with the script) (Sorry for the quality.)
(Also, the rising and falling text looks like it is only set once, but it is being constantly set.)

The Main Question

Does anyone know a way to check for things that are constantly changing like this only once? To clarify, in this case I want to check if the velocity is above 0 only once, and not for every number it goes past.

If not, do you know any other and/or more efficient ways to accomplish the following?

• Play rising animation when rising
• Play falling animation when falling
• Play idle animation when Y Velocity is 0

(OR A SIMPLE WAY TO ENSURE ONLY ONE ANIMATION CAN PLAY AT A TIME!)

Solutions tried:

• Debounce (tried and failed several times)
• GetPropertyChangedSignal
• GetAttributeChangedSignal
• while true do wait()

If anything is unclear, please let me know, and thank you.

[WrollingYou]

Have you tried using a debounce? You can set the debounce to true when initially playing the animation and false when finished, check if the debounce is set and if so, don’t play the animation.

[FeralJr (captain)]

I have tried this, and I shouldve stated that I did, but this provides nearly the same problem as the one shown in the second gif. I’ve even tried several different systems of debounce

[WrollingYou]

I’d like to see your code with the debounces

[FeralJr (captain)]

Just trust me, debounces wouldn’t solve the problem. The problem comes with an event firing from a rapidly changing signal, which will only cause the events to fire slower and/or incorrectly.

[WrollingYou]

That’s exactly why debounces are a thing though… to prevent execution of code within the function when an event fires several times before it’s actually executed.

[COUNTYL1MITS (wil)]

I suggest checking the current playback status of the animation before initiating it, thereby preventing the animation from restarting unnecessarily.

[FeralJr (captain)]

This is ideal, however how exactly would I do that?

[COUNTYL1MITS (wil)]

Before playing the animation, you may want to verify the AnimationTrack.IsPlaying property. This will help avoid restarting the animation unnecessarily.

[Kitsomia (Mia)]

If you’re using :GetPropertyChangedSignal() or :GetAttributeChangedSignal() you could have done :GetPropertyChangedSignal("AssemblyLinearVelocity"):Once() as it only fires one time. Could reduce potential checks depending on how you use it; pair it up if the velocity doesn’t meet your criteria then create another :Once connection and when it does, hook up an event telling you when the animation finishes.

Although you already found your working solution, just wanted to butt-in that small thing.