The Bit() Operator
Something really annoying in Scratch are the cloud variables. They can only store numbers, which makes saving strings or really any value for that matter very difficult. So, how could we solve this problem? Well, let's think about this: Why are we having this issue? It's because we can't really fit in a divider between numbers, so it's really hard to tell which is which automatically. So, I propose this block:

(encode (1) to [4 v] bits :: operators)
(decode (0001) :: operators)

How it works:
The ‘encode’ block, like it sounds, converts numbers to their bit format in the selected length of the user. Since bits are usually powers of 2, we shouldn't be able to insert a variable or any odd number because that would simply be too difficult to implement. In an example, if we put in ‘1’ and encoded it to ‘4’ bits, we'd output 0001.

The decode block would only allow values that include 0 and 1. Using a variable with other numbers will output NaN. It will check the length of the input, then decode it from that format. If you type in, let's say an odd number of 0s and 1s, it will also output NaN.

Why we need it:
It would simply make the serialization process quicker. There are tons of reasons not to add this operator in, but just why not? It seems like a good fit on Scratch and I already know that it could be used in WAY more creative ways than I described, but nonetheless, here it is.

What do you think? Is this a good addition to Scratch?

Cloud variables are only supposed to store numbers on purpose - this would make it easier for misuse.

This could be interesting in puzzle games and stuff like that, although I'm pretty sure the reason cloud variables dont store letters by default is to make it harder to make chatroom projects of any kind

han614698 wrote:

Cloud variables are only supposed to store numbers on purpose - this would make it easier for misuse.

I think I know what you mean, but please elaborate because I don't quite understand what you mean.

I think a better addition is to add a block that does common base conversions. Something like this:

(turn [61774] from [decimal v] to [hexadecimal v] :: operators) :: stack grey // F14E
(turn [15DEFEA7] from [hexadecimal v] to [binary v] :: operators) :: stack grey // 10101110111101111111010100111
// Some fun ones:
(turn [2763] from [octal v] to [letters and numbers v] :: operators) :: stack grey // 16B
(turn [hello] from [alphanumeric v] to [decimal v] :: operators) :: stack grey // 29234652, alternative name for letters and numbers

gilbert_given_189 wrote:

I think a better addition is to add a block that does base conversions. Something like this:

(turn [61774] from [decimal v] to [hexadecimal v] :: operators) :: stack grey // F14E
(turn [15DEFEA7] from [hexadecimal v] to [binary v] :: operators) :: stack grey // 10101110111101111111010100111
// Some fun ones:
(turn [2763] from [octal v] to [letters and numbers v] :: operators) :: stack grey // 16B
(turn [hello] from [alphanumeric v] to [decimal v] :: operators) :: stack grey // 29234652, alternative name for letters and numbers

This seems cool. I just think that bit format is much more widely used on top of the decimal system though. Even so, it seems like a good idea to add in conversion blocks so we could have multiple conversions, but I don't know how they'd be used. Maybe they'll add in the ability to enter hex codes into the color pickers.

TheBaton wrote:

han614698 wrote:

Cloud variables are only supposed to store numbers on purpose - this would make it easier for misuse.

I think I know what you mean, but please elaborate because I don't quite understand what you mean.

Cloud variables aren’t supposed to have words in them because of the ease to make life chats. This just increases that ease.

han614698 wrote:

TheBaton wrote:

han614698 wrote:

Cloud variables are only supposed to store numbers on purpose - this would make it easier for misuse.

I think I know what you mean, but please elaborate because I don't quite understand what you mean.

Cloud variables aren’t supposed to have words in them because of the ease to make life chats. This just increases that ease.

I don't believe it is even possible. There are just about 100 unique letters and symbols on the keyboard. At minimum, to have proper contact, you'd need only 26 individual codes. If that is so, you'd need a whopping FIVE DIGITS per letter for consistency. That being said, there is a 256-digit limit on cloud variables. So… 256/5 is roughly 51 characters. Data storage and limits still pose a significant threat to chatrooms. Also, there is still nothing stopping anybody from creating a chatroom. If it adds more ‘ease’ as you put it, then so be it. I know that most of the Scratchers can be trusted to their own devices. Let's stop assuming the worst of people. We're not animals.

TheBaton wrote:

Let's stop assuming the worst of people. We're not animals.

you need to assume the worst of me

because im very unpredictable

TheBaton wrote:

han614698 wrote:

TheBaton wrote:

han614698 wrote:

Cloud variables are only supposed to store numbers on purpose - this would make it easier for misuse.

I think I know what you mean, but please elaborate because I don't quite understand what you mean.

Cloud variables aren’t supposed to have words in them because of the ease to make life chats. This just increases that ease.

