ocular rewritten

As I hope several are well aware, the suggestion for a boolean block that detects whether a sprite is pointing towards another sprite is rejected.

Za-Chary wrote:

(#1)
1.3 “Pointing towards sprite” boolean block
This in theory would allow a sprite to detect if it is pointing towards another sprite, but there is ambiguity on how this would work. Would it return true if the sprite is pointing in any general direction towards another sprite, or strictly at the center of that sprite? This depends on your intended function of the block, at which point you may consider implementing your own workaround.

<pointing towards [sprite v]? :: sensing>

However, given the potential of the block, I don't think the idea should be given up. I can think of several use cases in a game I'm working on in which it would help cut down the amount of code use a lot. It'd be such a versatile tool to have.

If you have a look at the above quote from TOLORS, its reason for rejection is the ambiguity of how it would work. So why not have the two different possibilities? Here is my proposed solution:

<[Sprite v] is facing [center v] of [Sprite v]? :: sensing>

Or alternatively:

<[Myself v] is facing [any v] of [Sprite v]? :: sensing>

Note that as opposed to “pointing towards” I opted for “is facing” to shorten the block's length. “Myself” is also an option for it to work with clones.
While some complicated workarounds for the block exist, it's not simple enough to justify throwing out the idea for that alone either. There are several use cases in which it would be very great to have, and there are many cases where the workarounds I can think of wouldn't be very great.

Either way, I think it would be great to once more discuss the possibility of a block like this being added to Scratch.



Edit 1:

Forgot to mention another possibility:

<[Sprite v] is facing [center v] of [Mouse pointer v] ?::sensing>

im confused on how this would work
like lets say this is the screen of the project <> and >< are sprites:

<>

><



as you can see, technically <> will always be facing >< because as long as its showing, to the thing that detects it, itll always think its facing it, right?

starlightsparker wrote:

(#2)
im confused on how this would work
like lets say this is the screen of the project <> and >< are sprites:

<>

><



as you can see, technically <> will always be facing >< because as long as its showing, to the thing that detects it, itll always think its facing it, right?

I see how that can be confusing–but in this case they would not technically be facing each other. I'll clear this up a bit.

Let's assume both of them are pointing towards the default 90 degrees and draw a line at their rotations. It would look like this:

<>—————————————

><—————————————–


<>'s line does not touch >< or its center (depending on the use case) so the boolean would return false.

Now let's move >< below <> and rotate <> 90 degrees clockwise, for a total of 180 degrees:

^
v
|
|
|
><

As its line of “vision” passes through ><, the boolean would return true if set to “any.”

I guess that makes the block a bit more complicated, but I still think it'd be a nice thing to have. Thanks for bringing that up and I hope that clears the confusion!

EatNYeet wrote:

starlightsparker wrote:

(#2)
im confused on how this would work
like lets say this is the screen of the project <> and >< are sprites:

<>

><



as you can see, technically <> will always be facing >< because as long as its showing, to the thing that detects it, itll always think its facing it, right?

I see how that can be confusing–but in this case they would not technically be facing each other. I'll clear this up a bit.

Let's assume both of them are pointing towards the default 90 degrees and draw a line at their rotations. It would look like this:

<>—————————————

><—————————————–


<>'s line does not touch >< or its center (depending on the use case) so the boolean would return false.

Now let's move >< below <> and rotate <> 90 degrees clockwise, for a total of 180 degrees:

^
v
|
|
|
><

As its line of “vision” passes through ><, the boolean would return true if set to “any.”

I guess that makes the block a bit more complicated, but I still think it'd be a nice thing to have. Thanks for bringing that up and I hope that clears the confusion!

Oh, i was actually really confused about this, thanks for explaining!

in this case, this seems like a good idea but what could be the uses for this? /genq

Felt that I should make a workaround, even if it's difficult (although the suggestion isn't much easier to understand :P) [this is only for directly at the center]

define am i pointing towards sprite (sprite)?
set [pointing towards v] to <(([atan v] of ((([x position v] of (sprite)) - (x position)) / (([y position v] of (sprite)) - (y position)))) + ((180) * <(([y position v] of (sprite)) - (y position)) < (0)>)) = (direction)>


define is sprite (sprite) pointing towards sprite (sprite2)
set [pointing towards v] to <(([atan v] of ((([x position v] of (sprite2)) - ([x position v] of (sprite))) / (([y position v] of (sprite2)) - ([y position v] of (sprite))))) + ((180) * <(([y position v] of (sprite2)) - ([y position v] of (sprite))) < (0)>)) = ([direction v] of (sprite))>

shift + right arrow to see entire script. Also, pointing directly towards the center is slightly ambiguous, as would it have to be directly at the center, or a rounded range? The direction can be in decimals, but its not always precise.

I could make a workaround for the other part (any) although it would simply be out of scope for a scratchblocks that i can make on the fly.

This is a project with the scripts provided so you don't have to copy this forum post if you want them :P
[In the project i used round blocks to give a small amount of leniency.]

Also, the workaround above works with clones, but you'll have to have the clone's x and y position in a list if you're going to point at another clone. For non clones, a simpler workaround is available (only for the first block, second block stays the same.):

define am i pointing towards sprite (sprite)? \(simplified)
set [old dir v] to (direction)
point towards (sprite)
set [pointing towards v] to <(old dir) = (direction)>
point in direction (old dir)

malicondii wrote:

(#5)
Felt that I should make a workaround, even if it's difficult
-snip-

Ah, I figured there was some math on the more complicated side for a workaround. Even though it's relatively close to the top, I'll still link this post as the workaround. Might make the project with the scripts and share it for the post tomorrow if nobody else gets around to doing that.

EatNYeet wrote:

Ah, I figured there was some math on the more complicated side for a workaround. Even though it's relatively close to the top, I'll still link this post as the workaround. Might make the project with the scripts and share it for the post tomorrow if nobody else gets around to doing that.

Ah, i thought i put in the link, thats why there's an <insert link here> part lol, i'll link it now.

EatNYeet wrote:

malicondii wrote:

(#5)
Felt that I should make a workaround, even if it's difficult
-snip-

. Might make the project with the scripts and share it for the post tomorrow if nobody else gets around to doing that.

I have a project dedicated to storing useful custom blocks for users to use, want me to add that?