So, I have searched around the forum and found some wanted this, but they were not able to explain it and or they didn't know what or how to do it. I know there is a work around but that takes forever if there are too many colors at too many places (it will however scan and render images with few colors. So here goes:

set [color v] to (touching color::sensing)

where the color is basically this:

Image above is code for if touching color
Scratch can already find the color it (mouse pointer or the sprite) is touching so why not output that value?

Example usage: Image scanning and rendering (way faster than the existing ones)
- Upload image
- Draw the scanner costume which is a simple dot at center
- Scan the colors and re-draw the image using pen only:

Scanning:

set y to (180)
repeat (360)
    
set x to (-240)
repeat (480)
    
add (touching color::sensing) to [list v]
change x by (1)
end
change y by (-1)

end

Rendering:

pen up
clear
set pen size to (1)
set y to (180)
set [c v] to [0]
repeat (360)
    
set x to (-240)
pen down
repeat (480)
    
change [c v] by (1)
set pen color to (item (c) of [list v])
stamp
change x by (1)
end
pen up
change y by (-1)
end

This code above may or may not function correctly (haven't done any testing it with it lol) but you do get the idea right?

The colors are in ARGB(Y) (I think…) and that would be handled by scratch.
Please post a reason if you are not supporting this!

Edit: clearing out some confusion.
This block will function just like an eye dropper (that thing on paint even on scratch which you click and click on color you want). After clicking the touching color block, you will notice that it (color block) will change to the color the mouse pointer is touching till you click it. So saying scratch can recognize each different color, but doesn't have a reporter. This block reports the color a sprite touches, not the mouse pointer.

Support for

(color at x:(0) y:(0)::sensing) // updates to your current position

Don't suggest this! It is already suggested.
And the color should be reported in decimal (0-16777215) which is compatible with the Scratch color inputs.

Btw I already supported this in my signature xD

Sheep_maker wrote:

Support for

(color at x:(0) y:(0)::sensing) // updates to your current position

…

That script will not update it to the sprites current position unless you put the x, and y of sprite to that

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

The touching color doesn't need that as it will automatically output the color in base 10 (why is there a minus before the color number starts?!) So basically, mine is a shorter version ^u^

P444 wrote:

Sheep_maker wrote:

Support for

(color at x:(0) y:(0)::sensing) // updates to your current position

…

That script will not update it to the sprites current position unless you put the x, and y of sprite to that

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

The touching color doesn't need that as it will automatically output the color in base 10 (why is there a minus before the color number starts?!) So basically, mine is a shorter version ^u^

Oh whoops, I should have been more detailed in my post. I meant the default value in the block palette (like how the “go to x y” block's default value is the sprite's current position)

Sheep_maker wrote:

Support for

(color at x:(0) y:(0)::sensing) // updates to your current position

Don't suggest this! It is already suggested.
And the color should be reported in decimal (0-16777215) which is compatible with the Scratch color inputs.

Btw I already supported this in my signature xD

Support for both this and

(color at [sprite v] :: sensing)

The one with coordinates would simply pick the colour at the coordinates you give. The one with a sprite would pick the colour at the sprite's centre, but it would pick up the colour of the layer under the sprite, rather than the sprite itself.

stickfiregames wrote:

Sheep_maker wrote:

Support for

(color at x:(0) y:(0)::sensing) // updates to your current position

Don't suggest this! It is already suggested.
And the color should be reported in decimal (0-16777215) which is compatible with the Scratch color inputs.

Btw I already supported this in my signature xD

Support for both this and

(color at [sprite v] :: sensing)

The one with coordinates would simply pick the colour at the coordinates you give. The one with a sprite would pick the colour at the sprite's centre, but it would pick up the colour of the layer under the sprite, rather than the sprite itself.

I would rather use seperate codes for each sprite (like not putting every scripts of other sprites in one single sprite) just like how the volume works separately for each sprites sounds.

stickfiregames wrote:

Sheep_maker wrote:

Support for

(color at x:(0) y:(0)::sensing) // updates to your current position

Don't suggest this! It is already suggested.
And the color should be reported in decimal (0-16777215) which is compatible with the Scratch color inputs.

Btw I already supported this in my signature xD

Support for both this and

(color at [sprite v] :: sensing)

The one with coordinates would simply pick the colour at the coordinates you give. The one with a sprite would pick the colour at the sprite's centre, but it would pick up the colour of the layer under the sprite, rather than the sprite itself.

Oh, I like that idea; however the wording is confusing. Maybe it should be

(color below [Sprite1 v]'s center::sensing)

Sheep_maker wrote:

stickfiregames wrote:

Sheep_maker wrote:

Support for

(color at x:(0) y:(0)::sensing) // updates to your current position

Don't suggest this! It is already suggested.
And the color should be reported in decimal (0-16777215) which is compatible with the Scratch color inputs.

Btw I already supported this in my signature xD

Support for both this and

(color at [sprite v] :: sensing)

The one with coordinates would simply pick the colour at the coordinates you give. The one with a sprite would pick the colour at the sprite's centre, but it would pick up the colour of the layer under the sprite, rather than the sprite itself.

Oh, I like that idea; however the wording is confusing. Maybe it should be

(color below [Sprite1 v]'s center::sensing)

You can eliminate that by doing this as I have mentioned in my first post! : Draw the scanner costume which is a simple dot at center which is 1x1. This will eliminate the error in which the sprite is touching more than one color.

P444 wrote:

Sheep_maker wrote:

stickfiregames wrote:

...

Oh, I like that idea; however the wording is confusing. Maybe it should be

(color below [Sprite1 v]'s center::sensing)

You can eliminate that by doing this as I have mentioned in my first post! : Draw the scanner costume which is a simple dot at center which is 1x1. This will eliminate the error in which the sprite is touching more than one color.

But that block would detect the sprite's color, not the pen/backdrop below the sprite

“Touching Color”

P444 wrote:

“Touching Color”

1) a very laggy block
2) laggier on some computers like mine
3) and it gets laggy (very very very laggy) when you have to run the touching color block 16384 times just to get to white
4) and then when you want to take a screenshot of the project using code, the color will have to be detected 172800 times

