In Scratch, when you, for example, use the pen, it will just simply leave a mark on the screen and forget about it, and when you use the color effect block, it just sets the color to the number. You can use the

<touching color [#FFF000] ?>

to check if there is a color that you put in the color input where the sprite is, but what if you were checking which color was there? That would require tons of

<touching color [#FFF000] ?>

blocks, all with every color and every single shade of it. But what if there was a block that checked the color at the x and y coordinates you give it? What if there was a

(color at x: () y: () :: sensing)

block?
_____________________________________________
THE BLOCK

In Scratch, the

(color at x: () y: () :: sensing)

block would check the color at the coordinates that you give it, and would give you the number that you would use in the

set pen color to ()

to make that color. One use of this could be if you were making a cloud drawing program, and you were using pen, you could use

(color at x: () y: () :: sensing)

to check the color of all possible coordinates, add them all to a list, save it to cloud, and another person's program would read it, and make a pen drawing of what you made! Or, if you were using

set [color v] effect to ()

, and your sprite was all different colors, and you wanted to check the color change at one point of the sprite, you would input the coordinates of that part, and it will give you what color that part changed to!
_________________________
If you support or do not support, please make a reason for why you do/do not support this suggestion.
Thank you for reading and Scratch on!

That seems like a good idea! Perhaps also add a

(colour I'm touching:: sensing)

block to detect the colour the Sprite is touching at the Center (not the colour of the Sprite.)

Color at x, y block would be really useful for 100% pen games. But to check a color for a cloud draw program you can use this:

set [r v] to (0)
repeat (32)
set [g v] to (0)
repeat (32)
set [b v] to (0)
repeat (16)
if <touching color (((r) * (65536)) + (((g) * (256)) + (b)))> then 
add (((r) * (65536)) + (((g) * (256)) + (b))) to [color scan v]
end
change [b v] by (16)
end
change [g v] by (8)
end
change [r v] by (8)
end

This block would be extremely useful. 100% support

The problem with the below code is it takes a really long time to process and is not entirely accurate due to how scratch processes the touching color block. (more info here https://mv-ezproxy-com.ezproxyberklee.flo.org/wiki/Touching_Color_()%3F_(block) )

jromagnoli wrote:

Color at x, y block would be really useful for 100% pen games. But to check a color for a cloud draw program you can use this:

set [r v] to (0)
repeat (32)
set [g v] to (0)
repeat (32)
set [b v] to (0)
repeat (16)
if <touching color (((r) * (65536)) + (((g) * (256)) + (b)))> then 
add (((r) * (65536)) + (((g) * (256)) + (b))) to [color scan v]
end
change [b v] by (16)
end
change [g v] by (8)
end
change [r v] by (8)
end

awesome5185 wrote:

That seems like a good idea! Perhaps also add a

(colour I'm touching:: sensing)

block to detect the colour the Sprite is touching at the Center (not the colour of the Sprite.)

Thank you! However, the

(colour I'm touching:: sensing)

block has several problems:

1. Sometimes, Scratchers make the center of the sprite not in the middle, causing confusion.
   
2. It does not state in the block that it checks the color behind the center of the sprite, causing confusion.
   
3. If it did not check the color behind the center, what if the sprite was on different colors at the same time? What could it report?
   

P.S. Sorry if this post is off topic.

It could be a privacy problem if you show a picture from the camera and there is a quick way to scan that and store in a cloud variable.

mobluse wrote:

It could be a privacy problem if you show a picture from the camera and there is a quick way to scan that and store in a cloud variable.

Yes, that could be a problem with this block. Maybe if there was a project with a video block, this block, and cloud variables, it would have a warning like this:

This project contains the “Color on X, Y,” block, video sensing, and cloud variables. Thus, this project might take a picture of and/or videotape you. If you are concerned about this, please use “See Inside” and look at the scripts and check that this project will not take a picture of and/or videotape you.

Bump.

Bump.

Bump.

Semi-support, it should report a hex value instead.

PkmnQ wrote:

Semi-support, it should report a hex value instead.

It would probably just report a number, as (65536 * r) + (256 * g) + b. That number represents the same value as the corresponding hex value, but it can be used in calculations or, more importantly, dropped into a colour slot.

It would then be useful to have these as well:

([red | green | blue v] of [#3399ff] :: sensing)
(color r: () g: () b: () :: sensing)
(color [#ff9933] :: sensing)

to convert between colours and their component parts.

As for the actual suggestion, I support

(color at x:() y:() :: sensing)
(color at [sprite v] :: sensing)

The first one is self explanatory. The second one detects the colour at the sprite's centre, but ignores the sprite itself, so if you had a red sprite on a white background, it would return white rather than red.

I thought you meant this at first:

(color [#1534AB] at x:() y:() :: sensing)

For example,

if (color [#1534AB] at x:(0) y:(0) :: sensing) then
say [Yay, Blue!]
else
say [:( no blue.)
end

Bump.

Support; I can see myself using it. Although I don't use colour detection often inside of my projects, I'm sure in the future I'll try my hand at making a pen-based game, and this could be really useful. Especially if I change some variables… I could even make a colour picker feature!

jromagnoli wrote:

Color at x, y block would be really useful for 100% pen games. But to check a color for a cloud draw program you can use this:

set [r v] to (0)
repeat (32)
set [g v] to (0)
repeat (32)
set [b v] to (0)
repeat (16)
if <touching color (((r) * (65536)) + (((g) * (256)) + (b)))> then 
add (((r) * (65536)) + (((g) * (256)) + (b))) to [color scan v]
end
change [b v] by (16)
end
change [g v] by (8)
end
change [r v] by (8)
end

BAD BAD BAD. STAHP GIVING OUT WAYS TO STEAL IMAGES OF PPL.

In all seriousness, this workaround needs to be silenced as it can steal people's images and stash them in cloud where they cannot be modified by you in any way.

braxbroscratcher wrote:

jromagnoli wrote:

Color at x, y block would be really useful for 100% pen games. But to check a color for a cloud draw program you can use this:

set [r v] to (0)
repeat (32)
set [g v] to (0)
repeat (32)
set [b v] to (0)
repeat (16)
if <touching color (((r) * (65536)) + (((g) * (256)) + (b)))> then 
add (((r) * (65536)) + (((g) * (256)) + (b))) to [color scan v]
end
change [b v] by (16)
end
change [g v] by (8)
end
change [r v] by (8)
end

BAD BAD BAD. STAHP GIVING OUT WAYS TO STEAL IMAGES OF PPL.

In all seriousness, this workaround needs to be silenced as it can steal people's images and stash them in cloud where they cannot be modified by you in any way.

You can't freeze the webcam, so someone would have to stay still for a long time to get a decent picture them. Besides, that script isn't the most efficient way to scan the screen, although it is the simplest.

Bump.

Bump.

stickfiregames wrote:

braxbroscratcher wrote:

jromagnoli wrote:

Color at x, y block would be really useful for 100% pen games. But to check a color for a cloud draw program you can use this:

set [r v] to (0)
repeat (32)
set [g v] to (0)
repeat (32)
set [b v] to (0)
repeat (16)
if <touching color (((r) * (65536)) + (((g) * (256)) + (b)))> then 
add (((r) * (65536)) + (((g) * (256)) + (b))) to [color scan v]
end
change [b v] by (16)
end
change [g v] by (8)
end
change [r v] by (8)
end

BAD BAD BAD. STAHP GIVING OUT WAYS TO STEAL IMAGES OF PPL.

In all seriousness, this workaround needs to be silenced as it can steal people's images and stash them in cloud where they cannot be modified by you in any way.

You can't freeze the webcam, so someone would have to stay still for a long time to get a decent picture them. Besides, that script isn't the most efficient way to scan the screen, although it is the simplest.

You can go fast using run without screen refresh and use it in many clones, thus stealing images quickly and easily.