Making the database library able to store anything

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

You need all the properties of the costume: height, width, name, pixels.

True

Also blocks are done! Right now it can only store primitives, custom blocks are still a work in progress
https://snap.berkeley.edu/snap/snap.html#present:Username=cookieclickerer33&ProjectName=Databasemore%20stuff

When everything is finished I wanna make it so that there’s only one block that supports all data types, instead of one block for each data type

Why would you store the costume name? As far as I can tell there’s no way to set a costume name, and the thing will report the costume, not set it

Speaking of costumes, those are completed!
Gonna work on custom blocks next

Good point; there probably should be.

Maybe it could be added to the
Databasemore stuff script pic
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!

the full definition

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

details on creating nested custom 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

Huh? It does create a new costume. Costumes are first class; they don't have to be in some sprite's wardrobe to exist.

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!

My problem is not with "nested" but with "definitions." "Nested X" means "one X inside another X."

you are already able to save anything exept blocks and sprites but you have to arrange your data

you can directly store:
numbers
text

you have to arrange data for :
boolean
list
costume
sound

see this new database project

to test it, clear database contents, run the block to save a costume and check the database content

Oh… I didn’t realize it had been done already
At least custom blocks is an original creation

???

Like storing and importing custom blocks

check blocks with a robot icon