could you please make new custom versions instead?
really nice!
I thought of that, but I didn't want people to have to think about what they were doing, and just use it.
Here is V2:
Please report any bugs you find along the way! I will update the OP soon.
I'm not sure why you want that, but I'll do that soon as well.
customized primitives are glitchy.
will there be a non variadic version? also, why not use warp{ in the block definition?
I think you no longer need warp{ } when making solely computational loops. (It's the main change in 10.4)
Whaaaat?!?
That's.. great actually.
Hmmmm.... I've just used this block (no thinking 
)
But it's not the expected result
"stored" should pass the value between calls.
right! completely forgot!
Use the primitive, not the custom set block.
????
Your smart pic redefines the primitive!!!
Does it work for you? Can you post a script result of "swap&return" with your block?
It's really clever idea to register a subscribers to a variable update, but... the "updatees" grows with every call and variable references are never garbage collected. So the C-shaped slot version will be required to release the reference.
Also it looks half-backed. How do you want to call the "updatees" to sync variables.
That is a very strange glitch... I'll make a bug report! Basically, I had a custom block with the primitive definition, and then the primitive had a customized definition, but when you load the script pic you get the custom block's definition in place of the primitive!
Here is the primitive set definition:
Link to project (the only thing that seems to work properly): Snap! Build Your Own Blocks
I've finally updated the project and I think I've ironed out the bugs. However, you will need to use the custom set block, at least until the Snap! bug is fixed.
I've added garbage collection (happens every time you open the project), because it was causing errors as the block vars were carried over with the project. I hadn't known how to implement garbage collection, but as it turns out, it was erroring on its own and that was exactly what was needed.
That... was the modified primitive's job. See here.
I thought of that but... that won't work for the case that I created this new version for:
This seems great! (Though, it would probably make more sense if the BDV version of (a counter::variables reporter) was renamed to (the counter)).
I agree. I was meaning to fix that!
Alright, I just updated the OP so that the script pics actually work properly, and I ironed out some bugs in the meantime. This should be my last update.
Custom versions of the set blocks can be found here along with the primitive ones.
Humph. Another bug? The weird thing is you can fix it by editing the "set primitive" block once. Then, it works until the next load. There is no reason that it shouldn't work, I think it has to be a snap bug.
I think changing the primitive blocks is something best avoided if possible 
Except the issue is with a custom block that is supposed to perform the task of a primitive, using the "primitive" block. I'll do more research on this later. Maybe it isn't even a bug. I won't know until I take a closer look.
