Now, I know it's rejected unlikely for a

point towards x: () y: () :: motion 

block to exist, but what if we turned it into a reporter block, a much more versatile block.

direction to x: () y: () :: sensing reporter

Now you could use this in more settings. Of course you could always use it in its original setting.

point in direction (direction to x: () y: () :: sensing reporter

Now that sounds a bit more versatile, eh?
But there's more! You're probably like "@gosoccerboy5 ur crazy because this is already rejected suggested and bla bla", but I have further ideas..

[direction v] to x: () y: () :: sensing reporter
[distance v] to x: () y: () :: sensing reporter

With this one block you can do all sorts of things. Maybe this will help the ST rethink their decisions.
Please give your opinions to make Scratch a better place!!

Now to debunk the counter arguments:

“Easy workaround, no support”
Yes, but this “easy workaround” could involve an extra variable or sprite. Even if you decide to use a custom block, guess what we wouldn't need these except we don't have custom reporters. Also, some Scratchers might not know how to do this. It involves a bit of maths.

“Too complex”
You could apply that logic to the sin/cos/tan block, too, but we still have those.

“We don't need this”
Maybe you've never done some sort of game that required these? I'm sure everyone who actually uses Scratch to code has felt a need for one of these every once in a while. I had to do a lot of dumb workarounds in this project.

Any more fuzzy arguments? Post them down there! (Lol I do not mean any offense to anyone who thinks differently from me)

Does anyone want to… do anything?

bump
Sorry, you have to wait 60 seconds between posts.

here's a bump

bump

bump

Now that I think it over, what if we expanded to a

[distance v] from x1: () y1: () x2: () y2: () :: sensing reporter
[direction v] from x1: () y1: () x2: () y2: () :: sensing reporter

That'd be cool and more versatile but probably harder to pick up and it looks like a pretty bloated block anyways.

Totally not replacing my old redundant bump with a more constructive post.

A point towards x/y block isn't rejected; a pointing towards sprite? boolean is.
You might as well use the duplicate.

This is slightly different in that
a. it's a reporter block which is slightly more versatile
b. it also includes the distance to a certain point

I'll leave it to ST members to close if if they feel like it, sorry

blip blop bump

jeez yet another bump that i made a long time ago

bring up my post

In my opinion this block is more compact and versatile than the

point towards x: () y: () :: motion

block because it not only allows for you to point towards a certain point, but also allows you to read the direction without having to point there. You can also read the distance to the point, which can be useful for projects that use circles or triangles or whatever.


Edit: sorry I bumped so much back then, I've learned from my mistakes

(how have I not supported on this yet)


lots of support!
I would use it a lot, too many reasons to type in this post.

That is an amazing idea!

Lemonadeinsummer wrote:

That is an amazing idea!

Why? I want to know

sathvikrias wrote:

(how have I not supported on this yet)


lots of support!
I would use it a lot, too many reasons to type in this post.

Go ahead, the character limit is 200, 000. Don't be afraid to be constructive!

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

is point towards (x) (y) workaround

portalpower wrote:

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

is point towards (x) (y) workaround

I know that, and I have it backpacked, but… like seriously. That workaround tho.

Support! This is a clever way of workarounding the point to x y block and for avoiding a dupe. And I'm working on a game that can benefit from this.
But there is a very easy workaround for this kinda stuff that everyone can understand, This:

(([atan v] of (((x) - (x position)) / ((y) - (y position)))) + ((180) * <((y) - (y position))<  [0]>

As you can see, it's very simple and practical.

Support, this is much more versatile. While we're at it we should have

(distance to [Sprite1 v])

changed to

([distance v] to [Sprite1 v] :: sensing)

with “direction” being a new option.

Edit: Ayy, king of the page!