For my tower defense game I think this will help. It might be useful for other things too!

(distance to x:() y:()::sensing)

Tell me if you support!

Also if there is any way to get around this please tell me.

Support, the workaround is very long:

([sqrt v] of ((((x :: grey) - (x position)) * ((x :: grey) - (x position))) + (((y :: grey) - (y position)) * ((y :: grey) - (y position))))

Support

stickfiregames wrote:

Support, the workaround is very long:

([sqrt v] of ((((x :: grey) - (x position)) * ((x :: grey) - (x position))) + (((y :: grey) - (y position)) * ((y :: grey) - (y position))))

Support, but for an alternate workaround couldn't you just have a hidden sprite at the location you want to find the distance from, then use the "distance to " block?

zacadoole1 wrote:

stickfiregames wrote:

Support, the workaround is very long:

([sqrt v] of ((((x :: grey) - (x position)) * ((x :: grey) - (x position))) + (((y :: grey) - (y position)) * ((y :: grey) - (y position))))

Support, but for an alternate workaround couldn't you just have a hidden sprite at the location you want to find the distance from, then use the "distance to " block?

You could, but then of course you need another sprite and have to use broadcasts.

stickfiregames wrote:

zacadoole1 wrote:

stickfiregames wrote:

Support, the workaround is very long:

([sqrt v] of ((((x :: grey) - (x position)) * ((x :: grey) - (x position))) + (((y :: grey) - (y position)) * ((y :: grey) - (y position))))

Support, but for an alternate workaround couldn't you just have a hidden sprite at the location you want to find the distance from, then use the "distance to " block?

You could, but then of course you need another sprite and have to use broadcasts.

Yeah, but it's easier for me to remember than all those math blocks!

zacadoole1 wrote:

stickfiregames wrote:

zacadoole1 wrote:

stickfiregames wrote:

Support, the workaround is very long:

([sqrt v] of ((((x :: grey) - (x position)) * ((x :: grey) - (x position))) + (((y :: grey) - (y position)) * ((y :: grey) - (y position))))

Support, but for an alternate workaround couldn't you just have a hidden sprite at the location you want to find the distance from, then use the "distance to " block?

You could, but then of course you need another sprite and have to use broadcasts.

Yeah, but it's easier for me to remember than all those math blocks!

Easy to remember if you know how it works.

lol the block's going out of the quote section

Prinseskat wrote:

zacadoole1 wrote:

stickfiregames wrote:

zacadoole1 wrote:

stickfiregames wrote:

Support, the workaround is very long:

([sqrt v] of ((((x :: grey) - (x position)) * ((x :: grey) - (x position))) + (((y :: grey) - (y position)) * ((y :: grey) - (y position))))

Support, but for an alternate workaround couldn't you just have a hidden sprite at the location you want to find the distance from, then use the "distance to " block?

You could, but then of course you need another sprite and have to use broadcasts.

Yeah, but it's easier for me to remember than all those math blocks!

Easy to remember if you know how it works.

Oh, I could probably memorize it if I really wanted to, but you know what they say, you can't teach an old dog new tricks!

zacadoole1 wrote:

Prinseskat wrote:

zacadoole1 wrote:

stickfiregames wrote:

zacadoole1 wrote:

stickfiregames wrote:

Support, the workaround is very long:

([sqrt v] of ((((x :: grey) - (x position)) * ((x :: grey) - (x position))) + (((y :: grey) - (y position)) * ((y :: grey) - (y position))))

Support, but for an alternate workaround couldn't you just have a hidden sprite at the location you want to find the distance from, then use the "distance to " block?

You could, but then of course you need another sprite and have to use broadcasts.

Yeah, but it's easier for me to remember than all those math blocks!

Easy to remember if you know how it works.

Oh, I could probably memorize it if I really wanted to, but you know what they say, you can't teach an old dog new tricks!

It would be easier if we had a power block too:

([sqrt v] of ((((x :: grey) - (x position)) ^ (2) :: operators) + (((y :: grey) - (y position)) ^ (2) :: operators))

Still long though.

stickfiregames wrote:

Support, the workaround is very long:

([sqrt v] of ((((x :: grey) - (x position)) * ((x :: grey) - (x position))) + (((y :: grey) - (y position)) * ((y :: grey) - (y position))))

Yes I used this for a project this would really help!

Support. This would help new scratchers who don't want to use the “complicated” workaround.

This needs the formula:
SQRT of Xposition of one sprite - X position of other sprite * Xposition of one sprite - X position of other sprite + yposition of one sprite - y position of other sprite * yposition of one sprite - y position of other sprite
Hope this helped!

I won't support because this workaround is what's used in many other programming languages and it'd probably be a good thing for new Scratchers to learn the maths behind it.

define distance to (x) (y)
set [dx v] to ((x) - (x position))
set [dy v] to ((y) - (y position))
set [distance v] to ([sqrt v] of (((dx) * (dx)) + ((dy) * (dy))))

A nice and neat custom block for you

Sigton

Cub56 wrote:

I won't support because this workaround is what's used in many other programming languages and it'd probably be a good thing for new Scratchers to learn the maths behind it.

So, how do they even know if that script is gonna work? They don't understand how it works, why should we be expecting users to solve complicated problems and they aren't even in high school?

Cub56 wrote:

I won't support because this workaround is what's used in many other programming languages and it'd probably be a good thing for new Scratchers to learn the maths behind it.

I agree, it is a great opportunity to learn the math of distance.

Sigton wrote:

define distance to (x) (y)
set [dx v] to ((x) - (x position))
set [dy v] to ((y) - (y position))
set [distance v] to ([sqrt v] of (((dx) * (dx)) + ((dy) * (dy))))

A nice and neat custom block for you

Sigton

That's excellent.

Another work round

go to x: () y: () // sprite1

(distance to [sprite1 v]) // sprite2

Charles12310 wrote:

So, how do they even know if that script is gonna work?

By testing.

walkcycle wrote:

Cub56 wrote:

I won't support because this workaround is what's used in many other programming languages and it'd probably be a good thing for new Scratchers to learn the maths behind it.

I agree, it is a great opportunity to learn the math of distance.

Sigton wrote:

define distance to (x) (y)
set [dx v] to ((x) - (x position))
set [dy v] to ((y) - (y position))
set [distance v] to ([sqrt v] of (((dx) * (dx)) + ((dy) * (dy))))

A nice and neat custom block for you

Sigton

That's excellent.

Another work round

go to x: () y: () // sprite1

(distance to [sprite1 v]) // sprite2

Charles12310 wrote:

So, how do they even know if that script is gonna work?

By testing.

Yes but that's like saying the workaround is easy. -_-

The workaround is difficult, not everyone knows how it works, and I don't think everyone's gonna remember. I know about square roots but I can't even remember either. It's better to drag one block than to drag so many blocks and type so many stuff and then you realized that you forgot everything.

Charles12310 wrote:

Cub56 wrote:

I won't support because this workaround is what's used in many other programming languages and it'd probably be a good thing for new Scratchers to learn the maths behind it.

So, how do they even know if that script is gonna work? They don't understand how it works, why should we be expecting users to solve complicated problems and they aren't even in high school?

It is only Pythagoras and I learnt it practically at the start of the equivalent of middle school.

Yes, but still you don't understand, the workaround is too long, it takes too much dragging of blocks, it's better to use one block alone. Most people probably aren't in middle school yet!