follow sprite behaviour looks broken in 0.14.45 and absence of unfollow block

[kevinjwalters]

Describe the bug
The follow sprite behaviour for following a sprite which has an acceleration value set looks broken in the current beta beta, 0.14.45 / 5.30.6.

I have some code which accelerates one sprite with positive ay until it hits edge of screen. A second sprite later is set to follow that sprite and there's a very obvious difference between the reasonable 0.14.9 behaviour vs the peculiar 0.14.45. The latter initially follows the sprite only in the y direction but then when the followed sprite is very close it changes its mind and starts following it!

To Reproduce
Steps to reproduce the behavior (easier to just use my demo code unless there's need to investigate other permutations of this phenomena):

1. Set a sprite with positive ax and set it to stay on screen.
2. After it's hit edge of screen set the now stationary sprite to follow another one that's moving around the screen.
3. Observe any differences between 0.14.9 and 0.14.45

Expected behavior
The 0.14.9 behaviour looks reasonable from my demonstration code below. The 0.14.45 behaviour is bizarre and cannot be justified.

One open question is what is the intended behaviour for sprite1 if sprite1 has an acceleration set and then it is set to follow another sprite, sprite2.

A second question is what happens if that follow is removed on sprite1, i.e. does the acceleration take effect again. Actually I don't see a block that would explicitly remove a follow, how is this achieveable using a block?

The answers to these should be added to the follow sprite documentation - there is currently nothing about follow https://arcade.makecode.com/reference/sprites. The mouseover for the follow block doesn't explain this but that's probably intended to be concise?

Screenshots
The pink duck is followed by yellow and green after 12 seconds.

0.14.9

0.14.45

Desktop (please complete the following information):

• OS: Windows
• Browser: Same behaviour in both Chrome and Firefox

Smartphone (please complete the following information):

• n/a

Additional context
Here's the code for above:

[jwunderl]

You can make a sprite 'unfollow' by setting speed to 0, similar to the behavior of the move sprite with buttons block.

re: main problem, the follow follow keeps momentum by adjusting the speed rather than explicitly setting it; in this case the acceleration you set is just enough that the default turnRate isn't fast enough for it to counteract the acceleration. an acceleration of 40 blocking it is pretty low though; I'll make it get up to max speed faster by default, as it's not adjustable in blocks and 1 second to turn around is a pretty long time now that I think of it :)

If you want to see the change in behavior, switch your snippet to javascript and add in 400 as the third parameter for the follow block (it's current default is 100, so that will make it turn around 4 times as fast). microsoft/pxt-common-packages#1022

[kevinjwalters]

For the set speed to 0 thing, can that be added to the docs? Does that remove the feature entirely from the processing, i.e. is there any net overhead from setting a follow and then setting it to 0?

[kevinjwalters]

Also, why does the cyan duck not get destroyed when it hits the wall? The edge of the screen is considered a wall for bounce on wall but not for destroy on wall. Mentioned in https://forum.makecode.com/t/inconsistent-sprite-behaviour-with-on-wall-settings/832/2. Should I make a separate ticket for this?

[jwunderl]

Theres a tiny bit of overhead in that it will spin up a fiber for updating any existing follow blocks, that will check check each frame if any exist, apply no updates besides internal state, and continue - you can see the implementation in the function here: https://github.com/microsoft/pxt-common-packages/pull/1022/files the first time follow is called it will start up a 'follow update loop'. There would be no additional overhead for a second / more sprite that follows though.

Re: updating docs, would be good to include, I'm heading out on a flight for the week on a family vacation without wifi so someone else would have to, or I can add it when I get back :)

[jwunderl]

cyan duck - AutoDestroy is a property for destroying when they move off the visible screen already, so I didn't feel like it needed to specially handle the no-tilemap case like bounceonwall does; I can definitely see how that can be confusing, though, and it's little cost to keep consistent, so feel free to file another issue on that ~