Duchisan wrote:

define while ()

end

please don't block-spam in this newly-created page of mine

i really want global custom blocks, support

#2 seems to be the best option. While there are block deficiencies where sprite blocks are not in the stage, this goes for any procedure copied and pasted from a sprite to the stage- I see no reason for global custom blocks to change that. If, for instance, the stage uses a custom block containing pen commands, it simply won't run them and skips over the impossible ones.

If you want to be able to find the custom blocks easily, you can always stick them in an otherwise empty sprite, so you know where they all are. This is kind of like #4, but removes the need to make a completely different place to make them, also removing the need for thinking of a place to access this window. And I like the check box for global, as well.

I would like to represent my suggestion:
I don't want to repeat myself because I already did it on scratch github , so I'll post link instead:

Global Custom Blocks -https://github.com/LLK/scratch-vm/issues/3436

I'll explain here just the main points.

• When global custom block is called from the another script, the script is executed at the sprite where custom block is defined.
  Isn't it called a method but a procedure? There is simply no way you could implement features which are used by OOP , because it neither scratch's purpose or structure. That way would occur many ambiguous moments, like motion, looks, clone compatibility etc.
  
  
• Instead of listing every single one global custom block in custom block section, add new block “Global Custom Caller block” , which will have 3 dropdowns:
  1.Sprite from where global custom block is called
  2.Name of the custom block which is being called
  3.Would script run on the “original sprite” or clone
  Relatively to choice the argument fields would appear.
  
  
• Purpose - organizing , easier way of collaborating/remixing, teaching purpose of using libraries in programming languages.
  

For additional information check the link above.

I got an idea

Basically, when the define block is created, the define block and the custom block are given a thing like an ID that match each others. The define block’s ID and script is uploaded to some sorta thing that all sprites can access. When the custom block is moved from one sprite to another, the sprite takes the custom blocks ID and checks where the global define blocks are stored for a script. When it is found, it’ll use the script from the global define for the custom block. I know this might take up some memory, but it’s all I can think of.

Bump

Here's what I'm getting from all this. Please correct me if any of this is incorrect:

Throughout this discussion it sounds like #4 is the most acceptable solution (creating a new section for global blocks to be defined, which I'll call GLOBALS for clarity).

