We need a block that would be in the sensing column called make a <pointing towards (sprite1)?>

When would it report true? If the sprite is pointing towards the center of the sprite or if a line starting from the center of the sprite touches that other sprite? (sorry, but I didn't know how to explain better)

Mockup:

pointing towards [Sprite 1 v]?::boolean sensing

I don't understand?

APS_Ethan wrote:

I don't understand?

I mean, would it report true if the sprite we are controlling is pointing to the center of the other sprite or if it is pointing anywhere towards the sprite?

So why can't we just get a

<pointing towards[ …] ?>

APS_Ethan wrote:

So why can't we just get a

<pointing towards[ …] ?>

Because it's still unclear when it would report true nor false. Could you answer to my question above, please?

When would it be true. For what specific situation would this hypothetical block return as “true”.

findanegg wrote:

When would it be true. For what specific situation would this hypothetical block return as “true”.

agreed. you what if the direction is .00000000001 degrees off? would it still return true? because it is still pointing at it, its just a sliver off.

JackK211424 wrote:

agreed. you what if the direction is .00000000001 degrees off? would it still return true? because it is still pointing at it, its just a sliver off.

Perhaps it'd report true if and only if the sprite's rotation center would eventually enter the other sprite if it kept moving forward?

Why can't we get a

<pointing towards[ sprite1]?>

so why can't we just get a

pointing towards [Sprite 1 v]?::boolean sensing

Support, also, it would detect true if a thin line came out of the center of a sprite and touched another sprite. Like a “line of sight”.

APS_Ethan wrote:

Why can't we get a

<pointing towards[ sprite1]?>

APS_Ethan wrote:

so why can't we just get a

pointing towards [Sprite 1 v]?::boolean sensing

Because, not to be rude, but it's the fourth time someone asks you when would it report true, but you still didn't answer. I'm sorry, but it's not good to make users assume what a block does, you should explain what how would it work.

Botcho_Otkho wrote:

APS_Ethan wrote:

Why can't we get a

<pointing towards[ sprite1]?>

APS_Ethan wrote:

so why can't we just get a

pointing towards [Sprite 1 v]?::boolean sensing

Because, not to be rude, but it's the fourth time someone asks you when would it report true, but you still didn't answer. I'm sorry, but it's not good to make users assume what a block does, you should explain what how would it work.

Did you not read my post from above?

Me from the past wrote:

Support, also, it would detect true if a thin line came out of the center of a sprite and touched another sprite. Like a “line of sight”.

Mr_PenguinAlex wrote:

Did you not read my post from above?

Me from the past wrote:

Support, also, it would detect true if a thin line came out of the center of a sprite and touched another sprite. Like a “line of sight”.

Did the user that wrote this topic tell you about how the block would work? Yours is still an assumption.

we could also do with

 [my variable] go to x:(0) y:(0)

we should also get

 [my variable v], go to x:(0) y:(0)::vaiables

It's not clear to me exactly how this would be used - or what it really means. I think the definition might depend on the application - which means it probably should be left to the programmer to implement.

I have done something similar as to what I imagine the proposed block would do by using a 100% ghosted sprite with a costume consisting of a long line. By positioning the ghosted sprite on another sprite and orienting it in the same direction, I could then query the ghosted sprite to see if it was touching a second target sprite. By varying the thickness of the line costume (or using a triangle), I could control the “accuracy” of operation to fit my application.

Because of the fairly simple workaround - and the lack of definition of exactly how such a block would be used, I believe this suggestion is rejected at this time. Thanks for taking the time to propose it, though, and keep thinking of ways to make Scratch better