a [point towards x( ) y( ) block

medians

firaas1234 wrote:

when green flag clicked
when green flag clicked[quote][quote][quote][/quote][/quote][/quote]

firaas1234 wrote:

turn cw () degrees
when green flag clicked[quote][quote][quote][quote][quote][/quote][/quote][/quote][/quote][/quote]

Please don’t block spam.

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

Workaround:

woopaer wrote:

define point towards x: (x) y: (y)
set [xPos v] to (x)
set [yPos v] to (y)
broadcast [moveSprite v]
point towards [blankSprite v]

now, make a blank sprite without changing the costume

when I receive [moveSprite v] //put in the blank sprite
go to x: (xPos) y: (yPos)

medians

when green flag clicked
set [page v] to [front]

when green flag clicked
forever
if <(page) = [front]> then
set [page v] to [1]
end
end

mumu245

Support. The posts in my dupe:

mumu245 wrote:
I suggest a block that points the sprite towards a position on the stage.
point towards x: () y: () ::motion
I know of the workaround involving blank sprites, but it's too messy. Also, sometimes you need to use dynamic positions.
I also know of the other workaround, but it's very complex and just because there is a workaround, it dosen't mean it should not be added.

chowder_fish wrote:
I reckon there's just not much need for it. And yes, the workarounds are sometimes annoying, but it's not very hard to make a blank sprite, set it up to go to a position and then have the original sprite point towards the second one. Even if there is a specific case, you could make a custom block:
define go to (x) (y)

mumu245 wrote:
chowder_fish wrote:
I reckon there's just not much need for it. And yes, the workarounds are sometimes annoying, but it's not very hard to make a blank sprite, set it up to go to a position and then have the original sprite point towards the second one. Even if there is a specific case, you could make a custom block:
define go to (x) (y)
Fine but I think it's much needed.

ColourfulPixels wrote:
Sorry, no support. I know that it's not always right to not support a suggestion because there is a workaround, this this one can be easily implemented:
define point towards x: (x) y: (y)
point in direction (([atan v] of (((x) - (x position)) / ((y) - (y position)))) + (<(y position) > (y)> * (180)))

mumu245 wrote:
ColourfulPixels wrote:
Sorry, no support. I know that it's not always right to not support a suggestion because there is a workaround, this this one can be easily implemented:
define point towards x: (x) y: (y)
point in direction (([atan v] of (((x) - (x position)) / ((y) - (y position)))) + (<(y position) > (y)> * (180)))
And it's a compilcated math formula.

Wei-ern_520 wrote:
But http://scratch.mit.edu.ezproxyberklee.flo.org/discuss/topic/8101

dave-alt-4

bruh why are people saying no support cuz workaround , not everyone knows trigometry and using a hidden sprite would have a 0.06 sec delay

anyways , support as not everyone knows trigometry , using a hidden sprite would have a 0.06 sec delay and would make it laggier for big projects and potato devices , sometimes clones hit the 300 limit also.

medians

dave-alt-4 wrote:
bruh why are people saying no support cuz workaround , not everyone knows trigometry and using a hidden sprite would have a 0.06 sec delay

anyways , support as not everyone knows trigometry , using a hidden sprite would have a 0.06 sec delay and would make it laggier for big projects and potato devices , sometimes clones hit the 300 limit also.

If it's a potato device, it most likely won't run due to lack of ram, and most likely will just show a blue screen. YOU DON'T NEED CLONES, it goes to the coordinate so you don't generate clones. 0.06 sec delay isn't a lot and you can get used to it really easily.

SomeoneOnThelnternet

Workaround:

define point towards (x) (y)
set [pointx v] to (x)
set [pointy v] to (y)
broadcast [point v]
point towards [Sprite v]

Then on the other sprite:

when I receive [point v]
go to x: (pointx) y: (pointy)

So, no support.

Last edited by SomeoneOnThelnternet (Jan. 27, 2022 16:47:38)

AwezomeXD

SomeoneOnThelnternet wrote:
Workaround:
define point towards (x) (y)
set [pointx v] to (x)
set [pointy v] to (y)
broadcast [point v]
point towards [Sprite v]
Then on the other sprite:
when I receive [point v]
go to x: (pointx) y: (pointy)
So, no support.

If you read the posts above you, you'd realize that that solution would cause some minor lag in projects (which by itself isn't alot, but for complex projects lag can really add up)

