Scratch Plus Extension

[wasdafor]

Hi TurboWarp team,

This extension might not check all the "Good extension" boxes for you guys. But that aside this extension can be of great use for a lot of scratchers that just whish that Scratch had a couple of extra useful blocks to help them in their development journey.

This extension adds more than 80 blocks to the vanilla Scratch block palette. These block range from more looks to adding custom timers.

And lastly, the cherry on the cake and the main point of this extension. Scratch Plus supports compilation back into vanilla Scratch blocks, unlocking more possibilities than ever. Now you can develop your games in a fast TurboWarp environment with new custom blocks, but still keep the possibility to compile and upload your project to the Scratch website.

The compilation options van be found at multiple places, first of all at the bottom of the Scratch Plus palette multiple compile options can be found.

These same compilation options can also be found under the main menu option file.

The extension and compiler van be found in the same file to comply with the extension standard.

[SharkPool-SP]

I highly doubt this would be merged because of the amount of patches with scratchblocks, and the fact that the majority of these blocks exist in their relative extensions in our gallery.

Ie, comments, more timers, more motion, etc.

[wasdafor]

@SharkPool-SP

Yeah those points are valid, but it is all about the compilation, that adds new depth. Maybe a subset could be added, that would still add value?

[SharkPool-SP]

@SharkPool-SP

Yeah those points are valid, but it is all about the compilation, that adds new depth. Maybe a subset could be added, that would still add value?

The issue is that the compiler is still a work in progress. Updates are constantly happening to it. Additionally there is a new version of the compiler (which would break compatibility with old patches) which is being slowly worked on.

Maintaining a working version of the compiled blocks will be an issue. You'd have to ask garbomuffin on his opinion on that.

From what I've seen (old prs and this code), this is too unmaintainable

[wasdafor]

@SharkPool-SP

Yeah those points are valid, but it is all about the compilation, that adds new depth. Maybe a subset could be added, that would still add value?

The issue is that the compiler is still a work in progress. Updates are constantly happening to it. Additionally there is a new version of the compiler (which would break compatibility with old patches) which is being slowly worked on.

Maintaining a working version of the compiled blocks will be an issue. You'd have to ask garbomuffin on his opinion on that.

From what I've seen (old prs and this code), this is too unmaintainable

I do think there are problems, but the compiler is custom written.

Next to that the compiled and custom version of the blocks are made to be as close as possible and would likely never get large or any changes.

I do not have a lot of knowledge about the internal workings of Scratch or TurboWarp. But I do believe some of the ideas or part of extension could be a valuable addition.

[SharkPool-SP]

@SharkPool-SP
Yeah those points are valid, but it is all about the compilation, that adds new depth. Maybe a subset could be added, that would still add value?

The issue is that the compiler is still a work in progress. Updates are constantly happening to it. Additionally there is a new version of the compiler (which would break compatibility with old patches) which is being slowly worked on.
Maintaining a working version of the compiled blocks will be an issue. You'd have to ask garbomuffin on his opinion on that.
From what I've seen (old prs and this code), this is too unmaintainable

I do think there are problems, but the compiler is custom written.

Next to that the compiled and custom version of the blocks are made to be as close as possible and would likely never get large or any changes.

I do not have a lot of knowledge about the internal workings of Scratch or TurboWarp. But I do believe some of the ideas or part of extension could be a valuable addition.

oh. Regardless, this is a excessive and unnecessary amount of patching when it can easily be creating with existing extension APIs.

• this is not an actual Compiler (ie, its not the same as the Turbowarp Compiler, so it will still run in a compatibility mode)
• once again, a lot of these blocks in existing extensions

[WAYLIVES]

Oh, it's a very useful extension, but I'm afraid it won't make it to the TurboWarp gallery because it has too many blocks. In addition, this "Scratch Plus" extension does not open in TurboWarp Desktop, which is very important 🥹

[wasdafor]

@SharkPool-SP

Its all about the compilation back to Scratch block, yes there is a lot of overlap with other extensions, that is on purpose and unavoidable, but allows for the most flexibility.

And yes this is definitely a compiler, a compiler just compiles one set of instructions to another.

I do not see a lot of maintenance, maybe problems around the the ScratchVm and StratchBlocks api's could arise, but I do not suspect with the blocks them self.

Again this is a full package deal, maybe we can settle with a subset of the blocks.

I really do think a lot of Scratchers could really use an extension like this.

[wasdafor]

Oh, it's a very useful extension, but I'm afraid it won't make it to the TurboWarp gallery because it has too many blocks. In addition, this "Scratch Plus" extension does not open in TurboWarp Desktop, which is very important 🥹

The desktop part might be something for me to look into. The to many blocks is a different problem.

But feel free to use the extension in its current form.

[NexusKitten]

A few things

1. I'm not sure if we're allowed to use the word "Scratch" in extension names. I made an extension a while ago that had the Scratch logo in the thumbnail and I was asked to change it-- I'd assume that since the name is transformative the same would apply here.
2. As @SharkPool-SP said, extensions that patch the coding interface are usually not accepted-- too many things can go wrong, especially with large patches such as the ones seen in this extension.
3. Also as @SharkPool-SP said, there might be too many blocks in this extension for the TurboWarp gallery. We don't exactly have a block limit, but there's a precedent set that extensions should generally follow a specific theme. I'd recommend reading CONTRIBUTING.md for more information, specifically what it says about "Utility" extensions.

