Hi there,

The <touching color ?> block works very bad in many situations.
That might be due either to the block itself or to the “pick color” option.

Examples:

A sprite with color effects often can't be detected with the touching color block - not by selecting the original color, nor with the new color after the effect have been applied.

Even when trying on a fresh project (https://scratch.mit.edu/projects/editor for example), which has Scratch Cat and white background by default, using the <touching color ?> block with the white color returns “false”.

My browser / operating system: Linux Mint (Ubuntu derivative), Firefox 67.0, Flash 32.0 (release 0)

PLEASE STOP REPLYING ON THIS POST WHICH WAS ADDRESSED A LONG TIME AGO. IF YOU THINK THE TOUCHING COLOR IS STILL PROBLEMATIC PLEASE OPEN A NEW THREAD

HERE'S A RECAP:

1) When using RGB, Scratch rounds red and green to within 8, and blue to within 16. This probably distorts the HSV values you selected with the sliders, so you may have to fumble around to find the right color depending on the rounding.

2) If you want to properly detect a color, use the color picker

3) Scratch doesn't detect the white background of an empty project because it's not white, but transparent.

Mabey try <touching (sprite1)? >

I tried this, I made a sprite which was just a purple circle, put it on the stage, and put in this script:

when green flag clicked
forever
if <touching color [#000000] ?> then
play sound [pop v] until done
end
end

When I did it, it worked. Keep in mind that in order to get the color of the stage, I used the eyedropper tool and took the color directly from the stage. Remember that the colors are VERY specific, and even if you can't tell a difference, your computer can.

This block, however does not work with pen.

CR. My browser / operating system: Windows NT 10.0, Chrome 75.0.3770.100, No Flash version detected

Banana

2000624 wrote:

Mabey try <touching (sprite1)? >

I can't, I am using clones.

EIephant_Lover wrote:

I tried this, I made a sprite which was just a purple circle, put it on the stage, and put in this script:

- snip -

When I did it, it worked. Keep in mind that in order to get the color of the stage, I used the eyedropper tool and took the color directly from the stage. Remember that the colors are VERY specific, and even if you can't tell a difference, your computer can.

Using eyedropper, not the problem.

The problems appear more often in conjunction with sprite effects.

Blue_Science wrote:

EIephant_Lover wrote:

I tried this, I made a sprite which was just a purple circle, put it on the stage, and put in this script:

- snip -

When I did it, it worked. Keep in mind that in order to get the color of the stage, I used the eyedropper tool and took the color directly from the stage. Remember that the colors are VERY specific, and even if you can't tell a difference, your computer can.

Using eyedropper, not the problem.

The problems appear more often in conjunction with sprite effects.

Hi, do you have other example projects that are not the white backdrop and the cat? I don't know why the white backdrop and cat collision is not detecting, although it seemed to work just fine with other backdrops. I can see if we already have something recorded for this bug.

pondermake wrote:

Blue_Science wrote:

Using eyedropper, not the problem.

The problems appear more often in conjunction with sprite effects.

Hi, do you have other example projects that are not the white backdrop and the cat? I don't know why the white backdrop and cat collision is not detecting, although it seemed to work just fine with other backdrops. I can see if we already have something recorded for this bug.

Hi there,

This is a rather complex and heavy project but this is what brought my attention to this bug at first.
https://scratch.mit.edu/projects/196323057

In the “pong” app the red blocks are solid blocks that takes several hits to break. With this they have a brightness effect. In 2.0 I used a single <touching colour> block for each state but in 3.0 I doesn't work.

But when using a different block for each state it doesn't work either.

Blue_Science wrote:

Hi there,

The <touching color ?> block works very bad in many situations.
That might be due either to the block itself or to the “pick color” option.

Example:
Even when trying on a fresh project (https://scratch.mit.edu/projects/editor), wich has Scratch Cat and white background by default, clicking the <touching color ?> block with white color returns “false”.
This means even the default Scratch Cat sprite isn't able to detect the white background behind him.

My browser / operating system: Linux Mint (Ubuntu derivative), Firefox 67.0, Flash 32.0 (release 0)

This may happen because the backdrop in your fresh project contains no color. If it has no color you see checkers. To make it work try coloring the backdrop white and then try again. It's not a bug. This also happened to me when i tried to make my first platformer. The sprite did not touched white and it didn't falled. After that i colored the backdrop white and it worked.

<touching color [#6e7ca0] ?>    

say [false. your sprite is not touching that color.] for (2) secs

Signature: A kumkuat tried to eat my siggy but Little Emoji stoped it. Meow!

I had a separate post that got Duped to here, but I don't think it's actually a duplicate of this one. My Post

My issue is that sprites that are hidden or otherwise transparent are still having collision using the color block. If you use my code to test it you'll see that it's the background sprite touching the color of the horse that causes this. I've also seen people who are seeing collision with the color touching block even when the block is hidden. A hidden sprite should no longer have color and should no longer be able to be collided with I would think. There is definitely unexpected behavior happening with the touching color block.

I have a “touching colour bug” demo project here https://scratch.mit.edu/projects/284523037/ if it helps!

The ‘touching color’ script cant tell the difference between colors with no numbers in common (color, saturation, brightness), or any others. So I change the color, but it still can't tell the difference, which is weird, because it works with some colors. I could make a ‘touching sprite’ script, but it may take a while to convert the part of the first sprite to an entirely new sprite, and its not always possible to do that. Also, I was using the eyedropper, whose results have been inconsistently accurate, and sometimes change after I leave the sprite and work on another, coming back to see the script fail.

when green flag clicked
forever
if <> then
<touching color [#15a7ec] ?>
broadcast [ v]
end
end

Sorry. This is more like the script.

when green flag clicked
forever
if <touching color [#dbe4e9] ?> then
broadcast [ this isn't working, sorry]

Found another glitch, the eyedrop measures wrong over and over now, to add to other glitches mentioned above.

Found a fix, might be temporary though. Change the color to something random.

This bug still exists! The “touching color …” block usually gives incorrect results!

<touching color [#ffff00] ?>

If a new Scratcher (or any Scratcher) creates a backdrop costume with a certain colour (defined by Color,Saturation,Brightness) and then checks if a sprite is touching that colour (same Color,Saturation,Brightness) using a “touching color …” block, they likely won't get a match!

The same is true if they draw with Pen (defined by Color,Saturation,Brightness) and then checks if a sprite is touching that colour.

gor-dee's project (below) quickly shows that the required settings to detect a costume/pen color my be that color, may be 1 less than that color, or may not be detected by any close color value!
… and that is without looking at saturation and brightness.

gor-dee wrote:

I have a “touching colour bug” demo project here https://scratch.mit.edu/projects/284523037/ if it helps!

I have made another project in which areas of the backdrop are drawn in the Scratch Editor with values of Color, Saturation, and Brightness.

I use the colour 62,100,72 (Color,Saturation,Brightness) as an example and vary color, saturation and brightness by 1 in other areas.
The project then tries to detect any of the corresponding Color,Saturation,Brightness colours.
https://scratch.mit.edu/projects/419979876/
Success is mixed detecting the right colour, a different colour or none (as a value further away would be needed to match).

Possible Causes
=============
I think the problem is to do with inconsistent conversion of hsb (or Color,Saturation,Brightness) colours to RGB colours.
Scratch uses Color,Saturation,Brightness ranges of 1 to 100 for each component.
Scratch does not use the full 0-255 range for RGB components but ignores the least significant bits.
So Red has a “true range” of 0-63, Green 0-63 and Blue 0-31.

In the conversion from Color,Saturation,Brightness to RGB many Color,Saturation,Brightness values will map to one RGB value.
The “touching color …” block needs code behind it that converts the hsb colour to RGB and checks for a match.
If the code converts RGB to hsb then it is a one to many conversion, so a match may not happen.

Also the conversion code must be identical in the Scratch Editor, Pen and “touching color …” blocks.


(PS. I don't program in Scratch's source code language.)

Bump

I checked the source code, and I can confirm that RGB is used when checking if colors are touched:

From scratch-vm/src/blocks/scratch3_sensing.js

touchingColor (args, util) {
const color = Cast.toRgbColorList(args.COLOR);
return util.target.isTouchingColor(color);
}

colorTouchingColor (args, util) {
const maskColor = Cast.toRgbColorList(args.COLOR);
const targetColor = Cast.toRgbColorList(args.COLOR2);
return util.target.colorIsTouchingColor(targetColor, maskColor);
}

@-Rex- commented on my example project https://scratch.mit.edu/projects/419979876/ and I will summarise here.

@-Rex- says that the touching colour block works well, but when you uses the sliders in the color selector they are more precise (including decimal places) than the number 1-100 displayed.

Thus using the color selectors and setting color = 20, saturation = 30 and brightness = 40 might result in slightly different RGB colours as the values including decimals could actually be 19.6, 29.7, 39.6 or 20.4, 30.3, 40.4

My opinion:
It would be better if the color selector values set by the sliders could only be the integer values displayed.
Then 20,30,40 would always convert to the same RGB value and “touching color” would always match.

this glitch was fixed