I don't believe it is even possible. There are just about 100 unique letters and symbols on the keyboard. At minimum, to have proper contact, you'd need only 26 individual codes. If that is so, you'd need a whopping FIVE DIGITS per letter for consistency. That being said, there is a 256-digit limit on cloud variables. So… 256/5 is roughly 51 characters. Data storage and limits still pose a significant threat to chatrooms. Also, there is still nothing stopping anybody from creating a chatroom. If it adds more ‘ease’ as you put it, then so be it. I know that most of the Scratchers can be trusted to their own devices. Let's stop assuming the worst of people. We're not animals.

It is incredibly easy to make a chat room, exactly like you said. If you used decimal to make the messages you can use just 2 characters per letter, you can have messages up to 128 letters long.

But besides that, I’ve seen plenty of chat rooms. Along with this, the risk created by chat rooms massively outweighs the benefit.
Users can get scammed, blackmailed, harassed, and many other things by being on a chat room, and there is no record to allow the ST to see what was sent.

TheBaton wrote:

Let's stop assuming the worst of people. We're not animals.

Actually, humans are animals because we eat and sleep.
Anyways the suggestion itself isn't a bad idea, it's a quicker way and I assume most Scratchers will use it

SpyCoderX wrote:

TheBaton wrote:

han614698 wrote:

TheBaton wrote:

han614698 wrote:

Cloud variables are only supposed to store numbers on purpose - this would make it easier for misuse.

I think I know what you mean, but please elaborate because I don't quite understand what you mean.

Cloud variables aren’t supposed to have words in them because of the ease to make life chats. This just increases that ease.

I don't believe it is even possible. There are just about 100 unique letters and symbols on the keyboard. At minimum, to have proper contact, you'd need only 26 individual codes. If that is so, you'd need a whopping FIVE DIGITS per letter for consistency. That being said, there is a 256-digit limit on cloud variables. So… 256/5 is roughly 51 characters. Data storage and limits still pose a significant threat to chatrooms. Also, there is still nothing stopping anybody from creating a chatroom. If it adds more ‘ease’ as you put it, then so be it. I know that most of the Scratchers can be trusted to their own devices. Let's stop assuming the worst of people. We're not animals.

It is incredibly easy to make a chat room, exactly like you said. If you used decimal to make the messages you can use just 2 characters per letter, you can have messages up to 128 letters long.

But besides that, I’ve seen plenty of chat rooms. Along with this, the risk created by chat rooms massively outweighs the benefit.
Users can get scammed, blackmailed, harassed, and many other things by being on a chat room, and there is no record to allow the ST to see what was sent.

Yes, however, it's still possible. You just labeled an even simpler way to commit the heinous acts you just described. We'd be no safer than we are now. It doesn't weigh in our out any form of risk. If I just used 010320 would give you ACT. See what I did there? I get your point, and in no way is this meant to demean you. It's just the fact that it's still super easy to do.

There's a workaround, it's just way more complicated.

TheBaton wrote:

SpyCoderX wrote:

-snip-

Yes, however, it's still possible. You just labeled an even simpler way to commit the heinous acts you just described. We'd be no safer than we are now. It doesn't weigh in our out any form of risk. If I just used 010320 would give you ACT. See what I did there? I get your point, and in no way is this meant to demean you. It's just the fact that it's still super easy to do.

While most of what you said is true, the block you proposed makes it even easier. This because to encode and decode text you need multiple custom blocks, an understanding of string manipulation, and a list of characters.

Your block does it all in one.

SpyCoderX wrote:

TheBaton wrote:

SpyCoderX wrote:

-snip-

Yes, however, it's still possible. You just labeled an even simpler way to commit the heinous acts you just described. We'd be no safer than we are now. It doesn't weigh in our out any form of risk. If I just used 010320 would give you ACT. See what I did there? I get your point, and in no way is this meant to demean you. It's just the fact that it's still super easy to do.

While most of what you said is true, the block you proposed makes it even easier. This because to encode and decode text you need multiple custom blocks, an understanding of string manipulation, and a list of characters.

Your block does it all in one.

I understand your fear, but it just isn't reasonable to ban a block like this. What are we going to do, take away lists and cloud variables? A feature should be placed in regardless of the bad implications. So, let's outweigh them. Because that's what the others did. But I just wanted to say, you'd still need a list of characters to find the # of the letter to convert it. You'd also only need one custom block, in theory, But all that aside, let's go:

Pros:
Allows easier data saves and serialization
Can create complex security and encryption codes

Cons:
Chatrooms are easier to create

Tell me if I missed something.

I have a question. Why not just allow letters in cloud variables instead of this suggestion?

han614698 wrote:

I have a question. Why not just allow letters in cloud variables instead of this suggestion?

This suggestion isn't inherently based on encoding to cloud variables. It just seems like a cool addition that I know has way more implications than I've thought of. The Scratch community is super creative.

I will close this suggestion, and redirect you guys to my other, much better suggestion:

https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/804200/

I feel like this suggestion is much more necessary. Thanks for the support!

han614698 wrote:

(#2)
Cloud variables are only supposed to store numbers on purpose - this would make it easier for misuse.

good point.