This is a pretty ambitious idea that I had
Let’s start with the easy one and an example.
So the main combatant to the custom hat block argument is that the when <> hat replaces their need
My combatant to this is
There’s multiple types of inputs that might be used with custom hat blocks
The basic way they work is each frame they pull the command
If true is reported the hat block runs
If false or nothing is reported then it doesn’t run
This is obviously the same as the when <> hat but here’s where the main part comes in
If you add an up var that functions, as well as c loops and cap blocks to the hat
If you drag a hat block into the editor it changes the reason it triggers, so for example you could put a “when green flag clicked” hat block into the area and it will change the reason the hat block runs instead of on every frame.
Now for ringed hat blocks
They work somewhat like booleens when they get called
When called they report true or false based on weather they should be running
If they get run or launched they act like a wait until block where it waits until the hat block is triggered to run the rest of the script
(I may be misunderstanding continuations but:
If you where to run a hat block’s continuation it never stops running and acts as an independent script, normally the script would be disabled the first time the hat is run but not if ran with continuation)
Some use cases of these would be
1m reducing the number of blocks in the pallet (for example you could have a forever if hat block instead of dragging in a green flag, then a forever loop, then an if block)
Minimizing code confusion: if you have a ton of when hats it can get confusing as to what is what
3: allowing all blocks in the block pallet to be first class
4: allowing running hat blocks with inputs
5: be able to make snap, inside of snap (something I’m working on)
Again I’m just spitballing ideas out here, I really don’t think these would be added but if they where it would be pretty cool