So in Scratch there are a few blocks that use color boxes, that directly use a color instead of a number. So, what if there were variables that saved the color of something?

Here's an example of a block that could be based off color variables:

set [ vColor Variable #1] to [#534c0d]

Here is an example of how a color variable could be used:

<touching color (Color Variable #1) ?>

red_king_cyclops wrote:

So in Scratch there are a few blocks that use color boxes, that directly use a color instead of a number. So, what if there were variables that saved the color of something?

Here's an example of a block that could be based off color variables:

set [ vColor Variable #1] to [#534c0d]

Here is an example of how a color variable could be used:

<touching color (Color Variable #1) ?>

You can put hex codes in cloud variables.:

set [☁ score v] to (join [0x] (hex value))
<touching color (☁ score) ?>

jromagnoli wrote:

You can put hex codes in cloud variables.:

set [☁ score v] to (join [0x] (hex value))
<touching color (☁ score) ?>

Why “cloud variables” in particular? I'm not aware of any reason it has to be a cloud variable. (Indeed, it'd really be way better to *not* use a cloudvar…)

Any variable (local, global, cloud) can contain a numerical value in hex, if it has the “0x” (or “0X”) prefix.

Here: https://scratch.mit.edu/projects/155246726/

This is a custom block that I made for just this purpose.

set [variable v] to [#66dd44] ::custom

define set [var] to [color]
set (var) to (color)

If you do intend on using it, please drop some credit in the description.

Current project: [s3Blocks: scratchblocks rewritten for Scratch 3.0] ::#4b4a60 //https://scratch.mit.edu/discuss/topic/290031/ Basically done!

TheLogFather wrote:

jromagnoli wrote:

You can put hex codes in cloud variables.:

set [☁ score v] to (join [0x] (hex value))
<touching color (☁ score) ?>

Why “cloud variables” in particular? I'm not aware of any reason it has to be a cloud variable. (Indeed, it'd really be way better to *not* use a cloudvar…)

Any variable (local, global, cloud) can contain a numerical value in hex, if it has the “0x” (or “0X”) prefix.

Sorry, I read it wrong and thought they wanted a cloud variable.

jromagnoli wrote:

red_king_cyclops wrote:

So in Scratch there are a few blocks that use color boxes, that directly use a color instead of a number. So, what if there were variables that saved the color of something?

Here's an example of a block that could be based off color variables:

set [ vColor Variable #1] to [#534c0d]

Here is an example of how a color variable could be used:

<touching color (Color Variable #1) ?>

You can put hex codes in cloud variables.:

set [☁ score v] to (join [0x] (hex value))
<touching color (☁ score) ?>

Thank you for telling me about hex codes, and how I could use them as a work-around to my suggestion.

NitroCipher wrote:

Here: https://scratch.mit.edu/projects/155246726/

This is a custom block that I made for just this purpose.

set [variable v] to [#66dd44] ::custom

define set [var] to [color]
set (var) to (color)

If you do intend on using it, please drop some credit in the description.

Thank you for making me this custom block. It could be useful.

TheLogFather wrote:

jromagnoli wrote:

You can put hex codes in cloud variables.:

set [☁ score v] to (join [0x] (hex value))
<touching color (☁ score) ?>

Why “cloud variables” in particular? I'm not aware of any reason it has to be a cloud variable. (Indeed, it'd really be way better to *not* use a cloudvar…)

Any variable (local, global, cloud) can contain a numerical value in hex, if it has the “0x” (or “0X”) prefix.

Thank you for correcting @jromagnoli

Probably a block like this would be better.
It would report the color selected as a number.

(color [#FF0000]:: sensing

Pezd wrote:

Probably a block like this would be better.
It would report the color selected as a number.

(color [#FF0000]:: sensing)

This is a great suggestion, even better than mine. Thank you for stating it.

Pezd wrote:

Probably a block like this would be better.
It would report the color selected as a number.

(color [#FF0000]:: sensing

I really like this concept – I would certainly see it as having several uses!


I can foresee some potential confusion, though – in particular, Scratchers trying to drop it into places where it appears to make sense at first, but really doesn't when you know what the block actually is (i.e. a numerical value):

<touching (color [#ff0000] :: sensing)?> // oops! 
set [color v] effect to (color [#ff0000] :: sensing) // would be kinda nice...  :) 
(distance to (color [#ff0000] :: sensing)) // heh ;) 
point towards (color [#ff0000] :: sensing) // *grin* 
go to (color [#ff0000] :: sensing) // *grin* ^2 
(letter (3) of (color [#ff0000] :: sensing)) // OK, bit wacky this one – but is this "d", since the colour is "red"...?  :D 

Not sure how to avoid misconceptions like that…?

TheLogFather wrote:

Pezd wrote:

Probably a block like this would be better.
It would report the color selected as a number.

(color [#FF0000]:: sensing

I really like this concept – I would certainly see it as having several uses!


I can foresee some potential confusion, though – in particular, Scratchers trying to drop it into places where it appears to make sense at first, but really doesn't when you know what the block actually is (i.e. a numerical value):

<touching (color [#ff0000] :: sensing)?> // oops! 
set [color v] effect to (color [#ff0000] :: sensing) // would be kinda nice...  :) 
(distance to (color [#ff0000] :: sensing)) // heh ;) 
(point towards (color [#ff0000] :: sensing)) // *grin* 
(go to (color [#ff0000] :: sensing)) // *grin* ^2 
(letter (3) of (color [#ff0000] :: sensing)) // OK, bit wacky this one – but is this "d", since the colour is "red"...?  :D 

Not sure how to avoid misconceptions like that…?

lololololol
Well you can make those same mistakes with scratch blocks already present.

set [color v] effect to <touching color [#b72590] ?>// this statement makes sense if you don't know the difference between reporters and baleans.

go to x: (distance to [sprite v]) y: (distance to [sprite v])

Wait a second. I never knew there was any of these blocks

(go to ())
(point towards ())

Pezd wrote:

Wait a second. I never knew there was any of these blocks

(go to ())
(point towards ())

Oops! –Left the brackets in there. [Fixed!]

Meant:

go to (color [#ff0000] :: sensing)
point towards (color [#ff0000] :: sensing)

I.e. these blocks:

go to [something v]
point towards [something v]

Also, thinking a bit more about it, I don't see why it would be a blue sensor block – it has nothing to do with sensing (and that's potentially part of the problem with misconceptions).

Not sure what it would be in, though… A green Operator block? An orange Data block?

(color [#ff0000] :: operators)
(color [#ff0000] :: variables)

TheLogFather wrote:

Pezd wrote:

Wait a second. I never knew there was any of these blocks

(go to ())
(point towards ())

Oops! –Left the brackets in there.

Meant:

go to (color [#ff0000] :: sensing)
point towards (color [#ff0000] :: sensing)

I.e. these blocks:

go to [something v]
point towards [something v]

Also, thinking a bit more about it, I don't see why it would be a blue sensor block – it has nothing to do with sensing (and that's potentially part of the problem with misconceptions).

Not sure what it would be in, though… A green operator block? An orange Data block?

Well it can be in a lot of categories. Probably either be sensing or operators though. I disagree with it being a data block, since it is not a variable you make.

Pezd wrote:

Well it can be in a lot of categories. Probably either be sensing or operators though. I disagree with it being a data block, since it is not a variable you make.

Sensing doesn't make sense…

The Data pane contains blocks other than variables (“set”, “change”, “hide”, “show” are not variables), but they are all currently variable (or list) related, so it does seem slightly out of place at the moment, conceptually, even though it's the place that really makes most sense (since the “color” block *is* a form of “Data”)…

Maybe if there were other similar ‘constants’ in there, like <true> and <false>…? (Not that I particularly feel the need for such things, though they have been suggested…)

I can't see anywhere reasonable for this colour block other than Data or Operators, TBH (similarly <true> and <false>).

If they did go in the Data palette, I'd suggest they would have a different colour from variable blocks (just like lists are different).

TheLogFather wrote:

Pezd wrote:

Well it can be in a lot of categories. Probably either be sensing or operators though. I disagree with it being a data block, since it is not a variable you make.

Sensing doesn't make sense…

The Data pane contains blocks other than variables (“set”, “change”, “hide”, “show” are not variables), but they are all currently variable (or list) related, so it does seem slightly out of place at the moment, conceptually, even though it's the place that really makes most sense (since the “color” block *is* a form of “Data”)…

There are other variables in sections other than ‘variables’

(x position)
(size)
(volume)
(mouse x)

And so on…

Although all those variables are in sections that have things related to the variable.
I thought at first it should go into sensing since it has other color related blocks.

<touching color [#9b7b4f] ?>
<color [#206403] is touching [#58f5ec] ?>

But if we are putting it in a section with other blocks similar to it, then it might also go in pen.

I do see why you think it should be put in variables, but not only would it be out of place, I think it would also be hard to find.

jromagnoli wrote:

red_king_cyclops wrote:

So in Scratch there are a few blocks that use color boxes, that directly use a color instead of a number. So, what if there were variables that saved the color of something?

Here's an example of a block that could be based off color variables:

set [ vColor Variable #1] to [#534c0d]

Here is an example of how a color variable could be used:

<touching color (Color Variable #1) ?>

You can put hex codes in cloud variables.:

set [☁ score v] to (join [0x] (hex value))
<touching color (☁ score) ?>

What will set the (hex value) variable? You can't set a variable to a colour in the first place.

Pezd wrote:

Probably a block like this would be better.
It would report the color selected as a number.

(color [#FF0000]:: sensing

Support for this, and a lot more easier to use.

TheLogFather wrote:

Pezd wrote:

Wait a second. I never knew there was any of these blocks

(go to ())
(point towards ())

Oops! –Left the brackets in there. [Fixed!]

Meant:

go to (color [#ff0000] :: sensing)
point towards (color [#ff0000] :: sensing)

I.e. these blocks:

go to [something v]
point towards [something v]

Also, thinking a bit more about it, I don't see why it would be a blue sensor block – it has nothing to do with sensing (and that's potentially part of the problem with misconceptions).

Not sure what it would be in, though… A green Operator block? An orange Data block?

(color [#ff0000] :: operators)
(color [#ff0000] :: variables)

Isn't the other colour blocks sensing? The

go to (color [#ff0000] :: sensing)
point towards (color [#ff0000] :: sensing)

Will behave the same was as if the variable “variable” was “hello”

go to (variable)

Edit: There was a major Scratchblocks tag leak. 80% fixed now.

awesome5185 wrote:

jromagnoli wrote:

red_king_cyclops wrote:

So in Scratch there are a few blocks that use color boxes, that directly use a color instead of a number. So, what if there were variables that saved the color of something?

Here's an example of a block that could be based off color variables:

set [ vColor Variable #1] to [#534c0d]

Here is an example of how a color variable could be used:

<touching color (Color Variable #1) ?>

You can put hex codes in cloud variables.:

set [☁ score v] to (join [0x] (hex value))
<touching color (☁ score) ?>

What will set the (hex value) variable? You can't set a variable to a colour in the first place.

The hex value isn't a variable, it's just there to denote where you would put a hex number.

jromagnoli wrote:

awesome5185 wrote:

jromagnoli wrote:

red_king_cyclops wrote:

So in Scratch there are a few blocks that use color boxes, that directly use a color instead of a number. So, what if there were variables that saved the color of something?

Here's an example of a block that could be based off color variables:

set [ vColor Variable #1] to [#534c0d]

Here is an example of how a color variable could be used:

<touching color (Color Variable #1) ?>

You can put hex codes in cloud variables.:

set [☁ score v] to (join [0x] (hex value))
<touching color (☁ score) ?>

What will set the (hex value) variable? You can't set a variable to a colour in the first place.

The hex value isn't a variable, it's just there to denote where you would put a hex number.

Ooh, I'd prefer an example lol. I get it now.

Support, even though it has an easy workaround, I don't wanna learn all the colors, because there's

Wikipedia wrote:

16,777,216 colors

Thanks wikipedia.

PkmnQ wrote:

Support, even though it has an easy workaround, I don't wanna learn all the colors, because there's

Wikipedia wrote:

16,777,216 colors

Thanks wikipedia.

Search up RGB and Hex colour picker for easy acess, you don't need to remember them..

There should be something like

set color of  [foo v] to [#d1ada7]

note: I couldn't figure out how to make it orange