yes please! +1

+один

+1

Support and 1+

I think this is a very good idea.

[ v]

THIS NEEDS TO BE ADDED!

Yes +1.

I teach the basics of problem solving and programming using Scratch and the lack of this feature presents a bit of a road block.

The problem is that if one sprite plays say a Fanfare and this is used in the custom block and if when the block is reused by another sprite the sound file may be unavailable. There will be the same problem with costumes too, say sprite A has 5 costumes, but sprite B only the 1. If they can find a simple way to overcome that small hurdle it would be a logical and sorely needed improvement.

I'd like to see global custom blocks, but I do think there are implementation questions that need some careful consideration.

Does anyone have any comments about these…?

To spell them out again (sorry, bit long, as usual from me…)

1. When running a global custom block, which sprite should it actually ‘run’ in? The most obvious and sensible answer is “the one it's defined in” - after all, that's how custom blocks currently work, and anything else would cause questions/confusion over local variables, etc.

However, that also presents a further question: what if there are multiple clones of the sprite that contains the global custom block definition?

2. Does every clone then run its global custom block independently when it's called (once) from somewhere, using its own local variables? Or should it just be the ‘original’ sprite that runs it?

If all clones do run it, then it will undoubtedly cause the same confusion as broadcasts - and the same kind of check for clones or clone ids will be needed as currently with broadcasts. Another potential pitfall: what if you have numerous clones of a sprite call a global custom block - and that global custom block is in another sprite that also has numerous clones…? In that case, the number of times it gets run could multiply considerably. (And how about if the global custom block is called from within a clone of the sprite that actually has the block definition - should all clones still run it independently? That makes it behave quite differently to a custom block at the moment…)

But if only the original sprite runs it, then you need to remember it's only the values of local vars for that original sprite that can be involved, and in some ways the global block loses a bit of its potential power - one of the useful capabilities of global custom blocks would be to tell all clones to do some specific thing in one go from one place, much like you would with a broadcast, but with the extra flexibility of the arguments that can be passed to a custom block.

3. Should global custom blocks be distinguished from local custom blocks? I quite liked the way the 2.0 beta separated local variables from global in the variables pane (though they were not alphabetical then, which could be a bit tedious - and it still is tedious with the variable-name dropdown menus still not being alphabetical…)
I think it would be real handy to have something that makes it clear it's a global custom block rather than local, since there's such a big potential difference in behaviour.

I think one of the main desired uses of a global custom block would be to have the potential to run some relatively simple script from any sprite. For example, a calculation like atan2 might be required in multiple sprites, but it'd be nice to just have the one script somewhere that does it for you from whichever sprite you want.

So, the above considerations lead to another possibility…
How about if global custom blocks can only be defined on the background stage? Since that cannot have clones, it does at least remove the clone question, hence making it more intuitive that it's just getting done once from each sprite/clone where you actually called the block.
However, it does remove the potential power of having all clones of a sprite run a global block using only a single call from somewhere else - I guess that'd still be just for broadcasts. It would also mean you can only use global variables in that custom block, since the stage can't (for some reason?) have local variables.

Any thoughts…?

which sprite should it actually ‘run’ in? “the one it's defined in”

yep

every clone then run its global custom block independently when it's called

Yeah!

If all clones do run it, then it will undoubtedly cause the same confusion as broadcasts

Oh well… i don't think they are that confusing.

Should global custom blocks be distinguished from local custom blocks?

=/.. rather not.. I think that would confuse me a lot more…


From my experience, Custom blocks do not run as an individual thread.
When called, the Script stops, runs the custom block, and continues.
But when a custom block gets called from another sprite… it MUST run as an individual thread.

go to x:() y:() z:() ::custom

ProdigyZeta7 wrote:

I know I support this before, but how would global custom blocks be distinguished from local custom blocks? Maybe for the sprite only, there could be “sprite1: custom block name” like how local variables look on the stage.

I would prefer if global was the block with extra text rather than a local block, because local block will be more common.

[ v]

PH-zero wrote:

If all clones do run it, then it will undoubtedly cause the same confusion as broadcasts

Oh well… i don't think they are that confusing.

