@bh yes i know i already made a post talking about this, but this time i acually have a good reason.
in Snap! 10.0 we have 'Blocks all the way' which allows normal blocks to be customized, but hat blocks don't follow this. To extend this, add a control block:
to run the hat block.
plus: your logo is literally a custom hat block, and you cant make custom hat blocks; missed oppertunity.
That already exists
edit: I just realized what you meant, so this only works for the green flag.
Yes, Jens has noticed that, as you say, blocks all the way really means metaprogramming should extend to hat blocks. We're thinking about the design, but this is coming fairly soon, unless some big roadblock turns up. (Good timing; we just had this conversation last night.)
the flag just represents the most commonly used/mandatory hat block (when green flag clicked)
This is more like what it would look like.
I also just noticed that the block bevel isn't working on zebra colored blocks anymore. I need to fix that soon.
the zebra pattern on the hats are backwards
No, that's how it is in snap
oh
I don't think we need all of that. Just being able to stuff a hat block in a ring should do it; the rest you can then implement in user code. But, as I say, we still have to work out the design.
How does "running code" work? There it seems that the meaning is ambiguous/confusing...
"stop running this hat" Does it stop all hats of that type from running or stops the current script like "stop this script"?
For "this block", you can already achieve it by "this script" if you use this in custom blocks. What will be the difference? If you run it outside of custom blocks it returns "this block"?
"hide code" idk why would one need code hidden, someone expand on this for me
"convert hat to block" Unclear, I don't understand. Does this mean I can now create blocks such as
[scratchblocks]
move (10) steps::motion hat
[/scratchblocks]
?
I guess that custom hat blocks were partially implemented:
'running code' If the script/block is currently running in the project, it returns true.
'stop running this hat' Self explanetory. You can continue the hat block by using the 'run this hat' block.
'this block' Returns the block, not the definition of the block. This option is hidden in the main editor.
'this block script' Returns script if is running in a custom block editor
'hide code' What if you need to hide code that you dont want people to interfere with if you want to make a project for you to use your custom blocks?
'convert hat to block' Yes. You can make a move 10 steps hat
Extra block ideas below
With this many blocks we could just make an entire category dedicated to this.
btw this
seems weird and i can't input code compiling into the boolean but this
is better and i can input code compiling into the hat\
(Note: the rest of my block concepts will be orange for a better sign on a new category 'Hat Utilities')
that is not what i meant
convert hat ({when flag clicked} @addInput) to block :: reporter control before
I just realised i made convert hat ({when flag clicked} @addInput) to block :: reporter control before
With respect, I think you don't understand one of the design goals of Snap!. In the old days, in Scratch, people would create mods -- modified versions of Scratch itself -- and they would compete in terms of the number of blocks they added. (Primitive blocks, I mean, of course, since back then you couldn't write new blocks in Scratch itself.)
When we announced BYOB 3.0, the predecessor of Snap!, to the world, we took the opposite approach. We were proud that we added only eight blocks (to be exact, seven blocks and a button) to Scratch, and that was enough to give us custom blocks, first class procedures, first class lists, and with those, the ability for BYOB's users to write, in BYOB itself, any control structure or data structure they wanted.
Alas, we have since grown well beyond eight blocks. But it's still our policy to provide the minimum number of blocks needed to allow users to build whatever additional tools they need. (Our idea of minimality has expanded to include fast implementation of important algorithms that would be slow written in Snap!, such as higher order functions.)
So, when it comes to metaprogramming with hat blocks, probably all we'll add is the ability to ringify a hat block, or a script headed with a hat block. Users should then be able to use the existing metaprogramming facilities to do whatever they need. We'll do some experimentation to make sure we haven't forgotten some missing feature that really stands in the way of users manipulating hat blocks, but we won't add blocks just because they're useful, if they can straightforwardly be written with existing tools.