I have encountered a problem in my code, and my project runs too slowly when detecting colors!

A good way to fix this is a new color detection block that gives you distinct information about the color, saturation, and brightness of whatever it is touching. This would allow complex height maps and other cool projects to spark up. Otherwise, you'd have to create roughly 1,000,000 if-statements to handle detection as such, and that would slow down or even crash the editor. I hope this is taken into consideration, because I know this would help out a lot of people!

This is not the same as the color Boolean that checks for one specific color (referenced below), this is a changing, built-in variable for what color its touching. This would give you the 0-100 input you see on those sliders, if you understand what I mean.

<touching color [#1b37da] ?>

CONCEPT:
If this idea would be carried out, I would probably expect the blocks to be in the sensing category. This block would also likely be created much differently if implemented and would probably look much better and would make more sense!

([color v] touching [Sprite1 v] :: sensing)

IN ACTION:
In this scenario, the Scratcher sets their variable to the color that that is touching “Sprite1”, and uses a say block to join the variable and saturation value another sprite is touching

when green flag clicked
set [my variable v] to ([color v] touching [Sprite1 v] :: sensing)
say (join (my variable) ([saturation v] touching [Sprite2 v] :: sensing)

BUGS AND FIXES:
There are many technical bugs that may come about when this block is used. Let's discuss them and their possible fixes!

1. Multiple Collisions Error:
   This error may occur when a sprite overlaps with two colors with two different color combinations. There are a few fixes to consider!
   
   First Come, LAST Serve - This method would involve cancelling out previous sprite overlaps by whatever was touched most recently.
   =
   Higher Value > Lower Value - This method would involve taking the highest color, saturation, or brightness value it receives, but this brings on its own problems, so this is likely not a good choice.
   =
   Index - This method would involve adding another input section for the Scratcher, allowing them to choose a specific color, saturation, or brightness variable based on what sprite is giving it. This may be too technical and may not make enough sense to add, however. (concept below)
   
   

   ([color v] touching [Sprite1 v] from sprite [Sprite2 v] :: sensing)

   =
   
   
2. Changeable Color Error:
   This error may occur when the block in the “Looks” category is used to alter the color. (referenced below) There are some fixes to consider!
   
   

   change [color v] effect by (25)

   
   Use Internal Editor Values - This method involves simply ignoring this graphic effect and uses the color information from the Scratch sprite editor. This poses issues depending on the project and needs of the Scratcher at hand, so this may not be a viable option.
   =
   Make Color Info. Dynamic - This method involves changing this specific variable based on the change of the color effect given by the block referenced above. However, this could make it very confusing for the Scratch Team to program and may not be appropriate for this block concept.
   =
   
   
3. Touching Color Bug - Solved
   This error, which was submitted by @HBALabs, involves the block combination referenced below, and here is the explanation
   
   

   <touching color ([color v] touching [Sprite1 v] :: sensing)>

   
   Let's set up an example. Let's say that this block is located on Sprite1. This block would always output true, as it's the same as asking the computer, “Are you touching the color that you're touching?” The answer, certainly being yes, means this block will always output true.
   
   But if it was located in a different sprite's scripts, say, Sprite2, then this block will output true only if Sprite2 in this scenario is touching an object with the same color value.
   

I really hope that somebody on the Scratch Team sees this and thinks about it. It would help out a lot!
(If you find any faults or bugs in this block, please notify me and let me update this summary!)

If anybody sees this and has a suggestion for this feature, please let me know! Attention to this thread will be greaty appreciated.

One final daily check-in! I just wanted to bump this thread toward the top, so someone sees it soon. Please consider leaving your own feedback and opinion on this new block idea.

TheBaton wrote:

One final daily check-in! I just wanted to bump this thread toward the top, so someone sees it soon. Please consider leaving your own feedback and opinion on this new block idea.

Please only bump it once it's off the front page and has been 24 hours since last post.

Also keep in mind that it may take some time before it's really discussed.

Bump 1

Support! This is very useful!

But, im a bit confused. Let’s say i have this block in this block:

<touching color [([color v] touching [Sprite2 v] :: sensing)] ? ::sensing>

What would happen here?

HBALabs wrote:

Support! This is very useful!

But, im a bit confused. Let’s say i have this block in this block:

<touching color [([color v] touching [Sprite2 v] :: sensing)] ? ::sensing>

What would happen here?

I believe that you're referencing this block:

<touching color ([color v] touching [Sprite1 v] :: sensing) ?>

And that is some interesting insight! The actions of this particular block combination would heavily be depending on what sprite this is used on, let's say if it were to be Sprite1 in this example. If this block was asking Sprite1, “Are you touching the color you're touching?”, then the answer is of course yes, so that would always output “true”.

However, if it were for a different sprite, say, Sprite2, then this block would output “true” if it is touching something of the same color value as Sprite1. Otherwise, it will output false, and this could result in very great game mechanics, especially for something of a multiplayer game.

Thanks for the advice, and I'll be sure to add it to the “Bugs and Fixes” category as “Solved”.

I have the same problem, but I want to be able to use pen to render images from outside of Scratch

TheBaton wrote:

I have encountered a problem in my code, and my project runs too slowly when detecting colors!
A good way to fix this is a new color detection block that gives you distinct information about the color, saturation, and brightness of whatever it is touching. This would allow complex height maps and other cool projects to spark up. Otherwise, you'd have to create roughly 1,000,000 if-statements to handle detection as such, and that would slow down or even crash the editor. I hope this is taken into consideration, because I know this would help out a lot of people!
This is not the same as the color Boolean that checks for one specific color (referenced below), this is a changing, built-in variable for what color its touching. This would give you the 0-100 input you see on those sliders, if you understand what I mean.

<touching color [#1b37da] ?>

CONCEPT:
If this idea would be carried out, I would probably expect the blocks to be in the sensing category. This block would also likely be created much differently if implemented and would probably look much better and would make more sense!

([color v] touching [Sprite1 v] :: sensing)

IN ACTION:
In this scenario, the Scratcher sets their variable to the color that that is touching “Sprite1”, and uses a say block to join the variable and saturation value another sprite is touching

when green flag clicked
set [my variable v] to ([color v] touching [Sprite1 v] :: sensing)
say (join (my variable) ([saturation v] touching [Sprite2 v] :: sensing)

BUGS AND FIXES:
There are many technical bugs that may come about when this block is used. Let's discuss them and their possible fixes!

1. Multiple Collisions Error:
   This error may occur when a sprite overlaps with two colors with two different color combinations. There are a few fixes to consider!
   First Come, LAST Serve - This method would involve cancelling out previous sprite overlaps by whatever was touched most recently.
   =
   Higher Value > Lower Value - This method would involve taking the highest color, saturation, or brightness value it receives, but this brings on its own problems, so this is likely not a good choice.
   =
   Index - This method would involve adding another input section for the Scratcher, allowing them to choose a specific color, saturation, or brightness variable based on what sprite is giving it. This may be too technical and may not make enough sense to add, however. (concept below)
   

   ([color v] touching [Sprite1 v] from sprite [Sprite2 v] :: sensing)

   =
   

• Changeable Color Error:
  This error may occur when the block in the “Looks” category is used to alter the color. (referenced below) There are some fixes to consider!
  

  change [color v] effect by (25)

  Use Internal Editor Values - This method involves simply ignoring this graphic effect and uses the color information from the Scratch sprite editor. This poses issues depending on the project and needs of the Scratcher at hand, so this may not be a viable option.
  =
  Make Color Info. Dynamic - This method involves changing this specific variable based on the change of the color effect given by the block referenced above. However, this could make it very confusing for the Scratch Team to program and may not be appropriate for this block concept.
  =
  

• Touching Color Bug - Solved
  This error, which was submitted by @HBALabs, involves the block combination referenced below, and here is the explanation
  

  <touching color ([color v] touching [Sprite1 v] :: sensing)>

  Let's set up an example. Let's say that this block is located on Sprite1. This block would always output true, as it's the same as asking the computer, “Are you touching the color that you're touching?” The answer, certainly being yes, means this block will always output true.
  But if it was located in a different sprite's scripts, say, Sprite2, then this block will output true only if Sprite2 in this scenario is touching an object with the same color value.
  

I really hope that somebody on the Scratch Team sees this and thinks about it. It would help out a lot!
(If you find any faults or bugs in this block, please notify me and let me update this summary!)

Hmm I will bump it. Please make a topic on each.

ProCoder81 wrote:

I have the same problem, but I want to be able to use pen to render images from outside of Scratch

Yes! Exactly! You could use this new block to scan all the color data in, therefore allowing the pen tool to re-render the whole image. This could make technical image scanners much quicker!

CoderMCProX wrote:

Hmm I will bump it. Please make a topic on each.

I think you've misunderstood; it's all the same block, the rest of everything you see are bugs and fixes and other stuff like that. It's just to uncloud the concept and make get rid of the errors.

Bump 2

cool, this'd be useful

Bump 3

TheBaton wrote:

Bump 3

cmon stop spam bumping it wasnt even 24 hours

i-stubbed-my-toe wrote:

TheBaton wrote:

Bump 3

cmon stop spam bumping it wasnt even 24 hours

You can bump if it falls off page one.

Mozboz wrote:

i-stubbed-my-toe wrote:

TheBaton wrote:

Bump 3

cmon stop spam bumping it wasnt even 24 hours

You can bump if it falls off page one.

I was told to not bump if it hasn't been twenty-four hours, but I just count daybreak as the next twenty-four hours. There's no sense in monitoring someone's bumping frequency. I'll try to be more lenient with my bumping, but my point stands.

Support. While there are booleans for this, they cannot fully replace this block as you need a gigatonne of them/checks to get anything close to current colour.

Bump!

bump