Code reverses what it does

Unity Engine
,
1

Fix: Cameron_SM’s solution worked.
Updated code:

    void OpenAndCloseShop()
    {
        if (!inShop)
        {
            shopTween.Kill();

            shopTween = shopPos.DOMoveY(shopEndPos, 2).SetEase(Ease.OutBounce);

            inShop = true;

            return;
        }

        else
        {
            shopTween.Kill();

            shopTween = shopPos.DOMoveY(shopStartPos, 4).SetEase(Ease.OutExpo);

            inShop = false;

            return;
        }
    }

Old code:

    void OpenAndCloseShop()
    {
        if (!inShop)
        {
            shopPos.DOMoveY(shopEndPos, 2).SetEase(Ease.OutBounce);

            inShop = true;
        }

        else
        {
            shopPos.DOMoveY(shopStartPos, 4).SetEase(Ease.OutExpo);

            inShop = false;
        }
    }

This code works, at first, but after I call the function a second time, the thing I’m moving goes down like normal, but once it finishes it moves way up. I added debug statements to the conditional statements and only one gets activated each time you click it, so it’s not that the else statement is activating after the if statement which would reverse it. Plus the position the shop goes to is way higher then the shops start position. And I don’t think the tween is reversing itself because (correct me if I’m wrong) I’m pretty sure that you have to manually turn on that setting.

2

Haven’t used this tween package. Are you sure it doesn’t just add a second tween on top of the first? That’s the first place I’d investigate, starting with the API for this tween package.

3

Looks like DoTween. You probably want to keep a reference to the current tween. A tweener should be returned form the call DoMoveY.

tweener = shopPos.DoMoveY

And then call kill on that tweener before starting a new tween. This is because your internal state changes instantly (inShop = true/false) but the visual state takes 2 or 4 seconds to change.

It’s also not apparent how/what is consuming OpenAndCloseShop(). If that gets called twice within 2 or 4 seconds (depending on it’s current state) you’re going to have two tweens running at once which can cause unpredictable results.

1 Like
4

The key takeaway here is that, contrary to your line of thinking, the execution doesn’t pause in DoMove line, it instead triggers (commences) the tween at that moment in time, and immediately changes inShop state. Then the animation plays afterwards, but the state is wrong, so it switches to another animation which probably resets this one, and so on…

This switching happens only when you call OpenAndCloseShop. Thus likely on user input. The error would be easier to notice if it was in Update, as animations would cancel each other in quick succession, and nothing would happen at all, indicative of a faulty state machine.

5

I’m having trouble making any sense of that. Your summary makes a lot of assumptions and I think just confuses the issue at hand.

The code doesn’t seem to indicate any kind of assumption that execution is suspended.

The state change and the side-effect of starting a tween animation are effectively encapsulated in the logic branch of the if/else statement, after which execution exits the method.

The state is never wrong - and it changing instantly when invoking the method is totally fine.

  • The issue is that the side effects of this method introduce some temporary state that exists for up to 4 seconds.
  • The temporary state is that of the tween the method starts in either logic branch that persists for 2 or 4 seconds.
  • If this temporary state is not managed correctly it is possible to end up with multiple overlapping tweens trying to animate the same object (when OpenAndCloseShop is called twice within 2 to 4 seconds) hence the unexpected behaviour.
  • Managing the state of the tween started previously by killing it before before starting a new one should resolve any issues.

I’m not sure what the Update loop or state machines have to do with this at all.

6

Not sure if you’re supposed to be arguing with me, as I haven’t said anything contrary to your observation. I never said that the execution suspends, I said it doesn’t suspend contrary to what OP believed should be happening.

You see, the errors stems from the issue that the OP wrongly believed that the tween call would synchronously do its job, finalize it, then return to the proper execution sequence.

This is what I perceive the OP was having trouble with and where my post comes from. This is what I read from his post. You and me are well past such naive expectations that tweens work synchronously, and I believe you’re mentally stuck in how to parse my comment and so you miscategorized it as critique to your post.

Nah, I wasn’t replying to you at all. Maybe I should’ve quoted OP to make this more clear.

Not sure if I understand this. Yes the state is wrong compared to what OP desired, as it was made wrong inadvertently. If it weren’t wrong, OP wouldn’t ask for help.

Just cool down a bit, and take a good look at what I said.