Sheep_maker wrote:

P444 wrote:

“Touching Color”

1) a very laggy block
2) laggier on some computers like mine
3) and it gets laggy (very very very laggy) when you have to run the touching color block 16384 times just to get to white
4) and then when you want to take a screenshot of the project using code, the color will have to be detected 172800 times

Um, please look at the first picture on first post… Scratch already has all colors. It just doesn't “report” it back… The whole use of this block is to eliminate all that lag! I would really appreciate if you read the whole first post.

P444 wrote:

Sheep_maker wrote:

P444 wrote:

“Touching Color”

1) a very laggy block
2) laggier on some computers like mine
3) and it gets laggy (very very very laggy) when you have to run the touching color block 16384 times just to get to white
4) and then when you want to take a screenshot of the project using code, the color will have to be detected 172800 times

Um, please look at the first picture on first post… Scratch already has all colors. It just doesn't “report” it back… The whole use of this block is to eliminate all that lag! I would really appreciate if you read the whole first post.

Oh I thought you were posting a workaround (whoops). Didn't know that you meant that the first post has been updated.

Anyways, this block:

(touching color::sensing)

What colors would it return? Assuming a sprite was touching two colors at once, how would it return those colors?

https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/186736/?page=1#post-1832679
Draw a single dot at center of an empty costume. It can only touch a single pixel at a time, as the width and hight of the dot will be 1x1 pixels.

P444 wrote:

https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/186736/?page=1#post-1832679
Draw a single dot at center of an empty costume. It can only touch a single pixel at a time, as the width and hight of the dot will be 1x1 pixels.

What if that block was used in a sprite with a different costume (like the default Scratch cat).

Support for

(color at my center::sensing)

The eye dropper tool needs to be pressed and it detects the color the tip of the cursor is touching. For eg, My cursor may touch both black and red, but the tip of the cursor touches only a single specific pixel, so, same theory can be applied by detecting a color by getting the color at center.

.

I support for

color [I v] am on :: sensing reporter //Would return for other sprites too...?

and

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

Bump!