YEAH! This is definitely needed, I'm making a game that spawns enemies but has many different types of enemies, this would be so useful!!!

I SUPPORT x 10

bumb

Support, this would really be nice to be added. I could use this in my project, and so also more people can use it too. I hope this will be implemented soon.

code
game
dont eat
dont sleep
repeat

I agree, basically sometimes there’s a long and hard block I define, but then I need to use it on another sprite so then I make like 5 variables to copy the block, it’s a stupid solution but yes this should exist

Obviously support this, but more to the point:

TheLogFather wrote:

I posted this on another thread (on the same subject): https://scratch.mit.edu/discuss/post/1828250/

As I said there, the issue is not one of support, etc., but of how to implement it.

I've already reported the other topic to be closed as a duplicate, and I'm tempted to ask for this to be closed, and instead to have a topic which is asking for suggestions *how* to implement this (rather than just suggesting it).

First off, the fact that you can drag a custom block into another sprite and have it show there is misleading and creates confusion as to why the code won't run. If nothing else, custom blocks should not appear under other sprites and display an X or similar notification if you try to do so.

Secondly, There are multiple ways sharing blocks could be done. I would like to see a discussion on different ways it could be implemented and the issues that each method would have to overcome. There are numerous supporters for this feature, so let's figure out what it would take to make it happen. A couple of ideas:

1) People have already suggested an option to share with all sprites and seems like the most logical and preferred method. Some issues/solutions that have been pointed out already:
Issue: When exporting the shared block isn't located inside that sprite.
Solution: This could be solved by exporting linked blocks as well.
Issue: Duplicate naming issues.
Solution: Check for and don't allow duplicate names for shared blocks.

2) Have a dedicated area for shared blocks where they can be edited. They can be copied into individual sprites where they would display the original code but could edited from the main area and all other copies are updated. This would still create multiple copies but at least allow for quick changes to all blocks at once, not requiring deletion of the old and new copies of the changed ones.
Issue: Not allowing editing of the blocks in each sprite would likely cause confusing.
Issue: Still multiple copies in each block that give the appearance of reusing code. May create bad habits of code duplication & still takes up work space.
Issue: Requires a new section to be created specifically for shared blocks.

The second idea just popped into my head and I don't even like it, but for the sake of “no stupid ideas” I'll leave it here. I'd like to hear what the issues are with the first method that the team has so we can work as a community to overcome these.

Nevermind. I started reading through this thread and the GitHub discussion and now I understand more of the issues behind it's implementation. Also, I see that the issue was closed a few years back, assuming that it's no longer being considered for inclusion. I still believe that it would be a very beneficial addition and feel that the discussions came to a realistic implementation into Scratch. There were downsides to placing global blocks into the scene, but I think the benefits would heavily out-weight the negatives (no access to sprite movements, etc) and even those could likely be overcome with clever programming.

+1

Tynker.com has it, but Tynker.com sucks, so +1!!

when green flag clicked
set [Program I used to use v] to [Tynker]
set [Program I'm messing with v] to [Scratch]
set [Program I'm learning now v] to [Unity]
say [Procrastinating Unity a bit, because it kinda.. won't run...]

alexluzzi wrote:

insert quote here

when green flag clicked
change [evil apples v] by (-1)
add [thanks] to [list v]
move (stop game) steps

also use scratch collection for older scratch versions

Heers a workaround. put a custom blocks on all sprites. But you have to change each custom block son sprite, SUPPOT

move ()ewd steps
move (aw) steps
move (w) steps
move (dewd) steps
move () steps
move (wad) steps
move () steps
move () steps
move () steps

I have a project with I think 30+ sprites and I want to make a block for all of them.

How would these work with local variables?


Actually, now that I think about it, having it change per sprite might lead to some interesting things.

Support!!!

redspacecat wrote:

Support!!!

Can you explain why?

alexluzzi wrote:

alexluzzi wrote:

insert quote here

when green flag clicked
change [evil apples v] by (-1)
add [thanks] to [list v]
move (stop game) steps

also use scratch collection for older scratch versions

Idk but I think that might be a browser extension, I’m not sure

You can just drag the block into other sprites

when green flag clicked
forever
stay up until 1am questioning my existence
end

Support, less time consuming.

eikh2 wrote:

Support, less time consuming.

Also would be nice for run without screen refresh and inputs

{what method did you use::control hat
answer on profile ::motion
} ::operators

Typically, to avoid duplicating scripts, I group all sprites that share the same script into a single sprite, and then use cloning to create “virtual” sprites.

I support it too!
Like when I make blocks that I need every sprite to have it is VERY annoying to REMAKE this (idk why I can‘t copy-paste code from one sprite to another)