Comments (6)
I understand most of your reasoning for not continuing to add blocks except for the following (there is a chance that I am misinterpreting the wording of your reasons so feel free to correct any misunderstandings I may have):
It limits possibilities - By abusing argument reporters, it's not clear how to make blocks that extract the color of a pixel on the screen, implement matrix operations, activate/deactivate turbo mode, etc. Making a new category of blocks that can actually have inputs and dropdowns is necessary for these things. (Not promising to add blocks that do any of that)
This one mostly makes sense. This part is not clear:
it's not clear how to make blocks that extract the color of a pixel on the screen, implement matrix operations, activate/deactivate turbo mode, etc. Making a new category of blocks that can actually have inputs and dropdowns is necessary for these things.
It would seem to me that using custom blocks is the best way to remain in compatibility with Scratch. Making a new category of blocks doesn't seem to be necessary as long as you used regular custom blocks to do the same thing as the new blocks in that category. For example, getting the color of a pixel on the screen could be done by creating a new custom block called something like: tw_getColor (in1) (in2)
. Although we would have the empty definition hat floating around, we could always hide it or, in projects created in TurboWarp, they could be exported with the shadow JSON trick to make them invisible and out of the way. Although dropdowns are not an option in vanilla Scratch, thorough documentation would allow us to just type values into in1
, in2
, etc. to achieve the same effect.
Furthermore, using a consistent format for the naming of custom blocks like "tw", then an underscore, then the camel-case function name, then string inputs labeled with "in" and then the number of the input would make it easy to remember how to create and use these custom blocks in addition to not conflicting with any custom block names that a regular Scratch user is likely to create.
Onto your second point about the terms of service stating that only native Scratch projects are allowed to run in Scratch. This does not affect what I am assuming to be the "standard use-case" of TurboWarp in any way (although I do not have any of the analytic information that you do so I may be mistaken on this point). As far as I am aware, most people use TurboWarp mainly for its compiler and use it as a faster project player. If I am correct about this, that would mean that most projects opened in TurboWarp were created in Scratch, not the other way around. As long as the custom block can be created in Scratch, it should not matter to the Scratch Team if it works or not because it was created in the normal Scratch editor. Even though it may not do anything in Scratch, there are likely tens of thousands of projects on Scratch with nonfunctional custom blocks and these are no different as far as the Scratch team is concerned because if they do not perform any function that could affect a Scratch project in a way normal blocks cannot, they are not a moderation hazard to the Scratch Team.
For the language reason, I understand that there is no way to translate TurboWarp custom blocks in Scratch, but this is not as much of an issue as it may seem. Although this is brought up all the time as an important accessibility feature, in Scratch, it is much less useful. It works very well in the editor to the creator of the project, but then its point is defeated to those viewing it. The notes, descriptions, custom block names, variable names, sprite names, costume names, string inputs, and project names are never translated leaving projects written in languages you do not understand to be almost uneditable. This means that as long as you expand the database of valid custom-block names to accept their translated variants on the TurboWarp editor, users of Scratch that are viewing the project will not have any less accessibility than the default Scratch custom block names provide, while project-creators of different languages will still be able to input custom block names that they understand.
As a final note, I'd just like to say that all of the statements I have just made have a large possibility of being incorrect if I misunderstood your reasons earlier. In addition, the statements above are all based on my idea of the way TurboWarp is most commonly used. While writing this comment, I have based my ideas on the assumption that TurboWarp is intended to run Scratch projects but not act as a replacement to Scratch. Any reasoning over confusion to new users has also been avoided in the statements because simplicity makes Scratch stand out but also holds it back while TurboWarp being less focused on simplicity allows us to do more with it.
from scratch-vm.
I definitely support this one 😃
from scratch-vm.
this exists now
hopelessly incompatible with Scratch, of course
from scratch-vm.
hopelessly incompatible with Scratch, of course
Are you sure that there isn't any way to make it a custom boolean block such as "secondary mouse button down?" so that we can create the block in Scratch projects even if they don't work natively in Scratch? Then at least we would be able to save projects with the block and include links to the TurboWarp project page where they would actually function. We don't really need the "left mouse button down?" block and so it would only add two blocks to the TurboWarp section: "secondary mouse button down?" and "middle mouse button down?".
from scratch-vm.
It's possible, but I think that the method of adding new blocks by abusing argument reporters is flawed and it's not something I want to continue to do.
- It confuses users - A lot of people see "pink block that reports value" and assume that it's a crazy hacked custom block that found a way to report a value then get confused when it doesn't work in Scratch.
- It limits possibilities - By abusing argument reporters, it's not clear how to make blocks that extract the color of a pixel on the screen, implement matrix operations, activate/deactivate turbo mode, etc. Making a new category of blocks that can actually have inputs and dropdowns is necessary for these things. (Not promising to add blocks that do any of that)
- There's this line in the Scratch Terms of Use - "4.4 You may only submit user-generated projects that were created with (1) the Scratch website editor or (2) an unmodified copy of the Scratch editor compiled from the source code described in Section 5.3. You may not upload any projects that were created, by you or by anyone else, with a modified version of the Scratch editor." It's very unlikely that this will (or can) be enforced as literally anything made in a modified Scratch editor (as far as Scratch can tell, a project made in TW that doesn't use TW blocks may as well have been made in Scratch) but if a lot of projects start using blocks that come from a mod and only work in that mod, they might start enforcing it. Remember, Scratch does not have unlimited time and money to store and moderate these projects. Using a custom category means that those projects shouldn't even be able to load into Scratch at all.
- Argument reporters can't be translated into languages other than English.
- "mouse down?" and "left mouse button down?" are not redundant - it's possible for the standard mouse down to report false while the left mouse button is still down
I'm open to being convinced otherwise about this.
Maybe I'll add a "secondary mouse button down?" as an argument reporter anyways. I don't know.
from scratch-vm.
I'm closing this issue because blocks for individual mouse buttons being pressed was added. The discussion of whether to implement Scratch-compatible-ish reporter blocks for this has moved to #44
from scratch-vm.
Related Issues (20)
- about util.ioQuery HOT 3
- pen optimisation HOT 3
- Upload To Scratch HOT 4
- Weird Blocks HOT 3
- Custom Reporters - I dunno if this is my fault, but this makes no sense HOT 3
- Broadcasts get compiled dynamically HOT 8
- Suggestion: Compile broadcasts once per project start HOT 4
- Bug: `util.thread.peekStack()` is not working properly when there are nested reporters
- Compiler's waitPromise soft-lock if promise handlers executed immediately HOT 2
- New Argument: Block HOT 4
- vm crash HOT 2
- Global blockUtility HOT 4
- Native sb3fix integration
- Custom reporters can hang browser in certain situations. HOT 2
- Compiler Support HOT 3
- Request: Allow unlimited cloud variables on unpackaged projects. HOT 4
- Glide-to blocks don't pause when a project is paused
- Optimize namesOfCostumesAndSounds
- Procedure variant by argument types
- Optimize getSpriteTargetByName HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from scratch-vm.