Looking for suggestions how to do global custom blocks better

Ger77

DadOfMrLog wrote:
Provide a separate editing area for global custom blocks…

Thank you for your post. As I new started at Scratch this month and use the platform for a special project I have the same problem. Why the [rem] is it not possible to use blocks in other sprites? Why have to copy into any? After reading all the discussions about this I understand it is not so easy to implement as it seems to me first. Scratch! is great! I am a long time programmer and use several languages to create my ideas. But with Scratch! I found a framework that restrict me to the essentials, what is perfect for me.

Scratch! is great and fulfill all the requirements for a easy programming for kids to adults. As far I see it is only this part missing we discuss now here. The Global blocks (=GB)
But why then the absence of such important feature? If there is a kid that would lean how to program, it is a must not to overload it with possibilities Therefore the idea of global blocks and the needed abstraction to handle them could make it to hard to understand the concept of this.
In my opinion the GB should only have one function. To allow to make subroutines for manipulation global data. Because that is the only part that could separate without interaction with all other. If there would be allowed to create a GB for the behavior of sprites, the implications are extreme. This was discussed a long time and nothing more to say.
But for the problems of substrings, combining elements, create long text with variables and a lot more, the GB would be the perfect solution. The separate area is a MUST to avoid that someone (a beginner) try to copy a sprite command as ;

switch backdrop to [ something ]

or

 change pen shade by (5)

etc. in a global block in the stage. In this area are should only available blocks of lists, variables,control, operators and events. Nothing else. Any block that belongs to motion, pen, sound, look or sensing could not used because that would produce a lot of impacts for the implementation.

Finally there would be great to have such area for creating a lot of tools to handle data with routines. As an example I use this block in the hole area of my project, because I could extract with this positions from a list where I stored them in the form of “+138_-034 Home_Kind”. For using in e.g

glide () secs to x: (0) y: (0)

for sprites. To make a simple “set it to x y” I create a custom block

define Set ActPos XY <element> 
newstr = letters  (1) to (4) of (element)::custom  
set [ActPosX v] to (element)
newstr = letters  (6) to (9) of (element)::custom  
set [ActPosY v] to (element)

therefore I could use it as

 Set ActPos XY ( item (1) of  [locations v])::custom

BUT — if I want to use these substring function in other sprites I have to copy this costum block and the complex custom block “newstr = letters” made by @TheLogFather in all this areas. Thats not so funny and make it difficult to change the blocks later without to forget one of the copies also to change. And I think this is very hard for beginners to avoid such mistakes therefore they don't create it in this way. What a lot of ideas let die

.

To cut a long story short. It would be great such Global blocks area have available in a project. So we could reuse tons of methods in our projects that create other Scratchers. As I did with only one of the block

 newstr = letters  () to () of ()::custom

from here: https://scratch.mit.edu/projects/18838153

Thanx in advance to the Scratch Developer Team if it makes this wish come true.

Last edited by Harakou (April 10, 2016 01:05:01)

BurnedCrystal

DadOfMrLog wrote:
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…
_______________________________________________________________________

Mmmm

The problem with the first is, as mentioned, the potential block deficiencies

The second would make it a pain to find block definitions in larger projects (which is the only place where one would really use global cutsom blocks) if you didn't know where they were

The third sounds less like actual global blocks and more like a rapid placement utility ono

And the fourth is essentially perfect, as long as you are unable to run the blocks inside of the separate editing area itself. Also if this were the case all blocks within the global area should be adorned with a globe-type symbol :v

Last edited by BurnedCrystal (April 9, 2016 17:04:03)

A block idea or whatever.

go [in front of v] sprite [sprite1 v] :: looks

Wow, this is a really empty sig. needs some defining features… ah!
Have a RAINBOW :)

Ger77

BurnedCrystal wrote:
And the fourth is essentially perfect, as long as you are unable to run the blocks inside of the separate editing area itself. Also if this were the case all blocks within the global area should be adorned with a globe-type symbol :v

For me I see the problem, that a lot of unwanted interactions have to avoid in implementation if there are could created for behavior of sprites in motion, sensing or look. Also with using of pen methods on the stage. I see only the possibility to handle the global data (lists and variables) with this.
But this would enough, because the most of the time are only such subroutines are global needed. Reusing of such functions would be very easy with this new feature.

 do anything with (variables) for stage and all sprites::custom

