“when this sprite touches” is a block that currently exists in scratch's code:

i suggest that it gets added to the editor, but instead of having it be an events-sensing hybrid, it could just be an events block, like this:

I imagine there could be confusion about how it works. Does it fire continuously or only once when contact is made? Both behaviours have their use cases, but at a glance you can't tell which use case this block serves.

“Forever if touching” and “forever, wait until touching, wait until not touching” are clearer, imo. Their behaviours are obvious to anyone looking inside the project, and the lack of a hat block guides you into making the choice between the two consciously.

Also, whichever behaviour this hat block has, you have to use a variable to mimic the other. This is not the case with the loop-based workarounds.

rdococ wrote:

I imagine there could be confusion about how it works. Does it fire continuously or only once when contact is made?

It would do it only when contact is made, and it would be just like this block:

when [loudness v] > (10)

What would be different from using this?:

when green flag clicked
forever
if <touching [ v] ?> then
do something
end
end

Mryellowdoggy wrote:

What would be different from using this?:

when green flag clicked
forever
if <touching [ v] ?> then
do something
end
end

Because this one already exists in the Scratch code.

k7e wrote:

rdococ wrote:

I imagine there could be confusion about how it works. Does it fire continuously or only once when contact is made?

It would do it only when contact is made, and it would be just like this block:

when [loudness v] > (10)

That block is questionable. I'm guessing it's there for absolute novices to make simple interactive projects with sensing values, but I don't see those same novices making a video game or animation that relies on touching. Perhaps that's why it was removed…?

I see no downsides to this, it would make sense for this block to be in the block palette. It serves its purpose, and doesn't have any niche or complex factors to it, as I see the “touching” boolean used a lot throughout projects. This would be a necessity for the newer Scratchers.

rdococ wrote:

I imagine there could be confusion about how it works. Does it fire continuously or only once when contact is made? Both behaviours have their use cases, but at a glance you can't tell which use case this block serves.

All the other hat block's properties act once when the statement is true, so I'd suppose that this will act similarly to the other hat blocks, or else that would be a huge throw in the formula.

Mryellowdoggy wrote:

What would be different from using this?:

when green flag clicked
forever
if <touching [ v] ?> then
do something
end
end

Two words: less reliable.

Honestly, this would just be overcomplicating things. There's an easy, simple workaround. No support.

unmissable wrote:

Honestly, this would just be overcomplicating things. There's an easy, simple workaround. No support.

I can't see how this will make things more complex from a single hat block. There are a thousand different scenarios to use this and the “touching ()” is one of the most used booleans. We could say the same for broadcasts and loudness over () hat blocks as they have a similar workaround to what the touching hat block consists of.

“When this sprite touches” is actually not an event-sensing hybrid - a separate events block exists for the dropdown menu (although it seems to be broken, as it does not have any sprites).

CST1229 wrote:

“When this sprite touches” is actually not an event-sensing hybrid - a separate events block exists for the dropdown menu (although it seems to be broken, as it does not have any sprites).

*me in a corner who didn't understand anything*

Bump
(possible duplicate)

unmissable wrote:

Honestly, this would just be overcomplicating things. There's an easy, simple workaround. No support.

Same argument.

unmissable wrote:

unmissable wrote:

Honestly, this would just be overcomplicating things. There's an easy, simple workaround. No support.

Same argument.

The block already exists in the Scratch code, it's just only accessible through hacked blocks. Also, in this case, the “when timer > ()” block is also overcomplicating things.

k7e wrote:

unmissable wrote:

unmissable wrote:

Honestly, this would just be overcomplicating things. There's an easy, simple workaround. No support.

Same argument.

The block already exists in the Scratch code, it's just only accessible through hacked blocks. Also, in this case, the “when timer > ()” block is also overcomplicating things.

Yeah, I know. But scratch team probably won't remove it and I don't have the time or effort to make them.

Bump

unmissable wrote:

CST1229 wrote:

“When this sprite touches” is actually not an event-sensing hybrid - a separate events block exists for the dropdown menu (although it seems to be broken, as it does not have any sprites).

*me in a corner who didn't understand anything*

Did you not get why it's broken or what lol

Mockup for the forums:

when this sprite touches [ v] :: events hat