I think the most compact is probably this:

define point towards (x) (y)
point in direction ( ( [atan v] of ( ( (x) - (x position) ) / ( (y) - (y position) ) ) ) + ( (180) * ( (y position) > (y) ) )

EDIT: I see Zro has already said exactly that a while back…

Zekrom01 wrote:

Aboot4 wrote:

Guys, come on. Here's the easiest way to do it, and do it well, bro:

define Move (Steps) steps towards x: (X) y: (Y)
if <<(Y) > (y position)> or <(Y) = (y position)>> then
    point in direction ([atan v] of (((X) - (x position)) / ((Y) - (y position))))
else
    point in direction ((180) + ([atan v] of (((X) - (x position)) / ((Y) - (y position)))))
end
if <not <<(y position) = (Y)> and <(x position) = (X)>>> then
    move (Steps) steps
end

There are easier ways to do a point towards block.

I posted that back in the day when I was a lot worse than I am now at Scratch xDD

There is no need for trig knowledge, if you want it to be exceptionally nice then yes some trig!

Easily workaroundable, but support anyway.

No support because you can just add this to your backpack:

TheLogFather wrote:

define point towards (x) (y)
point in direction ( ( [atan v] of ( ( (x) - (x position) ) / ( (y) - (y position) ) ) ) + ( (180) * ( (y position) > (y) ) )

That's the whole point of the backpack, to allow you to save little code snippets like this one, and put them in your project when you feel like it.

Support. Gets annoying to use this every time-

define point towards x: (x) y: (y)
if <((y) - (y position)) = [0]> then
   if <((x) - (x position)) < [0]> then
      point in direction (-90 v)
   else
      point in direction (90 v)
   end
else
   if <((y) - (y position)) < [0]> then
      point in direction ((180) + ([atan v] of (((x) - (x position)) / ((y) - (y position))))
   else
      point in direction ([atan v] of (((x) - (x position)) / ((y) - (y position)))

Workaround from Scratch Wiki.

“Easily” workaroundable? Those workarounds don't look easy. Complete support from me; why should pointing toward the mouse-pointer or another sprite be so easy when merely facing a point in space isn't?

Aboot4 wrote:

No support. Easily workaroundable.

define point towards coordinates x: (x) y: (Y)
if <((Y) - (y position)) = [0]> then
    if <(x) < (x position)> then
        point in direction (-90 v)
    else
        point in direction (90 v)
    end
else
    if <((Y) - (y position)) > [0]> then
        point in direction ([atan v] of (((x) - (x position)) / ((Y) - (y position))))
    else
        point in direction (([atan v] of (((x) - (x position)) / ((Y) - (y position)))) - (180))
    end
end

See?

Method 2:

when green flag clicked
point towards [sprite v]

The sprite is blank and is in the wanted direction. That doesn't slow down my projects.

To calculate direction and distance from a point to another

define Direction&distance from x1 (x1) y1 (y1) to x2 (x2) y2 (y2)
set [atan v] to ([atan v] of (((x2::custom) - (x1::custom)) / ((y2::custom) - (y1::custom))))
point in direction ((atan) + ((180) * <(y1::custom) > (y2::custom)>))
set [distance v] to (([abs v] of (((y1::custom) - (y2::custom)) / ([cos v] of (atan)))) + (([abs v] of ((x1::custom) - (x2::custom))) * <(y2::custom) = (y1::custom)>))

Direction&distance from x1 (1) y1 (1) to x2 (1) y2 (1) :: custom

as you can see in direction&distance between 2 points

Support; if we have a “glide” block, why can't we have this (which is much more difficult to program than the glide block)?

Support.

It tends to annoy the heck out of me when I have to do the workaround.

Support. There are 2 ways to workaround: One uses trig, and the other uses an extra sprite.

Using too many extra sprites is inelegant, and you can't expect all beginners to know trig.

If you're going to not support this, you can't support

move () steps

either, becuase that's workaroundable with trig, and the trig workaround with this block is more complicated than move 10 steps is.

DaSpudLord wrote:

No support. Workaroundable. Look them up.

Okay, here is the workaround:

set [Δx v] to (([x position v] of [wanted sprite v]) - (x position))
set [Δy v] to (([y position v] of [wanted sprite v]) - (y position))
if<(Δy) = [0]> then
if<(Δx) < [0]> then
point in direction (-90 v)
else
point in direction (90 v)
end
else
if<(Δy) < [0]> then
point in direction ((180) + ([atan v] of ((Δx) / (Δy))))
else
point in direction ([atan v] of ((Δx) / (Δy)))
end
end

As you can see guys, it is very obvious and intuitive, I can't believe New Scratchers don't use this more often, how silly of them. </sarcasm>

Guys, seriously, simply having a workaround is not a good reason to not support a block.

Change to semi-support.

EDIT: Not because of theonlygusti's post. That was a huge coincidence.

And there is an easier workaround- just use a second sprite.

I'd just like to add that I have severely needed this block on so many occasions, and, put simply, it just doesn't make sense for Scratch to not have this block; they have “if on edge, bounce” for crying out loud!

DaSpudLord wrote:

And there is an easier workaround- just use a second sprite.

If you need to use this workaround, say, 20 times in a project, all with different inputs, would you need 20 different sprites? If not, you would need 2 extra variables and a broadcast instead, to pass over information to the second sprite, so it can move to the right place for you to point towards. How would you deal with race conditions, that is, where 2 sprites want to point in different directions at the same time? That would mess up the extra sprite leading to both pointing towards the same point, not what you want. So you would need an extra sprite, broadcast, and 2 variables, for EVERY sprite you want to use the workaround in. Say you wanted to use it in 5 sprites. You'll need 5 extra sprites, 5 extra broadcasts, and 10 extra variables. And you can't just copy over your custom block to every individual sprite (you ARE using a custom block, right? That's

define point towards x: (x) y: (y)
set [wanted x v] to (x)
set [wanted y v] to (y)
broadcast [point towards v] and wait
point towards [extra sprite v]

if you were wondering), because you'll need to change all the variables and broadcasts and sprite names.


Or you can just use a bit of trigonometry

Or it could be a primitive block

Hah hah, LOL, yeah. I never thought of the other workaround: create 172800 new Sprites and place them at every integer coordinate on the screen. Then just point towards the one you want. LOL so simple.

Semi-support: Although it's workaroundable, the workarounds is kinda clunky.

theonlygusti wrote:

Hah hah, LOL, yeah. I never thought of the other workaround: create 172800 new Sprites and place them at every integer coordinate on the screen. Then just point towards the one you want. LOL so simple.

Pretty sure you can have non-integer coordinates too.