BurnedCrystal

Ger77 wrote:
BurnedCrystal wrote:
And the fourth is essentially perfect, as long as you are unable to run the blocks inside of the separate editing area itself. Also if this were the case all blocks within the global area should be adorned with a globe-type symbol :v
For me I see the problem, that a lot of unwanted interactions have to avoid in implementation if there are could created for behavior of sprites in motion, sensing or look. Also with using of pen methods on the stage. I see only the possibility to handle the global data (lists and variables) with this.
But this would enough, because the most of the time are only such subroutines are global needed. Reusing of such functions would be very easy with this new feature.
 do anything with (variables) for stage and all sprites::custom

Hmmm

Pen with stage just wouldn't draw, or the X and Y position of the drawing would be 0 so that shouldn't be a problem

That block I'm not sure I understand, though. Could you elaborate?

A block idea or whatever.

go [in front of v] sprite [sprite1 v] :: looks

Wow, this is a really empty sig. needs some defining features… ah!
Have a RAINBOW :)

Ger77

BurnedCrystal wrote:
Hmmm
Pen with stage just wouldn't draw, or the X and Y position of the drawing would be 0 so that shouldn't be a problem

That block I'm not sure I understand, though. Could you elaborate?

Pen is used also with sprites. Therefore it could produce in global used custom blocks a lot of side affects.

Elaborate? Of course, I try (sorry for my weak English. I am not a native speaker

)
The example is based on a list like this:

Each entry represent the position in the stage with the x and y where a sprite could be set. If we now need to set a sprite to a specific position, we have only to split this text in the list entries in two parts. The @TheLogFather has provide a custom block that put a part of a string in the global variable (newstr)

newstr = letters  (1) to (4) of (element)::custom //extract four characters of element and store it in newstr
set [ActPosX v] to (newstr)
newstr = letters  (5) to (9) of (element)::custom //extract second four characters of element and store it in newstr
set [ActPosY v] to (newstr)
go to x: (ActPosX) y: (ActPosY)

Two of this custom block with 1 to 4 and 5 to 9 will do the work. After this sprite is set to this position.

This local custom block “newstr O letters” has to be copied in any sprite where this function is needed. If this were a global custom block the code would also for beginners easier to handle but add not more complexity to Scratch! because the only difference would be that this blocks are available in the hole project. I read a many of suggestion are point to string handling. This would be the solution for them all.

Hope I have explain it now a little better. The target is to help kids and beginners to keep the code more easier to manage.

Last edited by Ger77 (April 9, 2016 22:08:44)

BurnedCrystal

Ger77 wrote:
BurnedCrystal wrote:
Hmmm
Pen with stage just wouldn't draw, or the X and Y position of the drawing would be 0 so that shouldn't be a problem

That block I'm not sure I understand, though. Could you elaborate?
Pen is used also with sprites. Therefore it could produce in global used custom blocks a lot of side affects.

Elaborate? Of course, I try (sorry for my weak English. I am not a native speaker )
The example is based on a list like this:

Each entry represent the position in the stage with the x and y where a sprite could be set. If we now need to set a sprite to a specific position, we have only to split this text in the list entries in two parts. The @TheLogFather has provide a custom block that put a part of a string in the global variable (newstr)
newstr = letters  (1) to (4) of (element)::custom //extract four characters of element and store it in newstr
set [ActPosX v] to (newstr)
newstr = letters  (5) to (9) of (element)::custom //extract second four characters of element and store it in newstr
set [ActPosY v] to (newstr)
go to x: (ActPosX) y: (ActPosY)
Two of this custom block with 1 to 4 and 5 to 9 will do the work. After this sprite is set to this position.

This local custom block “newstr O letters” has to be copied in any sprite where this function is needed. If this were a global custom block the code would also for beginners easier to handle but add not more complexity to Scratch! because the only difference would be that this blocks are available in the hole project. I read a many of suggestion are point to string handling. This would be the solution for them all.

Hope I have explain it now a little better. The target is to help kids and beginners to keep the code more easier to manage.

I see where you're going, but I disagree with the whole ‘custom blocks for string manipulation thing’. Some of them should just be default blocks anyways, since they're pretty important blocks, although with the intended usage of scratch (which is sprite based) I can see why they're not :^

