Step 1: Make a custom Predicate.
Step 2: Add a C Command Input.
Is this what you're seeing?
Yes. On the left side and bottom it has incorrect stretching. On some spots, this also causes colors to overlap (snap shading problems, not related.)
Hmm, zebra coloring doesn't work so well in that picture, does it? I guess we'd need four colors to be sure never to have two same-color blocks touching. :~)
It also looks worse in flat design
But no matter what, you can still tell where the blocks are because of the outline.
that's not what the command look's like. this is a example of a predictable inside an if block.
We are talking about commands inside predicates.
Four colors would do the same thing if you put it in too many times. Three colors might do the trick, though.
Everything looks worse in flat design!
Well, in principle that's always true. Scratch gets by without zebra coloring. The thing is, it's hard to know what's inside what, and zebra coloring generally helps with that. But this example shows that it doesn't help perfectly in every possible situation, just in most situations, which is still worthwhile. It's kind of like how you know whether a point is inside a complicated "simple" closed curve by drawing a ray from it, and then counting intersections with the curve until you get clearly outside it, and taking the parity of that count.
You'd have to be clever about how you use them, and you're not required to use all four colors in simple cases where two would do. But the Four Color Theorem tells us that if you want to be able to color every graph on a plane so that no two adjacent regions have the same color, you sometimes need four colors.
The original findings are fixed, but I discovered another bug.
(forum error says I can't upload images) (command predicate with full stop name)
Not only is the shading messed up, the block stub is detached, and any transparent parts are still clickable!
Broken Block:
i broke it more
and heres the reporter version
