I was trying an experiment on the offline editor, where countries, represented by a single color, expand their territory and compete for dominance over the canvas. The sprites with a hue color of 0, 10, and 20 worked perfectly fine, but when I created a new sprite with a hue of 30, the 30 Civilization didn't expand and got wiped out very easily.

I thought it was a coding mistake, but the first three sprites worked perfectly fine. I created a sprite representing a hue of 40 because I thought the bug would extend into other colors with hues greater than 30, and that sprite worked fine too. I then thought it is a bug in the offline editor, but I then ported it to the online editor and the bug still happened. I believe that this is a bug within the

go to [ v]

block and not a coding mistake made by me. I have a theory that the

go to [random position v]

block is programmed so that sprites with a predominant hue of 30 will avoid colors with a hue of 30.

No, this is likely a bug with your code or just a coincidence.

Can you send the link to the project?

Believe it or not, when you stamp a sprite with color 30, brightness 100, saturation 100 the “touching color” block will not detect a match when testing for color 30, brightness 100, saturation 100.

It will detect a match for the color stamped if you test with color 29, brightness 100, saturation 100.


This is a “feature” (some would say bug) of Scratch.

There is no easy rule for the offsets when detecting colors.

The problem arises because Scratch uses different colour systems to write colours and detect colours.
Scratch converts Color Saturation Brightness colours to Red Green Blue colours when it draws.
Scratch detects colours as Red Green Blue colours but for speed only detects them to limited accuracy.
Together all this means that a stamped colour or sprite colour is often detected as a slightly different colour.

Maybe a solution could be to allow the creator to specify a “tolerance” level?