You're misinterpreting the Terms of Use by suggesting that section 4.4 was intended to ban all and any hacked blocks (as I've already told you in a comment reply).

Rather, AFAICT, the intention was to do two things:
1) prevent projects being shared that would break how the player shows the project in the editor, and/or how it plays (maybe even exploiting something to cause it to crash, etc.)
2) prevent projects being shared that can cause confusion to Scratchers, because they contain blocks that don't make sense.

There are various hacked blocks that clearly fall into the second category, and I'd not want to use those in projects.


However, there are also certain hacked blocks that actually *make perfect sense*, and Scratchers even *expect* them to work (and are somewhat surprised and disappointed when they don't).

In such cases, the confusion is not caused because the functionality of such a block is unclear. The confusion is actually caused by Scratch itself, in that it doesn't currently allow them to be made (directly) within the editor!


I made a mod to Scratch quite some time back which allows certain blocks to be placed where the standard Scratch editor doesn't currently allow (for example, dropping a var/expression into left side of a blue “_ of _” sensor block; or the right side of “video _ on _”; or perhaps even into a blue “key _ pressed?” sensor block).

At some point I'll be updating that so it works with the current Scratch source, and I'll submit it as a pull request on the Scratch github site. That will help to remove some of the confusion caused by use of (certain) ‘hacked’ blocks, because they will no longer be ‘hacked’…

system64 wrote:

I see no reason to ban hacked blocks as they are useful for projects, and aren't banned by the terms of use. Many times in my projects lag was caused because use of workarounds to hacked blocks, and they don't harm the community in anyway. As long as projects that include hacked blocks remain unshared there is no problem with hacked blocks.

Exactly. Force all hacked blocks out of the community.

DadOfMrLog wrote:

You're misinterpreting the Terms of Use by suggesting that section 4.4 was intended to ban all and any hacked blocks (as I've already told you in a comment reply).

Rather, AFAICT, the intention was to do two things:
1) prevent projects being shared that would break how the player shows the project in the editor, and/or how it plays (maybe even exploiting something to cause it to crash, etc.)
2) prevent projects being shared that can cause confusion to Scratchers, because they contain blocks that don't make sense.

There are various hacked blocks that clearly fall into the second category, and I'd not want to use those in projects.


However, there are also certain hacked blocks that actually *make perfect sense*, and Scratchers even *expect* them to work (and are somewhat surprised and disappointed when they don't).

In such cases, the confusion is not caused because the functionality of such a block is unclear. The confusion is actually caused by Scratch itself, in that it doesn't currently allow them to be made (directly) within the editor!


I made a mod to Scratch quite some time back which allows certain blocks to be placed where the standard Scratch editor doesn't currently allow (for example, dropping a var/expression into left side of a blue “_ of _” sensor block; or the right side of “video _ on _”; or even into a blue “key _ pressed?” sensor block).

At some point I'll be updating that so it works with the current Scratch source, and I'll submit it as a pull request on the Scratch github site. That will help to remove some of the confusion caused by use of (certain) hacked blocks.

Well, not just misinterpreting… I'm favorably interpreting the terms of use so that I can use them as support for my side.

braxbroscratcher wrote:

Well, not just misinterpreting… I'm favorably interpreting the terms of use so that I can use them as support for my side.

Surely the interpretation we take should be guided by what the Scratch Team originally had in mind when penning those words…?

And it's clear from things Lightnin said at the time that they were not originally intending to target all ‘hacked’ blocks.

That's why I wrote the first part above – because we do have a somewhat clearer idea, based on his comments, of what they were targetting with that phrase, and therefore it gives some guidance on how it's meant to be interpreted.

Also, it's not to say that certain hacked blocks can't fall foul of that phrase in 4.4 – I've already made it clear that I think they do.

I guess what I'm saying is that it's not up to us how this should be interpreted. It's really up to the ST.

Now, perhaps the ST have somewhat changed their minds on this, and have decided that the ToU doesn't allow for any kind of ‘hacked’ blocks at all. But I see no evidence of that, given how many projects do contain such things. (Even some containing hacked blocks which I'd think do much more clearly break the ToU.) Until we do see such evidence, I don't understand how we could think the ST intend us to interpret 4.4 in the way you're suggesting!

