that's absolute madness! probably just a crayon selector menu.
suggsetions : use these instead of internal functions and internal vars, instead of making them accessible in the project.
[scratchblocks] script variables (var) :: #888888 set [var] to [(code)] run (var) :: #EDD100 [/scratchblocks]
bump
The idea is to just make the dispatch list once and have it remembered. And some of them need to be accessible in more than one block. We need a package system, real soon now.
Globally persistent block variables would be invaluable for such purposes.
I don't get it... I need a work around.
What would that do?
Yes, if they were accessible in more than one custom block.
One of the big disadvantages of a visual language (or at least of this visual language) is that calling a function made with lambda takes more effort than calling one made as a named block. If I say
then to call it I have to say
compared to
if I make a named block. This isn't the end of the world, but it's a disincentive to putting 25 anonymous functions in 25 block variables as I would have to do in this application.
Another disincentive is that if I do it with anonymous functions I end up with one huge long block definition for SET PEN [attribute] TO [value...], which then is hard to edit because it takes forever for the block editor to load.
These are all implementation details, and we could do things differently, and we should figure out how the "differently" should work to be efficient both in computer time and in human (programmer) time. One thing I think would help a lot would be the ability to say "Make a Block" inside a block editor and have the new block be treated as lexically inside the original block, so it has access to local variables etc. The trick is to do that in a way that doesn't require opening block editors for all the internal functions when you edit the outer one.
But also a block should be able to create other blocks that are then globally available.
You know how you can make sprite-local blocks that are visible in the palette only when you're editing in that particular sprite? A package is the same idea, but not tied to a sprite; you make a bunch of blocks that are local to a package, and only the blocks making up that package can see them. (But the package will typically also export a few blocks that are globally visible, so in the color library the eight (I think) blocks that have $brush in their names would be globally visible, and the other 40 or 50 helper procedures wouldn't be.
Actually, duh, now that I'm explaining this I can see that we don't have to invent packages; we can just use (hidden) sprites. So the only thing we have to change is to let the library contain XML for sprites as well as for sets of blocks.
Say what?
yes I need a work around.
what the freak do these do
@bh are you just keeping these blocks for the sake of true byob fashion where people use the blocks to be used with the system?
>:(
If I didn't understand you the first time, I'm not going to understand because you say the same thing again. What do you mean, "a work around"?
Do you mean the "out of 100/255" ones you mentioned in the previous post? I'm not keeping them.
for this :
The idea is to just make the dispatch list once and have it remembered. And some of them need to be accessible in more than one block. We need a package system, real soon now.
@sathvikrias could probably figure it out.
Oh. If you look in the library you'll see a block called INITIALIZE VARIABLES. Read it.
well, um, I replied to my self here(the last post), and as @helicoptur said once...
so yeah... the post is 
can't we just manage to like, um save the values of the variables in a list, labeled "Colors" or something, and get on with it @bh @bh?
the body is to simalar... what can I do about it, write something like this? no of course, but maybe I can??? 
@BH?
-bump