-The GLOBALS section would need to be able to have local variables to be defined (let's call them GL) which are used only in the scope of the GLOBALS
-When a sprite calls a block in the GLOBALS, it would be required to create local copies of the GL variables, so simultaneous calls could happen from multiple sprites without affecting each other
-The calling sprite would handle all statements and therefore they would be updated by calls to looks, sound, etc
-Global blocks should display in a different color (or shade) than regular blocks, whether they are listed under all sprites or require being dragged onto the backpack

I know confusion for beginners is an issue but I don't think it would be that confusing and a setting could be added for Standard or Advanced layouts, hiding GLOBALS and anything else that may hinder a new programmer but allow them to open more possibilities as they develop.

Lastly, these are great for creating and showing things but not for calculations, etc. Saving data into global variables may result in messed data if the same block is called simultaneously by multiple sprites. It will require return values. This could be implemented in a fairly straightforward manner I believe.
The definition block would be the only slightly strange one. It would be a standard define block but with two lines. The usual first one for the definitions of the arguments, then a second line that starts with “returns” and any number of returnable values.

define Multiply (val1) * (val2)
returns [value]

I think these would maybe be best shown as draggable [] as opposed to (values) and when dragged out would appear as a

set [values] to ()

but in the same color as the GLOBALS block instead of the variables color.
The calling block would just be the typical style with a second line as well that would allow for the returns to be dragged out (like arguments on blocks)

Multiply (val1) * (val2)
returns (value)

Something like above anyways. Without some form of return I don't think global blocks allowing multiple instances could work IMO.

IDEAIDEAIDEAIDEA
It's probably stupid but who cares
What if there was a little arrow button on the block menu, and when you press it, it comes up with a separate code window with all the global custom block definitions in it? Like if you had two sprite code menus open in a split screen, except one of them would just contain global block definitions. That code editor would work just like a normal one, except it doesn't accept hat blocks, and you could close it at any time with the arrow button. That way it's seamless, and you can tinker with it by dragging code from the sprite into underneath the definitions, but it's still separate and has all the blocks. If you try to drag an ‘illegal’ block in (i.e. a motion block in the stage or a hat block in the definition menu) it will just not work and revert to its original position. Will make mockups bc I genuinely think this will work.

Eagle138 wrote:

IDEAIDEAIDEAIDEA

I will make my own topic for this
Bump anyways

DadOfMrLog wrote:

⚠ Warning! -This post is quite long! ⚠
But I've tried to structure it to make it easier to ‘dip into’ the parts you might want to read…

Note that the purpose of this topic is NOT to ask for support (we've had plenty of topics like that already - see below). It's to ask for IDEAS how to make global custom blocks work in an intuitive way, to find alternative ways to do it that will work around some of the issues I raise!
What I'm asking is this… Can YOU think up a better way?

_______________________________________________________________________

Contents

• Introduction

• Scratch Team support

• So what's the problem…?

• Different ways to do it

• Issues & questions (in later posts)

OK, so after reading all of those sections – especially the different ways to do it and their respective posts (of course, I assume you read every word several times, didn't you…? yeah…? right…?) – I'd be curious to know if you have any ideas how to do it better, or how to overcome some of the problems/questions raised.

It'd be really great if some bright spark here could come up with some way to make global custom blocks work that none of us old fogeys have actually yet considered…

_______________________________________________________________________

Introduction

We have global variables, which are accessible from all sprites (and Stage), so why not also allow the option to have custom blocks which can be accessed by any sprite (and Stage)?

This is a very popular suggestion which comes up regularly in the forums - here are some examples:
https://scratch.mit.edu/discuss/topic/260
https://scratch.mit.edu/discuss/topic/603
https://scratch.mit.edu/discuss/topic/3748
https://scratch.mit.edu/discuss/topic/6828
https://scratch.mit.edu/discuss/topic/12015
https://scratch.mit.edu/discuss/topic/20077
https://scratch.mit.edu/discuss/topic/37933
https://scratch.mit.edu/discuss/topic/48076
https://scratch.mit.edu/discuss/topic/50278
https://scratch.mit.edu/discuss/topic/58288
https://scratch.mit.edu/discuss/topic/105880
https://scratch.mit.edu/discuss/topic/126462
https://scratch.mit.edu/discuss/topic/130460

Of course, it gains a great deal of support (and why wouldn't it!) - presumably in the hope that the Scratch Team might take notice and so add such a feature.

But the purpose of this post is NOT to *suggest* the idea of global custom blocks (I suspect that might just've been done already, once or twice… ;P) It's to raise the issues and problems with various ways of doing it, in the hope that someone here can come up with something better!

_______________________________________________________________________

Scratch Team support

The reality is that the Scratch Team had certainly considered this long before any of us - in fact while Scratch 2.0 was being developed (before we had even heard of it!)

So, did they not want it? Did they reject it?

No!

Here's (part of) a quote from one of the Scratch Team members:

The Scratch editor design team discussed this extensively when planning for Scratch 2.0. We all agreed that global procedures would be great to have and an important concept, but also recognized the challenges of adding it in a seamless way.

See here for the full context in which above appears: https://github.com/LLK/scratch-flash/issues/782
(BTW, it's actually well worth reading through that discussion if you want to think more about this…)

_______________________________________________________________________

So what's the problem…?

Since it's clear that the ST would like to see this feature, and have known that for a long time, there must be a reason why it's not in Scratch even now.

The reason is that there are several subtleties which are not that obvious until you actually try to consider *how* to implement this feature.

What I will do below is outline a few possible ways to implement this feature, and then, in future posts, cover some of the problems that crop up with each.

_______________________________________________________________________

Different ways to do it

I've included four of the major ways to implement this ‘global custom blocks’ feature - see the linked posts for more detailed thoughts about how they might actually work, along with some of the issues:

• Allow (the option for) custom blocks on the Stage to be accessible by all sprites (similar to global variables) – read more here…

• A new checkbox in the “New/Edit Block” window which, when checked, allows global access from all sprites (and Stage), no matter where that custom block is located – read more here…

• A new checkbox in the “New/Edit Block” window which, when checked, places a copy of that custom block definition in all (selected?) sprites (and stage?) – read more here…

• Provide a separate editing area for global custom blocks (which is a bit like how it works in Snap! / BYOB) – read more here…

_______________________________________________________________________

Issues & questions

In the following posts I will go through each suggestion above, and list some of the issues and questions that arise when trying to implement it. And, yes, sorry, but this does get a bit technical at times…

Another thing of similar nature is why not have the capability to have custom blocks that can be directed towards another sprite, so if you use a custom block called “point towards 90,” in sprite 1 then you can direct it to sprite 2 causing the second sprite to point 90 degrees. There's only one way I've thought of doing this, and that is to add to the script order an imaginary script with the block data that's needed.

DadOfMrLog wrote:

⚠ Warning! -This post is quite long! ⚠
But I've tried to structure it to make it easier to ‘dip into’ the parts you might want to read…

Note that the purpose of this topic is NOT to ask for support (we've had plenty of topics like that already - see below). It's to ask for IDEAS how to make global custom blocks work in an intuitive way, to find alternative ways to do it that will work around some of the issues I raise!
What I'm asking is this… Can YOU think up a better way?

_______________________________________________________________________

Contents

• Introduction

• Scratch Team support

• So what's the problem…?

• Different ways to do it

• Issues & questions (in later posts)

OK, so after reading all of those sections – especially the different ways to do it and their respective posts (of course, I assume you read every word several times, didn't you…? yeah…? right…?) – I'd be curious to know if you have any ideas how to do it better, or how to overcome some of the problems/questions raised.

It'd be really great if some bright spark here could come up with some way to make global custom blocks work that none of us old fogeys have actually yet considered…

_______________________________________________________________________

Introduction

We have global variables, which are accessible from all sprites (and Stage), so why not also allow the option to have custom blocks which can be accessed by any sprite (and Stage)?

This is a very popular suggestion which comes up regularly in the forums - here are some examples:
https://scratch.mit.edu/discuss/topic/260
https://scratch.mit.edu/discuss/topic/603
https://scratch.mit.edu/discuss/topic/3748
https://scratch.mit.edu/discuss/topic/6828
https://scratch.mit.edu/discuss/topic/12015
https://scratch.mit.edu/discuss/topic/20077
https://scratch.mit.edu/discuss/topic/37933
https://scratch.mit.edu/discuss/topic/48076
https://scratch.mit.edu/discuss/topic/50278
https://scratch.mit.edu/discuss/topic/58288
https://scratch.mit.edu/discuss/topic/105880
https://scratch.mit.edu/discuss/topic/126462
https://scratch.mit.edu/discuss/topic/130460

Of course, it gains a great deal of support (and why wouldn't it!) - presumably in the hope that the Scratch Team might take notice and so add such a feature.

But the purpose of this post is NOT to *suggest* the idea of global custom blocks (I suspect that might just've been done already, once or twice… ;P) It's to raise the issues and problems with various ways of doing it, in the hope that someone here can come up with something better!

_______________________________________________________________________

Scratch Team support

The reality is that the Scratch Team had certainly considered this long before any of us - in fact while Scratch 2.0 was being developed (before we had even heard of it!)

So, did they not want it? Did they reject it?

No!

Here's (part of) a quote from one of the Scratch Team members:

The Scratch editor design team discussed this extensively when planning for Scratch 2.0. We all agreed that global procedures would be great to have and an important concept, but also recognized the challenges of adding it in a seamless way.

See here for the full context in which above appears: https://github.com/LLK/scratch-flash/issues/782
(BTW, it's actually well worth reading through that discussion if you want to think more about this…)

_______________________________________________________________________

So what's the problem…?

Since it's clear that the ST would like to see this feature, and have known that for a long time, there must be a reason why it's not in Scratch even now.

The reason is that there are several subtleties which are not that obvious until you actually try to consider *how* to implement this feature.

What I will do below is outline a few possible ways to implement this feature, and then, in future posts, cover some of the problems that crop up with each.

_______________________________________________________________________

Different ways to do it

I've included four of the major ways to implement this ‘global custom blocks’ feature - see the linked posts for more detailed thoughts about how they might actually work, along with some of the issues:

• Allow (the option for) custom blocks on the Stage to be accessible by all sprites (similar to global variables) – read more here…

• A new checkbox in the “New/Edit Block” window which, when checked, allows global access from all sprites (and Stage), no matter where that custom block is located – read more here…

• A new checkbox in the “New/Edit Block” window which, when checked, places a copy of that custom block definition in all (selected?) sprites (and stage?) – read more here…

• Provide a separate editing area for global custom blocks (which is a bit like how it works in Snap! / BYOB) – read more here…

_______________________________________________________________________

Issues & questions

In the following posts I will go through each suggestion above, and list some of the issues and questions that arise when trying to implement it. And, yes, sorry, but this does get a bit technical at times…

Another way they could do this is to store a list of all global blocks, and then whenever a new sprite is created, add a local copy of the block, of course when the original sprite is deleted it will move the global version over to the next sprite in line.

Preface:

Like most of the people that support the idea of adding global custom blocks, I went searching for a way to use a custom block from one sprite in another. I believe that the way I was trying to use custom blocks globally is very different from most of the other users here so I'll first go over how I was trying to use them, and then detail how I think that we could implement them in the way that the majority is describing.

Some definitions for this post:

“GCB” is used as shorthand for "Global Custom Block“

The ”origin“ or ”origin sprite" will be used to refer to the sprite that contains the definition of the GCB.

My Issue:

I was trying to run a custom block from another sprite to create a pen window manager of sorts. The block in question was the block responsible for drawing text from a text engine (-Rex-'s Stamp Text Engine if anyone is curious). It looks something like this:

define SFE | Print Line: Pos (x) (y) Size (s) Angle (a) Bounds (l) (r) Space (cs) Align (ax) (ay) Text (text)

As anyone who has ever peeped inside of one of -Rex-'s text engines will undoubtedly know, it is an absolute jungle of blocks and it slows the editor down significantly. Luckily, the entire text engine is contained within one sprite! Now I just needed to import the sprite and link up several global variables to act as parameters for the custom block and then use a broadcast to run it. This is where the issue occurs. The block runs too slowly to finish drawing the text before the broadcast is sent out again to draw another text element on a different window in that same frame. Usually, you would just make sure to use a “broadcast and wait” block to keep things synchronized but, in my case, each of my sprites already runs all scripts without screen refresh causes a horrible laggy mess while the project tries to wait for the broadcast to finish before continuing.

All I needed from global custom blocks, in this case at least, was the ability to run the custom block from another sprite as that other sprite. This would work similarly to a broadcast that is linked to a custom block from another sprite and can accept the parameters of that block. This way, the block would be able to run custom blocks from another sprite within this one (a "run the x custom block in y sprite with z parameters) block. This is not how most people want global custom blocks to work, however. Most people would likely argue that this is too niche of an issue and that I must be doing something wrong elsewhere if I can't use broadcasts as a workaround. I added this entire section to the top of the post in hopes people would see it and take it into consideration as either another option for GCBs or an essential feature to be added along with them.

As a side note, I just found out that -Rex- actually posted an identical idea on a different thread:

-Rex- wrote:

It would be more useful for sprites to call custom blocks from other sprites, meaning that the custom block would always run in the sprite with its definition, but that the custom block can be used anywhere.

Summary of the Requirements:

There are several great suggested implementations of custom blocks in this thread alone. After looking through some of them, I have done my best to understand what the majority of users want and the problems that could face the developers while implementing this feature. I'll break this up into parts below:

What we want:

As far as I've seen, the most frequently stated “must-haves” of global custom blocks are:

• Access to the custom block from every sprite.
  
• The ability to run a global custom block as the sprite that the instance of the block is in, not the sprite that the definition is located within (contrary to the personal issue I outlined above).
  
• An easy way to create global custom blocks through a checkbox or similar toggle.
  
• Custom blocks should run consistently with the way they run in the origin sprite except in cases where undefined behavior must be avoided.
  

What the Scratch Team doesn't want:

• Blocks with no visible definition in a sprite. This could be confusing and cause frustration if it is difficult to find the definition of a custom block.
  
• Another editor panel. The Scratch Team has made it clear they view adding another panel for editing custom blocks as unnecessary complexity.
  

Problems with global custom blocks:

• GCBs that play a sound or set a costume from the origin sprite
  
• Another editor panel. The Scratch Team has made it clear they view adding another panel for editing custom blocks as unnecessary complexity.
  
• There could be naming conflicts if two GCBs were created with the same name.
  

How to Implement Global Custom Blocks:

Creating GCBs:

In order to cover all of these specifications, we need to first look at where a GCB's definition should be stored and how one should be created. I think it would be best if the block was created in the same way custom blocks are currently created, with a checkbox to specify whether it should exist in the global or local scope. If global is selected, the block would be displayed in the “My Blocks” list of every sprite.

Where do the definitions go?:

The best place for the definitions, if they can't be in a separate panel, would be in the sprite they were created. The problem that arises here is how to stop users from being confused that the definition of the block is not in the sprite. My idea to solve this is to place a definition placeholder block into any sprite where a GCB is used. A definition placeholder block would be a new kind of block that looks identical to the definition block except it would be completely rounded on the bottom (no small nub on the bottom indicating that more blocks can be attached). The placeholder block would not be able to be attached to other blocks, have other blocks attached to it, or be run by clicking on it. The block's only purpose would be to exist in the sprite's scripting pane and when clicked, automatically change sprites and go to the place where the custom block is defined. These definition placeholders would prevent any confusion about where the block's definition is. The placeholder block could also have a button to make a local copy of the GCB but that will be discussed later and the feature this button would implement may be too complex to use for the Scratch Team to support.

Handling sprite-specific assets:

Sprite-specific assets pose one of the greatest challenges to implementing GCBs. Sprites and sounds that belong to the sprite in which the definition was created may not exist in the sprite that is using the GCB. In this case, I propose that the blocks that set costumes and play sounds function as they normally would. The asset-related blocks already have solutions in place in case an input does not directly correspond to an asset name or number. These solutions already pick the best guess at what the user intended or use a default option. This is similar to Snap!'s implementation of GCBs which I have determined after brief testing. This means we don't have to worry about accessing the asset lists of the origin sprite which prevents confusion about where the costume is and how to edit it if the costume is switched to one that resides in another sprite's costume tab.

Handling naming conflicts:

Each GCB requires its own unique name. This really is not an issue at all as long as Scratch sticks to its current method of sprite-specific variable naming. For example, creating a GCB and using “Say Hello” as the name in the sprite “Sprite 1” would create a custom block named “Sprite 1: Say Hello”. This also allows the local form of the custom block to remain and not be confused with the GCB.

Clone behaivior:

No special behavior would be given to clones. If a clone utilizes a GCB in some part of its script, it would be treated like a normal custom block. Local variables would still have their own clone-specific values and global variables would be treated the same.

Local variables:

If the custom block is not called from a clone, its local variable values should act as normal sprite-wide local variables. If the purpose of a custom block is to prevent the repetition of code, there is no need to add extra peculiarity by making local variable values specific to the GCB. If a local variable does not exist in the sprite where a GCB is being used but is required by the GCB, a local variable with the same name should be automatically created in the sprite. This is consistent with the behavior of dragging a custom block from another sprite or the backpack.

To address the case in which a GCB that accesses local variables is used in the stage, I think it makes the most sense to simply create the local variables for the stage. I'm not sure why the stage does not support global variables. Maybe it was because you cannot create clones of the stage and the design team figured stage-specific variable didn't have a point? I read on a separate thread from Maximouse that global variables are internally stored inside of the stage which could explain why all stage variables are global. Despite this, there seems to be no reason for disallowing local variables for the stage that can't be changed, and implementing them would solve issues relating to GCBs.

Changing scope:

While it's relatively simple to convert a custom block to a GCB, converting a GCB to a local custom block may appear to be more challenging which is why I've proposed this final feature to go along with the placeholder block. Each placeholder block would have either a button or a right-click context menu option to “Convert to for this sprite only”. This block would attempt to remove the sprite name prefix from the block name, and remove the placeholder blocks from all other sprites. It would give the standard warning “To delete a block definition, please remove all uses of the block” if the custom block was being used in other sprites.

I am aware that the Scratch Team tends to be against anything that adds more buttons or complexity to the editor, but this is a feature that works as intuitively as global variable deletion and shouldn't be confusing to users.

Wrap Up:

Thank you for taking the time to read my thoughts on the implementation of global custom blocks in Scratch. I may edit this post in the future as I get new ideas although I'll probably write a new one so that this one doesn't get too long. If you have any questions, feel free to ask! I look forward to seeing what happens to this suggestion in the future and will be monitoring this thread in the future.

Support for global custom blocks!

MiniCoder11 wrote:

Maybe it was because you cannot create clones of the stage and the design team figured stage-specific variable didn't have a point?

Let me just say, great post. This is one of the most constructive posts I've seen and I think your idea is amazing too.
-
So, the quote above got me thinking. What would this block do if it was in a different sprite? Would it create a clone of the origin sprite or the sprite the custom block is being played in?

create clone of [myself v]

If it is of the sprite the block is being played in, how would you make it where you could make a clone of the origin sprite. For example, let's say I make a text engine. The text engine is the origin sprite. I only want to make clones of that only, even if the code is being called in a different sprite. Now, how would I do this? I can't use

create clone of [myself v]

because that would create a clone of the sprite that is calling it, and I can't do

create clone of [text engine v]

because when you are editing a block like this you can't select the sprite you are editing, so how?

musicROCKS013 wrote:

If it is of the sprite the block is being played in, how would you make it where you could make a clone of the origin sprite. For example, let's say I make a text engine. The text engine is the origin sprite. I only want to make clones of that only, even if the code is being called in a different sprite. Now, how would I do this? I can't use

create clone of [myself v]

because that would create a clone of the sprite that is calling it, and I can't do

create clone of [text engine v]

because when you are editing a block like this you can't select the sprite you are editing, so how?

That's an excellent point. I think that the GCB should always execute relative to the sprite that it is running in and not the origin sprite. My design choices for the GCB were based around keeping the behavior of a GCB consistent with what would happen if you simply dragged the definition of the custom block into another sprite because that is what I assumed most people would find intuitive.

If a user drags the definition of a custom block into another sprite and its definition contains a “create clone of myself” block, it will create a clone of the sprite running the custom block, not the sprite the definition was dragged from. This is how I think GCBs should work as well. Of course, this would mean that the behavior of the custom block would be different between the origin sprite and the GCB in the running sprite. While this may be where the confusion seems to start, if we look at Scratch's current design, we'll notice that if you go to a separate sprite, change the clone dropdown to “Sprite 1” and then drag that block into “Sprite 1”, the block does keep the setting in the dropdown and you can actually use “create clone of Sprite 1” from within itself. This is obviously a workaround and probably not intuitive for some users, but it is an option nonetheless for making sure the GCB always clones the correct sprite and this option requires no further changes to the editor. Despite this, this is not the solution I'd recommend.

The solution I would recommend which I think could be the best way to approach this problem is that whenever a GCB is being defined and a clone block is dragged into the script, it not only has a “myself” option but also the name of the sprite it is being defined in. This way, it will intuitively support cloning both the origin sprite and the running sprite.

Please feel free to let me know your thoughts about this approach.

what i envision is something similar to the fourth suggestion
sadly costumes are harder to implement on a global scale but sounds could be implemented in a similar manner

essentially, next to the button for the stage would be an option for “global custom blocks”. it has no costumes tab and is only a reference point for sprites. costumes might be interesting but events would be outright disabled and this option would only shown if at least one custom block is global, still keeping the software simple for new users

Banana