braxbroscratcher wrote:

Exactly. Force all hacked blocks out of the community.

As I've said, it's the Scratch editor itself that causes the confusion, not (certain, sensible) ‘hacked’ blocks. – Does that mean Scratch itself is breaking the spirit of its own ToU?! ;P
Consequently, I'll be pushing for the opposite… that (certain, sensible) hacked blocks become no longer ‘hacked’.

DadOfMrLog wrote:

Consequently, I'll be pushing for the opposite… that (certain, sensible) hacked blocks become no longer ‘hacked’.

Thank you, I've been wanting this. I support being able to put variables in dropdowns where usually not possible, (eg. key __ pressed? boolean) and basically everything that “hacked” blocks do.

Scratcher1002 wrote:

DadOfMrLog wrote:

Consequently, I'll be pushing for the opposite… that (certain, sensible) hacked blocks become no longer ‘hacked’.

Thank you, I've been wanting this. I support being able to put variables in dropdowns where usually not possible, (eg. key __ pressed? boolean) and basically everything that “hacked” blocks do.

I want that too. Either that or ban em.

braxbroscratcher wrote:

Scratcher1002 wrote:

DadOfMrLog wrote:

Consequently, I'll be pushing for the opposite… that (certain, sensible) hacked blocks become no longer ‘hacked’.

Thank you, I've been wanting this. I support being able to put variables in dropdowns where usually not possible, (eg. key __ pressed? boolean) and basically everything that “hacked” blocks do.

I want that too. Either that or ban em.

Banning them would make a lot of sense, because what are people going to do? Why hack more in an attempt to bypass the system. I don't support banning them, but rather, beefing up security on the JSON files, and allowing us to

Me wrote:

put variables in dropdowns where usually not possible, (eg. key __ pressed? boolean) and basically everything that “hacked” blocks do.

braxbroscratcher wrote:

Scratcher1002 wrote:

DadOfMrLog wrote:

Consequently, I'll be pushing for the opposite… that (certain, sensible) hacked blocks become no longer ‘hacked’.

Thank you, I've been wanting this. I support being able to put variables in dropdowns where usually not possible, (eg. key __ pressed? boolean) and basically everything that “hacked” blocks do.

I want that too. Either that or ban em.

“I want that, but if they're not implemented, make it impossible for everyone else to have!”

Firedrake969 wrote:

braxbroscratcher wrote:

Scratcher1002 wrote:

DadOfMrLog wrote:

Consequently, I'll be pushing for the opposite… that (certain, sensible) hacked blocks become no longer ‘hacked’.

Thank you, I've been wanting this. I support being able to put variables in dropdowns where usually not possible, (eg. key __ pressed? boolean) and basically everything that “hacked” blocks do.

I want that too. Either that or ban em.

“I want that, but if they're not implemented, make it impossible for everyone else to have!”

With how commonplace they are, the ST might as well add support for them.

braxbroscratcher wrote:

Firedrake969 wrote:

braxbroscratcher wrote:

Scratcher1002 wrote:

DadOfMrLog wrote:

Consequently, I'll be pushing for the opposite… that (certain, sensible) hacked blocks become no longer ‘hacked’.

Thank you, I've been wanting this. I support being able to put variables in dropdowns where usually not possible, (eg. key __ pressed? boolean) and basically everything that “hacked” blocks do.

I want that too. Either that or ban em.

“I want that, but if they're not implemented, make it impossible for everyone else to have!”

With how commonplace they are, the ST might as well add support for them.

“With all the car thefts, we might as well make it legal.”

Firedrake969 wrote:

braxbroscratcher wrote:

Firedrake969 wrote:

braxbroscratcher wrote:

Scratcher1002 wrote:

DadOfMrLog wrote:

Consequently, I'll be pushing for the opposite… that (certain, sensible) hacked blocks become no longer ‘hacked’.

Thank you, I've been wanting this. I support being able to put variables in dropdowns where usually not possible, (eg. key __ pressed? boolean) and basically everything that “hacked” blocks do.

I want that too. Either that or ban em.

