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
I just realised i made
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.
Oh, that is still very much a thing to this day. There are many scratch 3.0 mods that add tons of completely unnecessary blocks. I love snap, because it knows what users really need, and doesn't throw hundreds of unnecessary blocks at you (although I can't say the same for custom block collections people used to make).
The great thing is that I can open someone's collection of 100 blocks and extract the two I really like, for my own collection. :~)
Thank you. It's because Jens spent his youth sitting at the feet of John Maloney, and I spent mine sitting at the feet of John McCarthy.
I confused "this block" with "this block script".
By the way, "block" can have different meanings, so if you use them for the classic stacking, jigsaw-like blocks (such as [scratchblocks]move (10) steps[/scratchblocks]), calling them "command" might be better, because it is already done in some parts of the UI (custom block creator, etc)
"convert predicate to hat" is unnecessary if it just triggers when it is true because can't the block [scratchblocks]when <>::control hat[/scratchblocks] do the job?
I don't think "when stop sign clicked" predicate will be seen outside of extraordinary use cases or bugged projects. Click the stop sign, too late, all scripts with that block are stopped, can't detect it.
The "when pause button clicked"? It just pauses, how will scripts be supposed to move on and handle the predicate? Does it work again when unpaused?
"when stop sign clicked" hat already exists in Snap! under "when I am stopped", albeit scripts are limited to one frame or instant. Any longer scripts will be stopped.
"start all" already exists again. Get a broadcast block and there is a green flag broadcast.
I like these concepts, but some are unfitting. Also some of my reasoning wasn't sounding great at all.
oh... can we atleast add custom hat blocks, ringed hat blocks and hats in the block editor, but only add the 'run this hat' and 'stop running this hat' blocks
Maybe. Not gonna do the design work in the forum. Maybe we'll announce a beta if we want users' comments at that stage.
ok. same thing for caps?
I really like this idea! Also, @ego-lay_atman-bay & @bh, why are you two hating on scratch mods that add a lot of blocks? I mean, if I were making a Scratch mod, I would probably add blocks too, but I do kinda get it, it's just that it sounds like a lot of hate.