Discuss Scratch

_Paymer
Scratcher
500+ posts

Modules - Extensible, Integrable Scripts

Modules
  • Extensible and integrable scripts, easy installation into your project
  • Act as normal sprites until loaded as modules into other projects
  • Prevent variable scope collisions, remove clutter, use premade functions to save implementation time
  • Easy and intuitive for beginners to understand, a kid-friendly version of package managers
How would it work?
  • “Create Module” button makes the current sprite a module then prompts the module name. “Delete Module” button makes the sprite a normal sprite.
  • “Add Module” to import modules from other projects.
  • List of installed modules with delete buttons, and a URL input for a Scratch project ID and module name. Red light next to the module name means the project was unshared, grace period to find a new module.
  • Installed modules list with parent project links appear by clicking the Modules extension on the project page
  • Each project can host up to 3 modules and use 10 modules
  • When saving to computer, it asks the user if they want to package the modules directly into the sb3 file or as a URL pointer (e.g. scratch.mit.edu/modules/project-id/module-name)
Parent Sprite Blocks
load (cloud-list v)  :: extension // Loads the module

when (cloud-list v) loaded :: extension hat // Runs code when module is loaded

([variable v] of (cloud-list v) :: extension) // Variable of module

([add_entry v] [parameter] of (cloud-list v) :: extension) // Activates function returning a value

<[add_entry v] [parameter] of (cloud-list v) :: extension> // Activates function returning a boolean

give control of sprite [this sprite v] to module (platformer-physics v) :: extension // Hands over control of the sprite, such as movement, costume management and code execution to the module

stop control of module (platformer-physics v) over [this sprite v] :: extension // Stops the module from controlling the sprite
Module Blocks
set [ v] to [] // Set to sprite only and running as module

change [ v] by (0) // Set to sprite only and running as module

when this module loads :: extension hat

define add_entry::extension hat // define appears as module colour if exposed as a module function when creating the block

define (add_entry (parameter)) :: extension hat

define <add_entry (parameter)> :: extension hat

return [thing] :: extension cap

parent sprite [move v] (10) :: extension // Executes operations in parent sprite when control is given: move, change x, change y, go to, direction, costume, effects, sound, sound effects

<controlling parent sprite? :: extension>

<running as module? :: extension>
Examples
Modules could be used to easily install cloud lists, authentication systems, cloud variable interfaces, encoders and platformer scripts into your project. They would create an intuitive interface for package installation and management.
FAQ
Q: Backpacks already exist?
A: When importing a sprite from your backpack, you have to configure it to fit into your project, which can be time consuming, increase project size greatly when loading in the website, and divert attention away from the core design of the project.
Q: Too complex
A: Read the suggestion. There could be a guide button on how to use modules, and it would be an extension anyway.
Q: Just make the custom blocks available for all sprites
A: You would still have to rewire the library into your project, just less sprites you need to copy the connector functions to.

Last edited by _Paymer (Aug. 20, 2026 08:19:07)

BitcoinFarmer
Scratcher
1000+ posts

Modules - Extensible, Integrable Scripts

Can't you just backpack things already? Also how about variables are they shared?
Sorry but this seems weird.
-1
_Paymer
Scratcher
500+ posts

Modules - Extensible, Integrable Scripts

BitcoinFarmer wrote:

Can't you just backpack things already? Also how about variables are they shared?
Sorry but this seems weird.
-1

Sigton wrote:

Secondly, I'm also disliking the fact people are jumping to conclusions about suggestions. People are picking out the smallest reason to down a suggestion, or just downing a suggestion simply because they don't understand it. For example, I saw this:
Anonymous wrote:

I have no idea what you're asking for. No support until further notice.
This isn't even asking for an explanation before making a conclusion. It was in fact this quote that finally drove me to making this topic. It added nothing to the discussion, and just downed the suggestion before even having the basic knowledge about it to draw a decent conclusion.

Please read the suggestion, and if you don't understand it, ask for clarification.
BitcoinFarmer
Scratcher
1000+ posts

Modules - Extensible, Integrable Scripts

I don't agree here. The entire suggestion is kind of hard to read but I am giving my best and I feel like this feature would be chaotic and hard to understand rather than intuitive.
Are they scripts or sprites?
Write like an intro to them, a tutorial on how to use them if they existed maybe. That might help explaining.
Are their functions custom blocks? So is it basically sprites with custom blocks for everyone?
If sprites, will they appear in the sprite list?
Will they be saved into the project you want to add them to?
If we can clarify what you want a bit more, maybe we can discuss this better.
CodeComet6161
Scratcher
1000+ posts

Modules - Extensible, Integrable Scripts

No support.
1. Scripts that crash Scratch
2.

BitcoinFarmer wrote:

Can't you just backpack things already? Also how about variables are they shared?
Sorry but this seems weird.
-1
3. Too complex, even for an extension.
_Paymer
Scratcher
500+ posts

Modules - Extensible, Integrable Scripts

CodeComet6161 wrote:

No support.
1. Scripts that crash Scratch
2.

BitcoinFarmer wrote:

Can't you just backpack things already? Also how about variables are they shared?
Sorry but this seems weird.
-1
3. Too complex, even for an extension.
1. Projects that store modules like crash scripts are still normal projects, the user can just go to the project storing the crash module and report it and also report the project using the module
2. Backpacking makes integration into your project more complex, and you have to rewire the functions into APIs or broadcasts. Variables are not shared between the sprite and module, the module has its own variables but can set the variable of the parent sprite using normal variable blocks if given control
3. There's a chance the other 95 million users using Scratch don't see a simple kid-friendly version of a package manager as too complex. Also
([tan v] of (9)::operators)
You know the drill
_Paymer
Scratcher
500+ posts

