Starstriker3000 wrote:

For my Warriors games, I used to have a “hacked” block, allowing the player to run when the CTRL key was pressed. I liked it, because the CTRL buttons are placed right next to both the WASD keys and the arrow keys. However, when Scratch 3.0 came out, the ability to use “hacked” blocks was removed, and I had to (and still have to, XD) change the run key in my game. Please bring back “hacked” blocks! I'm pretty sure others who depended on the use of “hacked” blocks for some of their projects will agree with me.

Agreed

No support.

Hacked blocks were never created or endorsed by the Scratch Team. Whenever someone decides to hack Scratch, there is always the risk of Scratch updating so that the hacks are no longer supported.

As a result, I don't think the Scratch Team is responsible for hacking their own interface, or for providing support for such blocks. Perhaps they could just add a “when CTRL pressed” block without the need to hack the system.

I don't think such a thing is a priority at the moment, though.

You may find these helpful for a little clarification
https://scratch.mit.edu/discuss/topic/341058/
https://scratch.mit.edu/discuss/topic/341062/

This would be quite useful, but I feel like the Scratch team doesn’t have any plans to bring the back.

there goes the custom undertale battle creator then

cs9999999999 wrote:

there goes the custom undertale battle creator then

Yeah, a lot of complex projects got broken

I think there'd be some trouble with using the control key in your project in particular, because if you move up by pressing W while you're holding down control, well… then you'd end up closing the browser tab! (Control + W is a keyboard shortcut for closing a tab, and it's not even technically possible for Scratch 3.0 to prevent that from happening.)

I really think shift should be an option in the key-pressed menu, though. There aren't any browser keyboard shortcuts that happen from just pressing shift and a letter/number, so it could be used as a key in Scratch projects.

No support.

Some hacked blocks have an easy solution, or solutions that were implemented in 3.0. While I realise that popular games are broken without them, there might be a workaround.

Za-Chary wrote:

No support.

Hacked blocks were never created or endorsed by the Scratch Team. Whenever someone decides to hack Scratch, there is always the risk of Scratch updating so that the hacks are no longer supported.

When the Scratch Team says that every 2.0 project will be compatible with 3.0, I except that a feature as widely-used as hacked blocks to be compatible with 3.0. They're even featured projects with hacked blocks multiple times before.

As a result, I don't think the Scratch Team is responsible for hacking their own interface,

This quote is meaningless since this doesn't have much to do with the interface and this suggestion suggests allowing users to “hack” their projects.

without the need to hack the system.

Again, this really isn't hacking the system. All that hacked blocks used to require was modifying the internal JSON project of a file, which does not require any extra software (except for perhaps a good text editor), is easy, and is predictable.

-Rex- wrote:

Again, this really isn't hacking the system. All that hacked blocks used to require was modifying the internal JSON project of a file, which does not require any extra software (except for perhaps a good text editor), is easy, and is predictable.

…and also was never supported by the Scratch Team. Not to say I'm definitely frustrated by hacked projects being so utterly broken as they are (especially since this issue hasn't apparently gone anywhere yet); but we were never guaranteed that hacked blocks would work in future updates to Scratch.

For what it's relevant, bringing back hacked argument slots (i.e. putting blocks in inputs that don't normally accept blocks) is a help-wanted feature, meaning they'd be interested in accepting community effort to write the code that adds it back. But, well, it's a very complicated thing to add, since Scratch 3.0 non-droppable inputs really aren't built to accept blocks at all.

_nix wrote:

For what it's relevant, bringing back hacked argument slots (i.e. putting blocks in inputs that don't normally accept blocks) is a help-wanted feature, meaning they'd be interested in accepting community effort to write the code that adds it back. But, well, it's a very complicated thing to add, since Scratch 3.0 non-droppable inputs really aren't built to accept blocks at all.

To me it seems that modifying scratchblocks and adding a few hashtable/map/objects for each sprite with variable and list names and UIDs should be enough (this way only one or two extra values would have to be changed when renaming variables), though I don't know very much about how the VM works and I'm not sure which specific files would have to be modified.

-Rex- wrote:

_nix wrote:

For what it's relevant, bringing back hacked argument slots (i.e. putting blocks in inputs that don't normally accept blocks) is a help-wanted feature, meaning they'd be interested in accepting community effort to write the code that adds it back. But, well, it's a very complicated thing to add, since Scratch 3.0 non-droppable inputs really aren't built to accept blocks at all.

To me it seems that modifying scratchblocks and adding a few hashtable/map/objects for each sprite with variable and list names and UIDs should be enough (this way only one or two extra values would have to be changed when renaming variables), though I don't know very much about how the VM works and I'm not sure which specific files would have to be modified.

I think you're interpreting the problem as there not being a mapping between variable names and variable IDs, so hacked blocks that tweak variable names and IDs wouldn't work..? As it turns out, there actually is such a mapping basically – those blocks would work… if it weren't for the problem of how hacked blocks import into Scratch 3.0:



That was from attempting to import this script:

when green flag clicked
say ((join [vol] [ume]) of [Stage v])

And nobody's exactly sure how to fix that..until someone does, we're stuck.

_nix wrote:

-Rex- wrote:

_nix wrote:

For what it's relevant, bringing back hacked argument slots (i.e. putting blocks in inputs that don't normally accept blocks) is a help-wanted feature, meaning they'd be interested in accepting community effort to write the code that adds it back. But, well, it's a very complicated thing to add, since Scratch 3.0 non-droppable inputs really aren't built to accept blocks at all.

To me it seems that modifying scratchblocks and adding a few hashtable/map/objects for each sprite with variable and list names and UIDs should be enough (this way only one or two extra values would have to be changed when renaming variables), though I don't know very much about how the VM works and I'm not sure which specific files would have to be modified.

I think you're interpreting the problem as there not being a mapping between variable names and variable IDs, so hacked blocks that tweak variable names and IDs wouldn't work..? As it turns out, there actually is such a mapping basically – those blocks would work… if it weren't for the problem of how hacked blocks import into Scratch 3.0:



That was from attempting to import this script:

when green flag clicked
say ((join [vol] [ume]) of [Stage v])

And nobody's exactly sure how to fix that..until someone does, we're stuck.

Wouldn't this involve adding shadow (whatever they are, I'm still not entirely sure) support to fields in the VM, scratchblocks, and the sb2 converter (converting blocks in fields as well)?

-Rex- wrote:

_nix wrote:

-snip-
..until someone does, we're stuck.

Wouldn't this involve adding shadow (whatever they are, I'm still not entirely sure) support to fields in the VM, scratchblocks, and the sb2 converter (converting blocks in fields as well)?

Yeah, I think so… honestly, I'm not as sure on the details as I'd like to be. That's the basic idea, but I'm not sure how easily you could implement it. For one, Scratch 3.0's file format doesn't even have support for putting blocks in place of fields (see also this issue), so we couldn't even import projects with hacked blocks without modifying the save file format (AKA, not easy, since we also have to avoid breaking existing projects).

Then we have to figure out how to modify scratch-blocks (you should call it that, BTW, not “scratchblocks” – that way we don't get it confused with the [scratchblocks] forum plugin) to somehow support putting blocks in place of fields. (The VM, too, like you mentioned, otherwise those blocks won't get evaluated properly.) That's the part that's the most daunting to me – but mainly because I have no idea how shadow blocks and fields and inputs really all work together…
(edit: formatting)