Hacked Blocks - Support Argument Hacking

There are many types of “hacked blocks” that are possible in Scratch 2.0. While prior discussions have grouped them all together, we have spent a bunch of time trying to tease apart this landscape so we can understand and hopefully work with the community to support these use cases.

While hacked blocks are uncommon (used by less than 0.01% of shared projects), they are used by some high-profile projects and are interesting to some Scratchers. By far the most common type of hacked block is what we are now referring to as “argument hacking”. This issue attempts to break down this type of hacked block with the hope of soliciting support from the community if they wish for Scratch to continue to support these projects in the future.

Examples

Overriding Menu Options

[
    "keyPressed:",
    "\u0010"
]

Making “Non-Droppable” Menus “Droppable”

[
    "penColor:",
    [
        "readVariable",
        "tmp"
    ]
]

Overriding Custom Procedure Menu Options

[
    "call",
    "colour %c",
    -3384542
]

Use Cases

By far the most commonly seen types of “Argument Hacking” are “Overriding Menu Options” and “Making ‘Non-Droppable’ Menus ‘Droppable’”. In all cases the project JSON is modified to override the arguments for a given opcode. While specific use cases vary from project to project and block to block, we often see this type of modification performed to support applications such as supporting non-standard keyboard events and dynamically controlling “non-droppable” state.

Example Project

https://llk.github.io/scratch-gui/develop/#214566447

Uncaught Error: Serialized variable type with id '}o/;i5r,O`;[HD478%k?-readVariable,scratch' had type list, and does not match variable field that references it: <field xmlns="http://www.w3.org/1999/xhtml" name="VARIABLE" id="}o/;i5r,O`;[HD478%k?-readVariable,scratch" variabletype="">readVariable,scratch</field>.
    at Object.Blockly.Xml.domToFieldVariable_ (lib.min.js:90)
    at Object.Blockly.Xml.domToField_ (lib.min.js:90)
    at Object.Blockly.Xml.domToBlockHeadless_ (lib.min.js:90)
    at Object.Blockly.Xml.domToBlockHeadless_ (lib.min.js:90)
    at Object.Blockly.Xml.domToBlock (lib.min.js:90)
    at Object.Blockly.Xml.domToWorkspace (lib.min.js:90)
    at Object.Blockly.Xml.clearWorkspaceAndLoadFromXml (lib.min.js:90)
    at t.value (lib.min.js:90)
    at t.l (lib.min.js:1)
    at t.n.emit (lib.min.js:12)
    at t.value (lib.min.js:12)
    at t.value (lib.min.js:12)
    at t.value (lib.min.js:132)
    at Object.l [as onClick] (lib.min.js:1)
    at t.value (lib.min.js:90)
    at l (lib.min.js:1)
    at Object.u (lib.min.js:98)
    at Object.invokeGuardedCallback (lib.min.js:106)
    at Object.invokeGuardedCallbackAndCatchFirstError (lib.min.js:106)
    at f (lib.min.js:98)
    at m (lib.min.js:98)
    at b (lib.min.js:98)
    at Array.forEach (<anonymous>)
    at A (lib.min.js:98)
    at w (lib.min.js:98)
    at Jl (lib.min.js:106)
    at Se (lib.min.js:98)
    at batchedUpdates (lib.min.js:98)
    at $ (lib.min.js:98)
    at Te (lib.min.js:98)
    at HTMLDocument.d (raven.js:425)

/cc @kchadha

[djsrv]

As someone who’s worked with hacked blocks extensively in the past, I can say that most of these have few real use case besides being curiosities.

I think instead of (or in addition to) supporting these hacks, it would be better to provide official methods of doing the things they enable. Hacked blocks have the disadvantage of being difficult to understand and impossible for a regular user to replicate.

Here are two common use cases for argument hacking and how they could be eliminated.

Non-standard key events

Common non-standard key events are shift, backspace, and escape. This could be eliminated by simply adding the keys to the key menu. 😃 Since they wouldn’t be used as often as the existing options, maybe they could be added to the bottom of the menu?

Variable variables

This hack is used to set/get arbitrary variables, similar to PHP’s variable variables. The need for this hack could be eliminated by adding dictionaries in addition to lists. This would be easier to understand than the hack, and it’s almost certainly a better programming practice. Maybe this could be added as an extension similar to pen?

[thisandagain]

@Mr-Dave2 I certainly wouldn’t describe the Scratch Team as an “army of programmers” … perhaps a “merry band of programmers”? Point is our team is quite small given the size of product we support (each engineer on the Scratch Team supports ~25 million kids each year). While the most common use case for argument hacking is scheduled to be resolved (the “when key pressed” hat block and “key pressed” boolean reporter) many others are not.

I do not believe it is reasonable to expect the Scratch Team to support all forms of hacked blocks. Those projects which are not supported may not work in Scratch 3.0 and I believe that is a reasonable expectation for projects that were created outside of the Scratch editor. To your point I do think we’ll need to communicate this clearly to the community as we get closer to launch.

That said, I understand that some of these use cases matter deeply to the community (and for the record I think many of them are really neat!). For many of those – as discussed by others in this thread – I’d be more than happy to discuss proposals for how to resolve them and review pull requests which extend support. I hope that helps clarify. 😄