A block idea or whatever.

go [in front of v] sprite [sprite1 v] :: looks

Wow, this is a really empty sig. needs some defining features… ah!
Have a RAINBOW :)

Ger77

BurnedCrystal wrote:
I see where you're going, but I disagree with the whole ‘custom blocks for string manipulation thing’. Some of them should just be default blocks anyways, since they're pretty important blocks, although with the intended usage of scratch (which is sprite based) I can see why they're not :^

The reason why a whole blocks for string manipulation are not default, so far as I seen, is that Scratch! is not mainly for creating, it is for education of programming. For kids and beginners. And they should understand the basics of such complexer operations like manipulation of strings.If there would able to reuse global custom blocks they could look inside the function. On default blocks this is not possible. And if anyone you go deeper and deeper into programming then this person should switch to Snap! where all this is default.

And there is a misunderstanding of the restriction that I suggest for global blocks. The string manipulation is only a part of this possibilities. If we could combine operators, variables, lists and event blocks and could use this in global blocks there are tons of methods that could created.

But it force the Scratchers! to use this global blocks only in a abstract way. Like the positions with X and Y coordinates on the stage. It is not a sprite and it is not the stage itself. Its are objects without optical representation but have to handle as they would such.

Hope this makes more clear why I think that only the manipulation of data in combination with events should be allowed. Events are also global. Therefore they interact not more now as they will do in future global blocks.

Last edited by Ger77 (April 10, 2016 00:02:43)

jokebookservice1

My solution is to use a checkbox for globality. But it would not be global in the sense you have all been thinking about, it would just be a broadcast that accepts arguments. Yes, this is not optimal, but it has lots of uses, for example, cloud list encoders require arguments from different sprites, but require each sprite to set a few global variables and broadcasting before the definition script can run. This is what I would like when I say I want global definitions.

However, to solve the “real” global definitions, as suggested before, a new thumbnail could appear next to the stage. The Scratch team rejected this because they wanted you to be able to test the scripts instantly, but there could be a sprite that would be assigned to this, to allow live testing. The editor of this new thumbnail would not allow mentions of sounds or costumes, and any instance where this occurs (by a script being dragged into it from a sprite), the code would execute it as normal (if you drag blocks into the stage and run them , Scratch handles it, and I want it to handle it the same). However, the editor would only allow global and cloud variables, and would not contain costume or recording blocks.

Thank you for reading, and sorry for the accidental bump

Scratch-Minion

I don't have a brain the size of a planet and am out of my depth here, but I'll write a few thoughts anyway - hope they are not too disjointed.
And maybe it may spark others with ideas. (and the topic gets bumped).

