i thought perhaps i could use this
return value takes a ring with params and a list of params to be inputted, returning a list with first item being the ring and second item being the list of params
run does run (item (1 v) of @list) input list: (item (2 v) of @list)
theres one problem, if someone gets the my _ block, they can do my blocks and drag the blocks out
If it does the same thing as the primitive... what's the point?
I've considered that, I know it's an issue.
I'm going to try and fix it in a new version, don't worry.
if it does the same thing as the primitive... what's the point?
the point is that you can do things like this
{my example block ((a)) :: reporter} :: define hat
report (return value ({((#1) + (1))} input names: ((#1))@<>) (a) @>)
my example block (10) :: reporter
returns (list ({((#1) + (1))} input names: ((#1))@<>) (list [10] @<>) @<>) evaluated, aka the list this is, not ({(list ({((#1) + (1))} input names: ((#1))@<>) (list [10] @<>) @<>)} @>)
{call ((a)) :: reporter} :: define hat
report (call (item (1 v) of (a)) input list: (item (1 v) of (a)) )
call (my example block (10)) :: reporter//11
No offense, but I can't see where this is useful...
I mean, if you need to have a value in a reporter be variable (e.g. (() + (3)) ) you can just use actual variables or (map (() @>) over []) . ( ((a) + (3)) , (map ((() + (3)) @>) over (list [1] [2] [3] @<>)) )
Also, instead of having to use 3 blocks to, for example, make a sprite say "Hello!" ( run (return value ({say []} @>) [Hello!] @<:> :: control) :: control ) you could simply run the block, or again, use a variable. ( say [Hello!] , say (a) )
isnt that like saying why have rings and call and run blocks if you can just run it directly
Those primitives are mainly used for having blocks as variable inputs.
Rings are used to pass blocks as inputs before they're evaluated, or turn blocks themselves into inputs rather than their output.
Examples:
- When (a) 's value is ({say []} @>) , you could use run (a) with inputs [Hello!] @<:> or run (a) with inputs (b) @<:> when (b) 's value is "Hello!" to run say [Hello!] .
- When (a) 's value is ((() + ()) @>) , you could use (call (a) with inputs [1] [2] @<:>) , (call (a) input list: (list [1] [2] @<>)) , or (call (a) input list: (b)) when (b) 's value is {1, 2} to run ((1) + (2)) .
Both examples only use up to 3 blocks in an actual script rather than custom blocks with definitions which add more blocks for a project to execute. Using primitives is much more efficient than your blocks and the results are exactly the same.
the reason i made those blocks is because, for example, if you are doing
{return a script that says ((a)) plus 1 :: reporter} :: hat define
report ({((a)+(1))} @>)
/*this doesnt work because it doesnt return the script where its whatever a is + one, it returns a variable a + one, so outside of this context, a is not what was inputted, and most likely when called, it returns an error because a isnt defined*/
That's a case where you don't need the ring, you could just have report ((a) + (1)) and it'll work just fine.
(P.S.: The block will not error, it will just report (((a) + (1)) @>) .)
wait () secs
not that kind, i mean save the ringed value, then run it later, like in the example
See the other topic you made. There is no error.
@specialred, microblocks isn't required. Click file>hide blocks... and right click on the menu that appears and select "all". Click OK and all the blocks are hidden. The stage has a couple of exclusive blocks as well, so you'll have to hide those from the stage.
I’ve already tried that.
The problem is that (my [blocks V]) won’t report any blocks if they’re all hidden.
Still, your blocks are less efficient. I understand if (return value (() @>) @:> :: control) looks nicer than (list (() @>) (list [] @<>) @<>) , but it’s not very useful if it’s a direct equivalent.
Right. I forgot that that was a problem because in my tests I used (extension [ide_blocks V] @:>. This normally works, but in one of my projects as well I have randomly gotten this error:
What you could do is set a variable (or even a block variable) to all of the blocks in the palette before hiding. In any case, I'm pretty sure you'll encounter the same issues with Microblocks.
Alright, I think that’ll work.
here is my way i did it
Snap! One Block
Hats are still there since they wont go in the stupid list
wow i was never expecting anyone to come back to this
that’s cool though, but i think there’s a workaround for the hats which i’m gonna try to find now
i have a new idea, relook at the project to see it
I made another block: 
. This block generates blocks until there is a when green flag clicked , when [ V] key pressed , when I am [ V] , or when I receive [ V] . These are the most useful hat blocks to start a project, in my opinion. I guess you could also use when <> , but you also need some sort of way to trigger it.