I think there should be an easier alternative to the

<> and <>

block. You should be able to also do something like this:

define unlock icon (icon id)
if <{
not <(icon)=(icon id)>
not <[icons v] contains (icon id)?>
}::#fff> then
 if <not <<(icon id)<[1]>or<(icon id)>[100]>>> then
  set [acheivment v] to (icon id)
  replace item (icon id) of [icons v] with [unlocked]
  broadcast [achievment v]
 else
  broadcast [error-icon_id v]
  end
 end

Instead of having

<not <(icon)=(icon id::custom-arg)>>and<not<[icons v] contains (icon id::custom-arg)?>>

, you could put multiple of those in the same argument.
Side note, I had to make the boolean insert white instead of a dark yellow to make it more realistic
Blocks like:

move () steps

pen down

and

replace item ( v) of [ v] with []

should be able to be put in string inputs.

But you should probably keep the

<>and<>

block so that New Scratchers won't have to make things tedious or have any difficulty with making projects.

Neutral support.

I don't think this is any easier or harder than the “add” block we have now. Sure, the one we have now can be problematic because it would make for really long scripts horizontally, but your suggestion could also be problematic for making long scripts vertically.

I don't see any particular benefit to your suggestion, but I also don't see any particular downsides. That being said, if Scratch were to add this in, I'd probably stick with the regular “and” block.

Za-Chary wrote:

Neutral support.

I don't think this is any easier or harder than the “add” block we have now. Sure, the one we have now can be problematic because it would make for really long scripts horizontally, but your suggestion could also be problematic for making long scripts vertically.

I don't see any particular benefit to your suggestion, but I also don't see any particular downsides. That being said, if Scratch were to add this in, I'd probably stick with the regular “and” block.

Thanks! I just think it would be a little less tedious

Support! I find it very hard for me to keep track of where everything is hooked up especially when they are all green… So a white block (or what ever color block) would be quite nice in this format.

StrangeMagic32 wrote:

Support! I find it very hard for me to keep track of where everything is hooked up especially when they are all green… So a white block (or what ever color block) would be quite nice in this format.

Thanks for the support!

Another example just for fun.

when flag clicked
say [Here are the motion blocks:] for (2) secs
say ({
move () steps
turn cw () degrees
turn ccw () degrees
point in direction ( v)
point towards [ v]
go to x: () y: ()
go to [ v]
glide () secs to x: () y: ()
change x by ()
set x to ()
change y by ()
set y to ()
set rotation style [ v]
if on edge, bounce
x position
y position
direction
}::#fff) for (2) secs

Also, I just made a white block to make it realistic. I don't want it to appear as a block, i just want it to appear as the input it was.

summunkid wrote:

StrangeMagic32 wrote:

Support! I find it very hard for me to keep track of where everything is hooked up especially when they are all green… So a white block (or what ever color block) would be quite nice in this format.

Thanks for the support!

Another example just for fun.

when flag clicked
say [Here are the motion blocks:] for (2) secs
say ({
move () steps
turn cw () degrees
turn ccw () degrees
point in direction ( v)
point towards [ v]
go to x: () y: ()
go to [ v]
glide () secs to x: () y: ()
change x by ()
set x to ()
change y by ()
set y to ()
set rotation style [ v]
if on edge, bounce
x position
y position
direction
}::#fff) for (2) secs

Also, I just made a white block to make it realistic. I don't want it to appear as a block, i just want it to appear as the input it was.

I still think that it shouldn't be green.

StrangeMagic32 wrote:

summunkid wrote:

StrangeMagic32 wrote:

Support! I find it very hard for me to keep track of where everything is hooked up especially when they are all green… So a white block (or what ever color block) would be quite nice in this format.

Thanks for the support!

Another example just for fun.

when flag clicked
say [Here are the motion blocks:] for (2) secs
say ({
move () steps
turn cw () degrees
turn ccw () degrees
point in direction ( v)
point towards [ v]
go to x: () y: ()
go to [ v]
glide () secs to x: () y: ()
change x by ()
set x to ()
change y by ()
set y to ()
set rotation style [ v]
if on edge, bounce
x position
y position
direction
}::#fff) for (2) secs

Also, I just made a white block to make it realistic. I don't want it to appear as a block, i just want it to appear as the input it was.

I still think that it shouldn't be green.

It sure would be weird for inputs/arguments to be green.

summunkid wrote:

StrangeMagic32 wrote:

I still think that it shouldn't be green.

It sure would be weird for inputs/arguments to be green.

I'm a bit confused now, inputs/arguments? What I mean is where in scratch does it have those? (do you mean where you input numbers/letters, and also booleans?)

Alternate version, where the boolean input's background is the same color as it would be without any booleans:

if <{
<first condition :: operators>
<second condition :: operators>
} :: #cc9816> then
...
end

Another idea I had:

I think the <and> block works fine. This suggestion would save space, yes, but not that much - to reiterate what @Za-Chary said earlier, you'd just be saving horizontal space at the expense of vertical space. The <and> block is also more similar to the way that “real” programming languages do it, and would also probably make more sense to new Scratchers than the suggestion - given the shape of the blocks and the inputs, it would just seem more intuitive to put booleans together using <and> than fitting multiple booleans into a boolean input. Experienced users would continue using the <and> block out of habit, and new users would use the <and> block instead of this because it would make more intuitive sense. This feature might have its benefits, but in the end I don't think it would help much, and I can see this becoming an unnecessary feature that nobody uses.

To summarize: semi-support, bordering on no support. If you want to save horizontal space, I think a better way would be something like collapsible boolean slots.

██       ██  ██            ██  ██       ██
██       ██  ██            ██  ██       ██
██       ██  ██     ██     ██  ██       ██
██       ██  ██     ██     ██  ██       ██
███     ███   ██   ████   ██   ███     ███
 █████████     █████  █████     █████████

StrangeMagic32 wrote:

summunkid wrote:

StrangeMagic32 wrote:

I still think that it shouldn't be green.

It sure would be weird for inputs/arguments to be green.

I'm a bit confused now, inputs/arguments? What I mean is where in scratch does it have those? (do you mean where you input numbers/letters, and also booleans?)

If your talking about the multiple inputs and one thing, no. Scratch does not have vertical input placement (or whatever you want to call it). Try and do it yourself.
If your talking about inputs/arguments, I would expect you to know what those are (cuz you're a scratcher). But if you don't know what they are,
https://en.scratch-wiki.info/wiki/Argument

rdococ wrote:

Alternate version, where the boolean input's background is the same color as it would be without any booleans:

if <{
<first condition :: operators>
<second condition :: operators>
} :: #cc9816> then
...
end

Another idea I had:

I tried doing the normal boolean insert BG. I was just too lazy and decided it to make it white.
Your idea is great, but:

say (join (join [Your score was ] (score)) [!])

or

say (join [Your score was ] (join (score) [!]))