Blocks for individual mouse buttons down

[GarboMuffin]

• left
• right
• middle

[MiniCoder11]

I definitely support this one 😃

[GarboMuffin]

this exists now

hopelessly incompatible with Scratch, of course

[MiniCoder11]

hopelessly incompatible with Scratch, of course

@GarboMuffin

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?".

[GarboMuffin]

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.

[MiniCoder11]

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.

[GarboMuffin]

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