Don't get me wrong, this extension looks pretty awesome and you're free to host it on your own website/github repository, however it's not the type of thing we typically see added to the turbowarp extension gallery.

[SharkPool-SP]

A few things

1. I'm not sure if we're allowed to use the word "Scratch" in extension names. I made an extension a while ago that had the Scratch logo in the thumbnail and I was asked to change it-- I'd assume that since the name is transformative the same would apply here.

2. As @SharkPool-SP said, extensions that patch the coding interface are usually not accepted-- too many things can go wrong, especially with large patches such as the ones seen in this extension.

3. Also as @SharkPool-SP said, there might be too many blocks in this extension for the TurboWarp gallery. We don't exactly have a block limit, but there's a precedent set that extensions should generally follow a specific theme. I'd recommend reading CONTRIBUTING.md for more information, specifically what it says about "Utility" extensions.

Don't get me wrong, this extension looks pretty awesome and you're free to host it on your own website/github repository, however it's not the type of thing we typically see added to the turbowarp extension gallery.

I didn't say there's too many blocks, I said the majority of blocks here are present in their own relative extension

[wasdafor]

@NexusKitten

You have some great and valid points there:

1. The name is open for change, this was just the coolest and most fitting name I came up with. But "Blocks Plus" or something similar would work aswell.
2. I agree, editing the coding iterface is asking for problems, with that in mind I added the extension buttons for when this would come up.
3. I did read the markdown file and have considered the section about utility and overlapping extensions, but I hope that the compilation adds enough value to overrule the recommendation. If not that we could come up with a subset of blocks that still might add enough value for the extensions library.

Self hosting would be hard becuase it is an unsanboxed extension that only works on the TurboWarp domain or localhost:8000. But if that could be bypassed would definitely be a cool second option.

Thanks for the feedback.

[yuri-kiss]

For what this is, this is not worth the insane amount of effort that would be required to maintain it, you are also in violation the the Scratch trademark as said above.

Patches should not be used, even if it is a user togglable thing, they cause to many issues, and a brand new compiler built into an extension is just going to mean even more effort trying to keep MULTIPLE compilers working correctly.

I am marking this as draft and getting @GarboMuffin to get a say in this.

[wasdafor]

For what this is, this is not worth the insane amount of effort that would be required to maintain it, you are also in violation the the Scratch trademark as said above.

Patches should not be used, even if it is a user togglable thing, they cause to many issues, and a brand new compiler built into an extension is just going to mean even more effort trying to keep MULTIPLE compilers working correctly.

I am marking this as draft and getting @GarboMuffin to get a say in this.

Any idea in what timeframe I could expect a final verdict from @GarboMuffin?

[yuri-kiss]

For what this is, this is not worth the insane amount of effort that would be required to maintain it, you are also in violation the the Scratch trademark as said above.
Patches should not be used, even if it is a user togglable thing, they cause to many issues, and a brand new compiler built into an extension is just going to mean even more effort trying to keep MULTIPLE compilers working correctly.
I am marking this as draft and getting @GarboMuffin to get a say in this.

Any idea in what timeframe I could expect a final verdict from @GarboMuffin?

Knowing his schedule either a few days to a few months

[SharkPool-SP]

after looking at this again, it would be a more reasonable idea to scrap everything except the compile blocks.

You could just make the extension have wrapper blocks that keep or remove 'extension blocks' (non-base category) when saved.

[wasdafor]

after looking at this again, it would be a more reasonable idea to scrap everything except the compile blocks.

You could just make the extension have wrapper blocks that keep or remove 'extension blocks' (non-base category) when saved.

For now I will just wait for @GarboMuffin his reply, after that we could look at other solutions if the current state of the extension is not something TurboWarp needs.

[yuri-kiss]

after looking at this again, it would be a more reasonable idea to scrap everything except the compile blocks.
You could just make the extension have wrapper blocks that keep or remove 'extension blocks' (non-base category) when saved.

For now I will just wait for @GarboMuffin his reply, after that we could look at other solutions if the current state of the extension is not something TurboWarp needs.

good move, thanks for submitting your extension even if some stuff might end up getting cut.

and side note, its pretty cool what your doing, just some stuff is iffy in production like this,
cant wait to see what else might come

[Brackets-Coder]

I'm confused. Is this supposed to let us create projects with custom extensions in Turbowarp, compile them back into a native scratch format, and upload / share them on the Scratch website as unsandboxed without turbowarp?

[CST1229]

I'm confused. Is this supposed to let us create projects with custom extensions in Turbowarp, compile them back into a native scratch format, and upload / share them on the Scratch website as unsandboxed without turbowarp?

i assume this extension adds its own blocks that compile to scratch-compatible code (that can run in the vanilla scratch player), but cannot compile other unsandboxed extensions

[Brackets-Coder]

I'm confused. Is this supposed to let us create projects with custom extensions in Turbowarp, compile them back into a native scratch format, and upload / share them on the Scratch website as unsandboxed without turbowarp?

i assume this extension adds its own blocks that compile to scratch-compatible code (that can run in the vanilla scratch player), but cannot compile other unsandboxed extensions

I think I figured that out.