This is kind of an extension of the topic Saving Data
This topic is just for making the library be able to store anything, lists where already figured out, and preatty much all data can be interpreted as a list of information, a block can be stored as a list of its label, inputs, and definition
Costumes are basically already solved! Just use “pixels of” and report that
Maybe it could be added to the
Block as a pull out? (So it doesn’t get crammed)
Having it as a setter might get confusing because, how are you supposed to report the value then?
Otherwise it would just set it to the costume name but, what do you do from there? you can’t set the new costume to a script variable
Slightly off topic, why was the name “new costume” chosen when it doesn’t create a new costume
Custom blocks are done!!!!!!
You can
Import custom blocks
Save custom blocks
Get custom blocks
This opens up a cool idea, you could make a block catalog and then when you click a button, it saves the block you selected to the browser, then you just import it using one of those blocks and there you go! A file free way of importing custom blocks!
This is one of the largest peices of code I’ve ever written!
And it’s the culmination of basically all of my snap experience up until this point, tracing back to even the scratchifyed days
when the block reported the custom block successfully I literally threw my hands in the air!
Now there is a pretty large limitation with this, the custom block’s definition has to only be primitives
I can think of a way to do more than just primitives but I’d absolutely love if someone could help me out with that gigantic task
Summary
You can import everything related to custom blocks
The definition of the stored custom blocks can only contain primitives or other custom blocks that are already in the pallet
This is the biggest thing I’ve ever made and uses all concepts I’ve learned so far
I’ll need some assistance to make nested custom block definitions
The idea I have in mind uses the iteration and composition library
We would need to repeatedly make lists of lists of every custom block’s definition until we get a primitive
The hardest part of this is well, writing the code
But the way that I wrote the custom block definition getter would require it’s own block to run nested ones
Let me know if you think you are up to the task
Actually, because of the way I wrote the original “get block” as long as the nested custom block inside the definition is the same as a block in the pallet (custom or not) (excluding definition and variable names) it will be reaplaced, so really the nested custom blocks is just importing multiple custom blocks at once, not rewriting the entire thing to support them
So nested custom blocks do work, as long as they are in the pallet already
more stuff on creating it
This means what will need to be done is go to the furthest definition in the list of nested custom blocks, import that, then step backwards, import that and repeat until it gets back to the original
That’s what I ment, wouldn’t just “costume” make slightly more sense?
Also kinda sorry, I should have just made all that stuff above into one huge post but it was kind of too late
I don't think you mean this. You mean nested custom block calls. Nested definitions, which I want someday, would be defining a custom block inside another one, so the inner one would be local to the outer one (to each invocation of the outer one, actually) and not exist elsewhere.
Google says “nested” means “arranged in a hierarchical structure.”
And “hierarchy” means “a system or organization in which people or groups are ranked one above the other according to status or authority.”
So “nested” is somewhat correct as the way it’s being decoded, theres a hierarchy of blocks. the one called being the highest. And the higher blocks have authority over what the lower blocks do
About your definition of nested custom blocks: So basically script scoped custom blocks? Sounds like that could be interesting, especially for this specific project!