Modules - Extensible, Integrable Scripts

BitcoinFarmer wrote:

I don't agree here. The entire suggestion is kind of hard to read but I am giving my best and I feel like this feature would be chaotic and hard to understand rather than intuitive.
Are they scripts or sprites?
Write like an intro to them, a tutorial on how to use them if they existed maybe. That might help explaining.
Are their functions custom blocks? So is it basically sprites with custom blocks for everyone?
If sprites, will they appear in the sprite list?
Will they be saved into the project you want to add them to?
If we can clarify what you want a bit more, maybe we can discuss this better.
1. Scripts
2. Maybe for people that still get confused
3. Their functions work like custom blocks, but they aren't just sprites with custom blocks for everyone as they run in the project while not directly existing as a sprite
4. No
5. They will be saved into the project as metadata pointing to the actual module code in the module project
0_009
Scratcher
1000+ posts

Modules - Extensible, Integrable Scripts

This post was too long, I didn't read

Last edited by 0_009 (Feb. 24, 2026 07:23:46)

_Paymer
Scratcher
500+ posts

Modules - Extensible, Integrable Scripts

0_009 wrote:

This post was too long, I didn't read
Fixed
BitcoinFarmer
Scratcher
1000+ posts

Modules - Extensible, Integrable Scripts

How do you want to make it that you can give a module values and let it give values back?
Variables are named differently in every project.
_Paymer
Scratcher
500+ posts

Modules - Extensible, Integrable Scripts

BitcoinFarmer wrote:

How do you want to make it that you can give a module values and let it give values back?
Variables are named differently in every project.
Now functions are reporters and can return values
_Paymer
Scratcher
500+ posts

Modules - Extensible, Integrable Scripts

forever
bring :: custom
this :: motion
topic [https://scratch.mit.edu/discuss/topic/868641/] :: events
up :: operators
end
kkidslogin
Scratcher
1000+ posts

Modules - Extensible, Integrable Scripts

I love the idea of a library linker for Scratch. Something I feel that Scratch has been missing is the easy ability to use other people's code; it's nearly impossible to interface other code (unless it is designed to) and is always having variable scope collisions. Something like this would make it much simpler, faster, more streamlined, and would accelerate “imagine, program, share” much more than an AI assistant!

_Paymer wrote:

(#18)
When the arguments are countered, the suggestion is ignored forever
Untrue
_Paymer
Scratcher
500+ posts

Modules - Extensible, Integrable Scripts

kkidslogin wrote:

I love the idea of a library linker for Scratch. Something I feel that Scratch has been missing is the easy ability to use other people's code; it's nearly impossible to interface other code (unless it is designed to) and is always having variable scope collisions. Something like this would make it much simpler, faster, more streamlined, and would accelerate “imagine, program, share” much more than an AI assistant!

_Paymer wrote:

(#18)
When the arguments are countered, the suggestion is ignored forever
Untrue
Exact
_Paymer
Scratcher
500+ posts

Modules - Extensible, Integrable Scripts

Buts
Blobfish_Industries
Scratcher
100+ posts

Modules - Extensible, Integrable Scripts

It feels like you want to take a feature that doesn't belong in Scratch, and add it to Scratch. While it would be cool for advanced users, most Scratchers would either find it all too confusing, or never need it. Backpacking already exists, and works fine for most use cases. I can't think of any instances where this would be better than backpacking. Furthermore, what if the module is modified and no longer works? Well now your project no longer works. Backpacking does not have this problem. If the backpacked code doesn't work for your use case, than modify it. I think that modules are cool, but not something Scratch needs right now.
_Paymer
Scratcher
500+ posts

Modules - Extensible, Integrable Scripts

Blobfish_Industries wrote:

It feels like you want to take a feature that doesn't belong in Scratch, and add it to Scratch. While it would be cool for advanced users, most Scratchers would either find it all too confusing, or never need it. Backpacking already exists, and works fine for most use cases. I can't think of any instances where this would be better than backpacking. Furthermore, what if the module is modified and no longer works? Well now your project no longer works. Backpacking does not have this problem. If the backpacked code doesn't work for your use case, than modify it. I think that modules are cool, but not something Scratch needs right now.
You completely ignored the use cases and features to make it beginner-friendly in the OP. There are many situations this module system could be applied, and it would introduce beginners to real package managers in programming languages like npm. Backpacking clutters your backpack and simply just adding the sprite you want to your project makes it harder to bind to your project. For example, if you wanted both a cloud list and a multiplayer system, you would have to adapt it to your project's sprites, costumes, etc. Simply just modifying the code is actually harder for beginners. And the modules changing over time is actually beneficial, for example if a module you are using is very slow and the owner makes optimizations to make it faster, you would not have to backpack the sprite and rebind everything to your project again.
_Paymer
Scratcher
500+ posts

Modules - Extensible, Integrable Scripts

When the counter-arguments are countered, the suggestion is ignored forever
I_wantasheep
Scratcher
1000+ posts

Modules - Extensible, Integrable Scripts

difference between this and custom blocks?
_Paymer
Scratcher
500+ posts

Modules - Extensible, Integrable Scripts

I_wantasheep wrote:

difference between this and custom blocks?
It is a kid-friendly version of a package manager, not custom blocks. The difference is self-explanatory

Powered by DjangoBB