“I want that, but if they're not implemented, make it impossible for everyone else to have!”

With how commonplace they are, the ST might as well add support for them.

“With all the car thefts, we might as well make it legal.”

Now that's different. Car thefts are bad - hacked blocks are not necessarily so.

braxbroscratcher wrote:

Firedrake969 wrote:

braxbroscratcher wrote:

Firedrake969 wrote:

braxbroscratcher wrote:

Scratcher1002 wrote:

DadOfMrLog wrote:

Consequently, I'll be pushing for the opposite… that (certain, sensible) hacked blocks become no longer ‘hacked’.

Thank you, I've been wanting this. I support being able to put variables in dropdowns where usually not possible, (eg. key __ pressed? boolean) and basically everything that “hacked” blocks do.

I want that too. Either that or ban em.

“I want that, but if they're not implemented, make it impossible for everyone else to have!”

With how commonplace they are, the ST might as well add support for them.

“With all the car thefts, we might as well make it legal.”

Now that's different. Car thefts are bad - hacked blocks are not necessarily so.

Well then why have you been arguing for them to be completely banned the whole time?

BookOwl wrote:

braxbroscratcher wrote:

Firedrake969 wrote:

braxbroscratcher wrote:

Firedrake969 wrote:

braxbroscratcher wrote:

Scratcher1002 wrote:

DadOfMrLog wrote:

Consequently, I'll be pushing for the opposite… that (certain, sensible) hacked blocks become no longer ‘hacked’.

Thank you, I've been wanting this. I support being able to put variables in dropdowns where usually not possible, (eg. key __ pressed? boolean) and basically everything that “hacked” blocks do.

I want that too. Either that or ban em.

“I want that, but if they're not implemented, make it impossible for everyone else to have!”

With how commonplace they are, the ST might as well add support for them.

“With all the car thefts, we might as well make it legal.”

Now that's different. Car thefts are bad - hacked blocks are not necessarily so.

Well then why have you been arguing for them to be completely banned the whole time?

There is where you don't see what I was arguing for. I was arguing that hacked blocks should be banned or made not hacked.

So where exactly in the original post does it state that?


It doesn't at the time of this post.

Before you edited the OP, it said:

I say ban hacked blocks altogether.

We don't need them, they confuse most people, they are downright dishonest with users about what you can and can't do legitimately with Scratch, and most of all, they are an exploit of a weakness in Scratch.

That doesn't sound like someone who wants to allow hacked blocks…

If you changed your mind, please close this and make a new suggestion (which I'll give full support to).

Edit ninja'd

BookOwl wrote:

Before you edited the OP, it said:

I say ban hacked blocks altogether.

We don't need them, they confuse most people, they are downright dishonest with users about what you can and can't do legitimately with Scratch, and most of all, they are an exploit of a weakness in Scratch.

That doesn't sound like someone who wants to allow hacked blocks…

If you changed your mind, please close this and make a new suggestion (which I'll give full support to).

Edit ninja'd

I'd rather edit and keep the opinions of people here.

braxbroscratcher wrote:

BookOwl wrote:

Before you edited the OP, it said:

I say ban hacked blocks altogether.

We don't need them, they confuse most people, they are downright dishonest with users about what you can and can't do legitimately with Scratch, and most of all, they are an exploit of a weakness in Scratch.

That doesn't sound like someone who wants to allow hacked blocks…

If you changed your mind, please close this and make a new suggestion (which I'll give full support to).

Edit ninja'd

I'd rather edit and keep the opinions of people here.

But then it get's really confusing since this would be a new suggestion. You could link to this thread if you want people to see why you suggested that we make hacked blocks not hacked.

Please don't edit and make it look like we're arguing against something else.
Here's an archive page for posterity though
https://web.archive.org/web/20160419001552/https://scratch.mit.edu/discuss/topic/194493/?page=1

Firedrake969 wrote:

Please don't edit and make it look like we're arguing against something else.
Here's an archive page for posterity though
https://web.archive.org/web/20160419001552/https://scratch.mit.edu/discuss/topic/194493/?page=1

I legit can't close it yet. I'll do it tommorow.

OK.