Jackson49_test

Bump

Michael10167

You can just have a sprite go to a curtain coordinate, and have another sprite point to that. You can also have it when you want that sprite to sometimes point to something else, you can have a block that is like this:

go to x: (0) y: (0)
point towards [Sprite2 v]
point in direction ([Direction v] of [Sprite1 v])

Last edited by Michael10167 (April 5, 2022 21:46:49)

historical_supa

Would be useful since the workaround needs like a million sprites.

k0d3rrr

historical_supa wrote:
Would be useful since the workaround needs like a million sprites.

Or to simplify that workaround, two sprites and two scripts.

Sprite1:

when gf clicked
go to x: (X) y: (Y)

Sprite2:

when gf clicked
forever
point towards [Sprite1 v]
end

But this is still a great idea. I'm not saying this idea is bad, nor am I saying “no support”, but I'm saying the current workaround is the one provided above.

CYTOTOXIC_1

Support!!!!!!!!!!

the workaround is complicated, scratch is supposed to be a beginners website where people can learn the basics of code, not where you need to be some genius with trigonometry.

CYTOTOXIC_1

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?

you call that easy? for people who are new that's just not really feasible, you can make entire projects with half the code

-An_Unnamed_User-

25% support. There's a workaround:

when green flag clicked
broadcast [point towards v]
point towards [Sprite 2 v] :: motion

Put this on Sprite1.

when I receive [point towards v]
go to x: () y: () :: motion

Put this on Sprite2.

Last edited by -An_Unnamed_User- (Aug. 18, 2022 09:03:35)

gdfsgdfsgdfg

Guys, stop saying no support just because of a stupid trigonometry workaround!

if people don’t know trigonometry then its hard now go Read my post and Others peoples post!

anyways no support because of ambiguity

Last edited by gdfsgdfsgdfg (Feb. 12, 2023 14:02:19)

medians

gdfsgdfsgdfg wrote:
Guys, stop saying no support just because of a stupid trigonometry workaround!

if people don’t know trigonometry then its hard now go Read my post and Others peoples post!

Well, if you know trig it logically makes sense.
Though there's another workaround that makes more sense if you don't:

(30, 45):

You have to run it twice to make sure it works:

Last edited by medians (Feb. 12, 2023 14:07:41)

gdfsgdfsgdfg

medians wrote:
gdfsgdfsgdfg wrote:
Guys, stop saying no support just because of a stupid trigonometry workaround!

if people don’t know trigonometry then its hard now go Read my post and Others peoples post!
-Quote so big that I had to cut it-

I already saw that workaround

this is not practical too because it’s going to be infinite sprites on a very big project just for something

Last edited by gdfsgdfsgdfg (Feb. 12, 2023 14:09:28)

medians

gdfsgdfsgdfg wrote:
I already saw that workaround

this is not practical too because it’s going to be infinite sprites on a very big project just for something

…It's one sprite.

gdfsgdfsgdfg

medians wrote:
gdfsgdfsgdfg wrote:
I already saw that workaround

this is not practical too because it’s going to be infinite sprites on a very big project just for something
…It's one sprite.

yes but you use the second sprite for the main one

which can clutter the sprites area

medians

gdfsgdfsgdfg wrote:
medians wrote:
gdfsgdfsgdfg wrote:
I already saw that workaround

this is not practical too because it’s going to be infinite sprites on a very big project just for something
…It's one sprite.

yes but you use the second sprite for the main one

which can clutter the sprites area

Uhm, what?
Let me guess, this is something to do with everything being made 1000x huge?
Also bringing this up

Discuss Scratch