It's OK once you know it happens - but there are numerous cases here on the forums where a project is simply not doing what the creator expects, simply because they never considered that clones would be running those receive scripts (and similarly for key press event scripts).

Having global custom blocks also behave like that would produce countless more questions like that on the forums, despite it being a potnetially powerful behaviour.

PH-zero wrote:

Should global custom blocks be distinguished from local custom blocks?

=/.. rather not.. I think that would confuse me a lot more…

I wasn't thinking of them actually looking different - more like having a separator in the “More blocks” pane so you can tell which are local and which global. The variables shown in the Data pane used to be like that during the Scratch 2.0 beta, but that was changed in favour of having them all alphabetical (which is good), and all mixed together (unfortunately!) The variable drop-down menu still has a separator between local and global (and it's in creation order, not alphabetical, so it's inconsistent with the list of variables in the Data pane).

PH-zero wrote:

From my experience, Custom blocks do not run as an individual thread.
When called, the Script stops, runs the custom block, and continues.
But when a custom block gets called from another sprite… it MUST run as an individual thread.

Custom blocks are a little like broadcast-and-wait - the script for that custom block must complete before the calling script can continue. I wouldn't really see it being any different in the case of global custom blocks.

When you say “an individual thread”, are you thinking of it being similar to a broadcast (without wait)? If so, why would you expect it to be like that?

PH-zero wrote:
From my experience, Custom blocks do not run as an individual thread.
When called, the Script stops, runs the custom block, and continues.
But when a custom block gets called from another sprite… it MUST run as an individual thread.

Custom blocks are a little like broadcast-and-wait - the script for that custom block must complete before the calling script can continue. I wouldn't really see it being any different in the case of global custom blocks.

When you say “an individual thread”, are you thinking of it being similar to a broadcast (without wait)? If so, why would you expect it to be like that?

You're right with “Send message and wait”!
But when Sprite1 calls a custom block in Sprite2, should the script in Sprite1 wait?

go to x:() y:() z:() ::custom

This would be great. Perhaps, custom blocks defined on the stage could be visible from other sprites, but blocks defined within sprites are local to the sprite. We also don't want new programmers getting accustomed to using global functions for everything .

I support!

Also, to solve some of the problems, what if there was a block editor and / or a special container for custom blocks?

This reminds me of the “switch between global and local variables” discussion - which would also work here.

I support this since having global subroutines is very common and useful.

One way to implement it is to have custom blocks created under the Background be global. No checkbox needed. This is how variables under background are treated.

Clones would then be able to access the function block.

Just thought I'd add another thought for you to ponder. You define a global jump block to make sprites or clones jump. What happens when the stage calls it?

Apologies all… I've been using the name “Background” when I should have been saying “Stage”.

Regarding the global/local variable conundrum, the arguments passed from a sprite to the global function are, by definition, local to the sprite unless global variables are intentionally linked to the sprite's arguments through the sprite's script programming.

The global function would have to be able to create instances of itself that execute in parallel so that it doesn't become a bottle neck when many clones start calling it. Each instance would then need its own internal versions of any Stage (global) variables used in the global function block and those global variables could safely be updated only at the end of script execution. That way, temporary registers will be preserved within a script and won't be stomped on by simultaneously-running instances of the global function block. Updating global variables for global use could be done by the sprite that called the global function IF the function blocks had return arguments.

Under this scheme, global variables used in Stage custom function blocks would not be automatically updated. That's a little quirky, but I'm willing to live with that if it gives me global function blocks.

This comes back to the question of why the Stage has no local variables. If the Stage was given local variables, then a global function block could use those local variables for internal registers as described in paragraph 2 above and would be able to update global variables without relying on the Sprite to map the (currently nonexistent) return arguments to global variables.

It looks to me that the Stage needs local variables and then we can implement global function blocks within the Stage. As highlighted above, the complexities of having global functions run at the sprite level are staggering; best to avoid that quagmire altogether.

Does anyone know why the Stage only has global variables? I searched and didn't see anything.

Return argument thread; http://scratch.mit.edu/projects/11829884/

Yes please. This would work extremely well for projects where the custom blocks are so long that they lag the workspace, because I could simply create a new, invisible sprite to use with zero lag.

(110% SUPPORT)

though I probably wouldn't use this