I suggest the idea of Global Blocks being a different colour (that's how we spell color in NZ) in the list of blocks.
Then programmers could immediately see that these were global blocks. (similar to lists and variables being different colours).

Sprites could have blocks with the same name as a global block!
They would be distinguished by different colours so there is no confusion to the programmer which block is being called. If a block is dragged from a sprite into the global script area (options 1 or 4) then a prompt could ask - local, global or cancel.
The default would be local (stops existing projects being broken). Some blocks in the “global script area” will be local anyway as they would only be called by global blocks.

When a global block is created, the programmer must change any calls of an existing block of the same name to use the new global block. (This would also stop existing projects being broken).

I really like Ger77's idea that not everything can be global!

I think Option 4 is possible, however, and Motion and Pen commands could be included with the proviso that these Motion and Pen commands only act on this global sprite, not the original calling sprites. Thus the calling sprites must supply Position, Pen Width, Color information etc as arguments to the global blocks in the global sprite that does the drawing.
(Any costume changes could only change costumes of the global sprite)

For example: You could make a global block/script to draw a rectangle which can be called from anywhere but it is the global sprite which has to be positioned and moved to do the drawing.
Another example: You could do a global collision detection, but you would need to pass the position and costume name of the calling sprite to the global sprite which would be moved to that position, put on the costume (which the programmer must have already added to the global sprite - I know this is a limitation but implementation would be easier) and then check if the global sprite has collided with something.

Only global variables should show in the global area (and the local variables to the global area). No local variables from other sprites should be visible.

Return values from global blocks rather than having to use global variables would be good.

Last edited by Scratch-Minion (April 18, 2016 02:44:15)

..Scratch Movie.. ..Scratch Memes.. Scratch Cat Dash ..FPC? Not Me!.. Scratch Dictionary Animal Hangman

Studios:

3D Tutorials, Polyhedra, 1 Line Challenge, Mandelbrot Art Challenge, Op Art Challenge

Ger77

I have made a concept study for the “GLOBAL blocks” and create a project for this, that I want discuss with you.
https://scratch.mit.edu/projects/107734026

In this project I use a block with a complex script in other sprites. For this I pass the parameters to the GLOBAL_Block (GB) with local variables of the specific sprite. In the “Global area” for each sprite the process of the GB is protected through use a clone for this. Because each clone has it own local variables and so the process could run simultaneously without conflicts.
The only weak part is the use of the global variables. And one problem seems to be the pass of the parameters. If two call of the “Global Block” nearly in the same time, the block is not processed. To avoid this I maid a little delay before the broadcast (for discuss such advanced aspect of this I opened another topic: https://scratch.mit.edu/discuss/topic/196889/ )

The workaround shows me that “Global Blocks” could implemented if the restrictions of an extra area (my sprite GLOBAL) and that is not possible to use motion, look, sound or pen blocks in this blocks are also implemented. But one big problem is that it is not easy to understand for beginners, that such a block deliver different values to each sprite which call the GB. Therefore it is needed to have a easy understandable method to take this value from the GLOBAL area. The simple return of values like the < > of < >.

SET speak for (%speakID) with (%speakRepl)
set [%text v] to ( GLOBAL [speaktext v] for this sprite::sensing ) // Make this clear that the value is only for this sprite?

This problem seems the real hurdle, because Scratch! should a language for beginners. What do you think? Is this concept - of calling a block that deliver different values depending from which sprite it is called - a possible implementation? One of the main part is to understand that this GBs are not the same as a call of a function. Its only the reuse of blocks without to have the same script for them in many sprites.
It would avoid a lot of errors that normally happens if there are redundant scripts. Every time the script have to be changed the change has to be done in all sprites where it is copied in. That is a problem that not make it easier for beginners. Instead of this it produce frustration.

Last edited by Ger77 (May 2, 2016 21:55:15)

Jonathan50

bobbybee wrote:
This is a little messy, and unforunately an extension of the 4th one, but I think it solves all the issues in a mature manner (although raising more!):

Employ prototypical inheritance patterns. Next to Stage (on top of it?), there is Sprite. Anything here is automatically everywhere but the stage. This could include block definitinos that are not cleanly global, but also a wealth of other possibilities, like:
when this sprite clicked
say (join (join (x position) [, ]) (y position))
Now you have a magical new feature where you can click anything to find its position, which could be useful for debugging or something.

I don't know. Maybe it'll confuse new scratchers too much. But it seems like if someone could make a neater version of this metaphor, it would solve this problem (and make a lot of other awesome features!) with relative ease. (This would be fairly trivial to implement compared to something like linked definitions.)

Thoughts (=criticisms)?
~Alyssa

Nice idea. And clones should be OOP too, like in Snap!.

Not yet a Knight of the Mu Calculus.

superben100

MathlyCat wrote:
I actually read through everything…

Phew.

I'm gonna put it short: S. U. P. P. O. R. T.

What's there not to like

Me too.

Hello there!
I've been a Scratcher for nine years now, and I'm always happy to help!
I'm not around too often, but I check in here from time to time.
Let me know if you need anything!
|| Probably vibing to “Try” - Lawrence ||

jokebookservice1

Edited out +

Also, may I summarize my post. I would like to have custom blocks more as broadcasts that accept arguments. And those “broadcasts” can only be received by 1 sprite that created the block. Useful for CloudList engines for example.

Last edited by jokebookservice1 (Dec. 22, 2017 14:17:04)

Ger77

After a lot of experiences in Scratch! I come to following conclusion about GLOBAL Blocks.
There is no way for global blocks. Instead of this I suggest the corresponding blocks (CB).

EDIT: Moved to a seperate topic as suggestion:
https://scratch.mit.edu/discuss/topic/211739/?

Last edited by Ger77 (Aug. 3, 2016 08:35:27)

Charles12310

Looks like you got your support!

A few internet communication companies want to corrupt the internet by getting rid of net neutrality. Stop Them!

Sheep_maker

Charles12310 wrote:
Looks like you got your support!

What are you supporting? This is a topic for ideas on how to implement an already unanimously supported suggestion:

DadOfMrLog wrote:
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?

- Sheep_maker This is a kumquat-free signature. :P
This is my signature. It appears below all my posts. Discuss it on my profile, not the forums. Here's how to make your own.
.postsignature { overflow: auto; } .scratchblocks { overflow-x: auto; overflow-y: hidden; }

Mr_PenguinAlex

edit: turns out i was dumb a year ago

Last edited by Mr_PenguinAlex (June 13, 2020 20:36:22)

Raven_Singularity

I read the original posts, and think things are being overly complicated.

In terms of which sprite the variables etc. apply to when using a custom block, it should simply internally expand the custom block code at that spot, as if all the pieces had been inserted there verbatim.

Conceptually I think it would be good to place these global custom blocks into the backdrops code areas, or have a new tab up top.

About the tabs at the top, I really don't like how the tabs change based on what you have clicked down below, such as Backdrop or Sprite. GUIs that change their layout like that are a nightmare to use, they needlessly complicate things, and are less efficient. Tools shouldn't be hiding themselves when you want to use them. Quick access is king for tools. It's really unclear how to access a tool when it's invisible. It's far better that your tools are always available in the same consistent place. Easier for children and adults alike. I think it should always show the Code, Costumes, Sounds, Backdrops, etc.

For the editing of code blocks, you could add a new tab called “Blocks” to house the global blocks. Or better yet, just have an (Edit) or (+) button built into the block itself. When clicked it expands to allow you to edit the global code directly. This is clear and easy to understand.

Functions are such an integral part of learning to program, they should really be available in Scratch. When I discovered subroutines in QuickBASIC, I was blown away with how efficient and easy to use they were. Aim for the same with Scratch. Functions are at the heart of programming efficiency and time-saving automation. Being able to code something once, and reuse it a thousand times. Complex code reduced it to a single function name (and maybe some parameters). It's a bit horrifying how much repetition happens in Scratch due to this missing feature.

Also, the GUI makes it really difficult to duplicate code. While right-click Duplicate works fine, dragging code blocks to other sprites is very error prone. Often the GUI goes crazy because dragging the item to the sprite list will cause it to produce a scrollbar, and the scrollbar causes the highlighted item to move, which unhighlights it, and then the scrollbar disappears… repeat forever at high speed. The CSS should be changed to always show a scrollbar in that list, which will avoid the strobing glitch. It literally makes it impossible to drag code blocks to other sprites without first rearranging the order of the sprites to avoid the strobing.

Last edited by Raven_Singularity (June 13, 2020 05:48:19)

gosoccerboy5

DadOfMrLog wrote:
First suggestion:

Allow (the option for) custom blocks on the Stage to be accessible by all sprites…
This idea is probably the most obvious, since it is so similar to the way that global variables work on the Stage.

However, here are some points to consider:
There are a number of important blocks which are not available (directly) from the Stage, because they don't apply to the stage. For example, it has no motion blocks, since it can't move; there are various sensor blocks missing, such as the touching blocks and ‘distance to’; there are no pen blocks (except ‘clear’); many of the ‘Looks’ blocks are missing (e.g. say/think/show/hide/size); etc., etc…
Would global custom block scripts have to use only global variables? Note that if only global vars are ‘allowed’, this would make it hard to use global custom blocks ‘concurrently’ from different sprites, since any time one of them changes a global var, it'll change for the others too - you can't use the same ‘counter’ type var from two sprites at the same time… (BTW, you really don't want to see the horrible mess that results if you try to use a pre-existing sprite-only variable in the Stage…)
How does costume-switching work? (This is also a more general consideration for any implementation of global custom blocks - but I guess you'd have to either avoid it, or make sure you named/numbered the costumes consistently across sprites that use the global custom block…)

Well, you can backpack a motion script and put it into the Stage. If you make that mistake it's your fault. Same goes for global custom blocks.

Costume switching? I suppose it would read the number id of the costume then translate that into costumes for that sprite.

Full support

Duchisan

define while ()

end

set volume to (Nothing) %
Error::#ff0000custom

Wait, what?

Discuss Scratch