Discuss Scratch

Hardmath123
Scratcher
1000+ posts

How to hack your own magic custom blocks

Hacking your own custom blocks
A tutorial

Basically, in this tutorial I'm going to demonstrate how to mess with blocks offline so that you can manually insert reporters in forbidden spaces, and even create custom blocks.

Step 1: Setup
Open up a new Scratch 2.0 project and make a new custom block. For this tutorial, I'm going to make a block that automates a boring thing: adding a value many times to a list. You will be able to, with one block, add an arbitrary value to a list, an arbitrary number of times.

Make a new Scratch project, and add a new custom block:
define [Fill [list] with [a],(n) times]
repeat (n)
|add [a] to [list v]
Pretty straightforward. Remember to make a list to get the list blocks!

Step 2: Downloading a project
Now select File>>Export to local drive to save it to your local disk. In the popup, rename it to “Hack.zip”. Note the “.zip”, not “.sb2”. Pick any place to save it. Now, unarchive the zip.

On Mac or Windows, just double-click the zip file. On Mac and Linux, you can also use the “unzip” command-line utility.
$ cd ~/path/to/zip's/folder
$ unzip Hack.zip
You should get a whole bunch of goodies:
  • project.json!
  • 0.png: this is the image which contains pen trails/stamps
  • 1,2,3.svg: costumes and backgrounds
  • 0.wav: sounds
The second two items are the defaults loaded into a project.
(At this point, you can safely delete the zip file.)

Step 3: Modifying the code!
Now, open up project.json in your favorite text editor/code editor. Here's what you should see:
{
	"objName": "Stage",
	"lists": [{
			"listName": "dummy",
			"contents": [],
			"isPersistent": false,
			"target": "Stage",
			"x": 5,
			"y": 5,
			"width": 102,
			"height": 202,
			"visible": true
		}],
	"sounds": [{
			"soundName": "pop",
			"soundID": 0,
			"md5": "83a9787d4cb6f3b7632b4ddfebf74367.wav",
			"sampleCount": 258,
			"rate": 11025,
			"format": ""
		}],
	"costumes": [{
			"costumeName": "backdrop1",
			"baseLayerID": 3,
			"baseLayerMD5": "790f7842ea100f71b34e5b9a5bfbcaa1.svg",
			"rotationCenterX": 240,
			"rotationCenterY": 180
		}],
	"currentCostumeIndex": 0,
	"penLayerMD5": "279467d0d49e152706ed66539b577c00.png",
	"tempoBPM": 60,
	"children": [{
			"objName": "Scratch Cat",
			"scripts": [[53,
					47.8,
					[["procDef", "Fill %s with %s , %n times", ["list", "a", "n"], ["", "", 1], true],
						["doRepeat", ["getParam", "n"], [["append:toList:", ["getParam", "a"], "dummy"]]]]]],
			"sounds": [{
					"soundName": "pop",
					"soundID": 0,
					"md5": "83a9787d4cb6f3b7632b4ddfebf74367.wav",
					"sampleCount": 258,
					"rate": 11025,
					"format": ""
				}],
			"costumes": [{
					"costumeName": "costume1",
					"baseLayerID": 1,
					"baseLayerMD5": "f9a1c175dbe2e5dee472858dd30d16bb.svg",
					"rotationCenterX": 47,
					"rotationCenterY": 55
				},
				{
					"costumeName": "costume2",
					"baseLayerID": 2,
					"baseLayerMD5": "6e8bd9ae68fdb02b7e1e3df656a75635.svg",
					"rotationCenterX": 47,
					"rotationCenterY": 55
				}],
			"currentCostumeIndex": 0,
			"scratchX": 0,
			"scratchY": 0,
			"scale": 1,
			"direction": 90,
			"rotationStyle": "normal",
			"isDraggable": false,
			"indexInLibrary": 1,
			"visible": true,
			"spriteInfo": {
			}
		}],
	"info": {
		"scriptCount": 1,
		"spriteCount": 1
	}
}

Don't panic! I'll walk you through it.

The format you see with all the colons and brackets is called JSON (JavaScript Object Notation). It's a simple notation to describe data structures. Read more here, but for now I'll explain the basics as we go.

If you have a search utility in your text editor (try ctrl-F), look for “Scratch Cat” (the name of the sprite in which we added the custom block).
These lines are what we will be messing with. “objName” means the sprite's name, and “scripts” is a list of scripts.

Replace that bit, up to but not including the line “sounds” with:
			"objName": "Scratch Cat",
			"scripts": [[28,
					101.9,
					[["procDef", "Fill %m.list with %s , %n times", ["list", "a", "n"], ["", "something", 10], true],
						["doRepeat", ["getParam", "n"],
						 [["append:toList:", ["getParam", "a"], ["getParam", "list"]]]
						]]]],

All I did was replace a text input with a list drop down. A complete list of %-things can be found here, courtesy nXIII. I also changed the input to the append function. Finally, I changed the default values in the first line for a professional look.

Step 4: Reuploading
Now save the json file and quit. You need to re-zip these files.

On Windows, right-click the folder in which you saved the original zip, and choose “Send to”>>“Compressed (Zipped) folder”. On Mac, rihgt-click the folder and select “Compress…”. On Mac and Linux you can also use the “zip” utility basically the same way we did above. Rename the new file to “Hack.sb2”.

Open up the Scratch project and select File>>Import from local drive. If it gives you any warnings, select “Ok”. Enjoy!
ImagineIt
Scratcher
1000+ posts

How to hack your own magic custom blocks

I can't seem to make the inputs go after specific words, so I'm pretty sure I can just change the format in the file, right?
Tbtemplex97
Scratcher
100+ posts

How to hack your own magic custom blocks

It worked!, this seems fun anything else you can do?

Last edited by Tbtemplex97 (Feb. 3, 2013 14:37:30)


ESCAPE 3 The Epic finale to the popular trilogy.
BoltBait
Scratcher
1000+ posts

How to hack your own magic custom blocks

You should make this tutorial into a project so that I can “love” it and “favorite” it.

Click to play:
Hardmath123
Scratcher
1000+ posts

How to hack your own magic custom blocks

You can support this on a demo project that uses the hack: look for Magic KEYPRESS block in my projects. And thanks.
Lightnin
Scratch Team
1000+ posts

How to hack your own magic custom blocks

This is a cool hack, but my concern is that when anyone who doesn't know what you've done (or how you've done it) tries to view your project, they won't be able to understand your scripts - they won't even make sense.

I wouldn't mind at all if this was being done only with downloaded, local projects. But these are public, shared ones, that people are likely to “see inside”.

Any thoughts on the issue?
Hardmath123
Scratcher
1000+ posts

How to hack your own magic custom blocks

Lightnin wrote:

This is a cool hack, but my concern is that when anyone who doesn't know what you've done (or how you've done it) tries to view your project, they won't be able to understand your scripts - they won't even make sense.

I wouldn't mind at all if this was being done only with downloaded, local projects. But these are public, shared ones, that people are likely to “see inside”.

Any thoughts on the issue?
Hmm. It's definitely a problem. I personally see doing this JSON-hacking a lot in the future, and not just for nefarious purposes—putting together an abnormally large script is much easier with a simply Python program. Also, being able to do this allows us to read Scratch projects, too, so I can imagine being able to implement a nice Scratch 2.0 to Snap! converter for Jens and Brian, or do a similar fun project.

That said, it would definitely be confusing and intimidating to a new user; when I saw nXIII's highscore project I was totally lost (ok, intrigued, impressed and curious, but still admittedly lost).

One possible solution may be to change the way block definitions are stored, so that you can't hack in special inputs. You should only be able to have string and number and boolean inputs, the rest can gracefully become string inputs. That lets us continue messing with blocks in the JSON, but prevents odd-looking blocks. One issue with that is being able to stuff blocks into others offline—it can be awkward to explain how I fit a reporter into a dropdown to every new Scratcher who asks. Yet having, for example, a variable in the <key {} pressed?> block, is extremely useful.

I suppose the truth is that you can't completely disallow hacks just like you can't completely disallow chat rooms—there will always be the ingenuous, enterprising people who get around any walls you put up. But making the source completely closed and not letting anyone explore is pretty unfair, too. So I think the best ways is to actively discourage making scary-looking hacked blocks, but allow smaller things like stuffing reporters into dropdowns or making really long scripts with external programs.
learnegy
Scratcher
100+ posts

How to hack your own magic custom blocks

Lightnin wrote:

I wouldn't mind at all if this was being done only with downloaded, local projects. But these are public, shared ones, that people are likely to “see inside”. Any thoughts on the issue?
Perhaps, Scratch could just detect and label projects that use non-standard blocks, inputs, etc. Over time, you could track the use of various hacks and use the data as input when considering new features to implement in future versions.

2.0 Alpha Tester • Scratch instructor and fan!

“Some like to build and some like to play. You can do both with Scratch every single day.”
mcjohnso
Scratcher
47 posts

How to hack your own magic custom blocks

Hello again!

Such a great time waster! I love things like this. :D
It works too! I had been meddling around in scratch 1.4 a bit,
and I remember the %n %s and so on. This makes modding a lot easier
than it was in 1.4. Nice job figuring this out!

Privacy at its finest

You won't be unknown anymore



I love math, Python, bash scripting, Star Wars, Linux, and EDM. What can I say, I'm a geek.
Running Ubuntu Precise 12.04 Linux distribution with Xfce Desktop Environment.
comp500
Scratcher
100+ posts

How to hack your own magic custom blocks

Awesome! This means I can port to Go Everywhere


Ubuntu 13.04: Chrome 29.0.1547.76, Flash 11.8 (release 800) Windows 7: Same Both: Dell Inspiron 545: Dual-Core w/3GB RAM… let's stop boasting now…
For more info ask me on my profile page…
AttackScratch.php
Magnie
Scratcher
100+ posts

How to hack your own magic custom blocks

learnegy wrote:

Lightnin wrote:

I wouldn't mind at all if this was being done only with downloaded, local projects. But these are public, shared ones, that people are likely to “see inside”. Any thoughts on the issue?
Perhaps, Scratch could just detect and label projects that use non-standard blocks, inputs, etc. Over time, you could track the use of various hacks and use the data as input when considering new features to implement in future versions.
A brilliant idea to finding the highest priority features and blocks. I support this.

▴ ▾ ▴ Macbook Pro 13" 2015 i5-5257U 8GB RAM - MacOS Sierra - Vivaldi v1.7 ▴ ▾ ▴
There are 10 types of people in this world, those who understand binary, those who don't, and those who know ternary.
nathanprocks
Scratcher
1000+ posts

How to hack your own magic custom blocks

If you hack the set variable block, you can use it to create new variables. There is no use for it though because you can't hack the variable reporter to allow input.

Last edited by nathanprocks (Feb. 5, 2013 06:50:46)



Want to write text in rainbow? How about uʍop-ǝpısdn? Or just sdrawkcab? Get the TextTools Chrome extension!
My browser / operating system: Macrosoft Winding XO, Internet Exploder 6.0, Angel Player ver.:1.2.5
;
Hardmath123
Scratcher
1000+ posts

How to hack your own magic custom blocks

Hardmath123 wrote:

Lightnin wrote:

This is a cool hack, but my concern is that when anyone who doesn't know what you've done (or how you've done it) tries to view your project, they won't be able to understand your scripts - they won't even make sense.

I wouldn't mind at all if this was being done only with downloaded, local projects. But these are public, shared ones, that people are likely to “see inside”.

Any thoughts on the issue?
Hmm. It's definitely a problem. I personally see doing this JSON-hacking a lot in the future, and not just for nefarious purposes—putting together an abnormally large script is much easier with a simply Python program. Also, being able to do this allows us to read Scratch projects, too, so I can imagine being able to implement a nice Scratch 2.0 to Snap! converter for Jens and Brian, or do a similar fun project.

That said, it would definitely be confusing and intimidating to a new user; when I saw nXIII's highscore project I was totally lost (ok, intrigued, impressed and curious, but still admittedly lost).

One possible solution may be to change the way block definitions are stored, so that you can't hack in special inputs. You should only be able to have string and number and boolean inputs, the rest can gracefully become string inputs. That lets us continue messing with blocks in the JSON, but prevents odd-looking blocks. One issue with that is being able to stuff blocks into others offline—it can be awkward to explain how I fit a reporter into a dropdown to every new Scratcher who asks. Yet having, for example, a variable in the <key {} pressed?> block, is extremely useful.

I suppose the truth is that you can't completely disallow hacks just like you can't completely disallow chat rooms—there will always be the ingenuous, enterprising people who get around any walls you put up. But making the source completely closed and not letting anyone explore is pretty unfair, too. So I think the best ways is to actively discourage making scary-looking hacked blocks, but allow smaller things like stuffing reporters into dropdowns or making really long scripts with external programs.
Bump. Lightnin? Can you please read this?
ke1235
Scratcher
100+ posts

How to hack your own magic custom blocks

http://beta.scratch.mit.edu/projects/10040233/ <– using this I made a block that sets input from a color picker to a variable

EDIT: now added a dog that says if its touching that color

Last edited by ke1235 (Feb. 8, 2013 04:28:26)



It's the interrobang‽Hey! You found the hidden text!
CODE:0110010001100111011010000110010001100110011001110111001101101001011100000111001100110101001101010011010101110000011001110110011001110011011001110110011000000011

Some of my projects:
———————————
Cloud Lists (230char and caps!) is letter () capital? Saving Platformer test Random question of the (usually) day! Voting Engine (limit 9 options) <You can only vote once!
Lightnin
Scratch Team
1000+ posts

How to hack your own magic custom blocks

Hardmath123 wrote:

Hardmath123 wrote:

Lightnin wrote:

This is a cool hack, but my concern is that when anyone who doesn't know what you've done (or how you've done it) tries to view your project, they won't be able to understand your scripts - they won't even make sense.

I wouldn't mind at all if this was being done only with downloaded, local projects. But these are public, shared ones, that people are likely to “see inside”.

Any thoughts on the issue?
Hmm. It's definitely a problem. I personally see doing this JSON-hacking a lot in the future, and not just for nefarious purposes—putting together an abnormally large script is much easier with a simply Python program. Also, being able to do this allows us to read Scratch projects, too, so I can imagine being able to implement a nice Scratch 2.0 to Snap! converter for Jens and Brian, or do a similar fun project.

That said, it would definitely be confusing and intimidating to a new user; when I saw nXIII's highscore project I was totally lost (ok, intrigued, impressed and curious, but still admittedly lost).

One possible solution may be to change the way block definitions are stored, so that you can't hack in special inputs. You should only be able to have string and number and boolean inputs, the rest can gracefully become string inputs. That lets us continue messing with blocks in the JSON, but prevents odd-looking blocks. One issue with that is being able to stuff blocks into others offline—it can be awkward to explain how I fit a reporter into a dropdown to every new Scratcher who asks. Yet having, for example, a variable in the <key {} pressed?> block, is extremely useful.

I suppose the truth is that you can't completely disallow hacks just like you can't completely disallow chat rooms—there will always be the ingenuous, enterprising people who get around any walls you put up. But making the source completely closed and not letting anyone explore is pretty unfair, too. So I think the best ways is to actively discourage making scary-looking hacked blocks, but allow smaller things like stuffing reporters into dropdowns or making really long scripts with external programs.
Bump. Lightnin? Can you please read this?

Sorry, I did - just didn't get to respond to it. Thanks for pinging me about it with a comment to remind me.

A couple days ago we started a discussion on this by email, and John said:

“His suggestion would prevent making user-defined blocks with drop-down menu parameters via JSON. That's pretty easy and probably worth doing. It doesn't prevent all ”impossible to construct“ scripts but it would prevent user-defined blocks with input slots that can't be created via our block definition dialog.”

So it's likely on his list, with the 2000 other things.

The main concern I have about this technique is that if we have a ‘public code repository’ - which is one way of seeing the Scratch website - it's important that code is legible, makes sense, and corresponds accurately to what the project actually does. If hacking the JSON makes projects that don't behave how their scripts indicate they'd behave, or which can't be re-created with the normal editor, then I think it's potentially really confusing for anyone viewing the code. If some way of doing that becomes common, I'd recommend we think about validating uploads and rejecting hand JSON edits that can't be recreated in the editor. But if it's not much of an issue, we won't have to.

But as for making scripts by hacking the JSON that *can* be accurately represented / recreated in the editor - knock yourself out!

Last edited by Lightnin (Feb. 9, 2013 04:28:44)

BoltBait
Scratcher
1000+ posts

How to hack your own magic custom blocks

I had to hack work around an editor limitation in order to create my clock project.

You see, the block "go to [clock]" couldn't directly be made using the editor while in the clock sprite itself. Normally, I can see why you'd want to limit this behavior since you can't really go to yourself. But, in my case, the block would be used by a clone to go to the original sprite.

I had to create a different sprite and select it. Then I could go to the motion blocks and drag the one I wanted over to the clock sprite and let it go. It properly showed up in the clock sprite and I was able to drag it around and connect it in the proper place. Then I deleted the temporary sprite that I created.

I'm just not sure there's any value in fixing this editor limitation.

Last edited by BoltBait (Feb. 9, 2013 05:12:39)


Click to play:
comp500
Scratcher
100+ posts

How to hack your own magic custom blocks

Lightnin wrote:

Hardmath123 wrote:

Hardmath123 wrote:

Lightnin wrote:

This is a cool hack, but my concern is that when anyone who doesn't know what you've done (or how you've done it) tries to view your project, they won't be able to understand your scripts - they won't even make sense.

I wouldn't mind at all if this was being done only with downloaded, local projects. But these are public, shared ones, that people are likely to “see inside”.

Any thoughts on the issue?
Hmm. It's definitely a problem. I personally see doing this JSON-hacking a lot in the future, and not just for nefarious purposes—putting together an abnormally large script is much easier with a simply Python program. Also, being able to do this allows us to read Scratch projects, too, so I can imagine being able to implement a nice Scratch 2.0 to Snap! converter for Jens and Brian, or do a similar fun project.

That said, it would definitely be confusing and intimidating to a new user; when I saw nXIII's highscore project I was totally lost (ok, intrigued, impressed and curious, but still admittedly lost).

One possible solution may be to change the way block definitions are stored, so that you can't hack in special inputs. You should only be able to have string and number and boolean inputs, the rest can gracefully become string inputs. That lets us continue messing with blocks in the JSON, but prevents odd-looking blocks. One issue with that is being able to stuff blocks into others offline—it can be awkward to explain how I fit a reporter into a dropdown to every new Scratcher who asks. Yet having, for example, a variable in the <key {} pressed?> block, is extremely useful.

I suppose the truth is that you can't completely disallow hacks just like you can't completely disallow chat rooms—there will always be the ingenuous, enterprising people who get around any walls you put up. But making the source completely closed and not letting anyone explore is pretty unfair, too. So I think the best ways is to actively discourage making scary-looking hacked blocks, but allow smaller things like stuffing reporters into dropdowns or making really long scripts with external programs.
Bump. Lightnin? Can you please read this?

Sorry, I did - just didn't get to respond to it. Thanks for pinging me about it with a comment to remind me.

A couple days ago we started a discussion on this by email, and John said:

“His suggestion would prevent making user-defined blocks with drop-down menu parameters via JSON. That's pretty easy and probably worth doing. It doesn't prevent all ”impossible to construct“ scripts but it would prevent user-defined blocks with input slots that can't be created via our block definition dialog.”

So it's likely on his list, with the 2000 other things.

The main concern I have about this technique is that if we have a ‘public code repository’ - which is one way of seeing the Scratch website - it's important that code is legible, makes sense, and corresponds accurately to what the project actually does. If hacking the JSON makes projects that don't behave how their scripts indicate they'd behave, or which can't be re-created with the normal editor, then I think it's potentially really confusing for anyone viewing the code. If some way of doing that becomes common, I'd recommend we think about validating uploads and rejecting hand JSON edits that can't be recreated in the editor. But if it's not much of an issue, we won't have to.

But as for making scripts by hacking the JSON that *can* be accurately represented / recreated in the editor - knock yourself out!
One problem with this is when someone can download a project, remove the author tag and put their own therefore meaning credit is not given…


Ubuntu 13.04: Chrome 29.0.1547.76, Flash 11.8 (release 800) Windows 7: Same Both: Dell Inspiron 545: Dual-Core w/3GB RAM… let's stop boasting now…
For more info ask me on my profile page…
AttackScratch.php
Hardmath123
Scratcher
1000+ posts

How to hack your own magic custom blocks

Lightnin wrote:

Hardmath123 wrote:

Hardmath123 wrote:

Lightnin wrote:

This is a cool hack, but my concern is that when anyone who doesn't know what you've done (or how you've done it) tries to view your project, they won't be able to understand your scripts - they won't even make sense.

I wouldn't mind at all if this was being done only with downloaded, local projects. But these are public, shared ones, that people are likely to “see inside”.

Any thoughts on the issue?
Hmm. It's definitely a problem. I personally see doing this JSON-hacking a lot in the future, and not just for nefarious purposes—putting together an abnormally large script is much easier with a simply Python program. Also, being able to do this allows us to read Scratch projects, too, so I can imagine being able to implement a nice Scratch 2.0 to Snap! converter for Jens and Brian, or do a similar fun project.

That said, it would definitely be confusing and intimidating to a new user; when I saw nXIII's highscore project I was totally lost (ok, intrigued, impressed and curious, but still admittedly lost).

One possible solution may be to change the way block definitions are stored, so that you can't hack in special inputs. You should only be able to have string and number and boolean inputs, the rest can gracefully become string inputs. That lets us continue messing with blocks in the JSON, but prevents odd-looking blocks. One issue with that is being able to stuff blocks into others offline—it can be awkward to explain how I fit a reporter into a dropdown to every new Scratcher who asks. Yet having, for example, a variable in the <key {} pressed?> block, is extremely useful.

I suppose the truth is that you can't completely disallow hacks just like you can't completely disallow chat rooms—there will always be the ingenuous, enterprising people who get around any walls you put up. But making the source completely closed and not letting anyone explore is pretty unfair, too. So I think the best ways is to actively discourage making scary-looking hacked blocks, but allow smaller things like stuffing reporters into dropdowns or making really long scripts with external programs.
Bump. Lightnin? Can you please read this?

Sorry, I did - just didn't get to respond to it. Thanks for pinging me about it with a comment to remind me.

A couple days ago we started a discussion on this by email, and John said:

“His suggestion would prevent making user-defined blocks with drop-down menu parameters via JSON. That's pretty easy and probably worth doing. It doesn't prevent all ”impossible to construct“ scripts but it would prevent user-defined blocks with input slots that can't be created via our block definition dialog.”

So it's likely on his list, with the 2000 other things.

The main concern I have about this technique is that if we have a ‘public code repository’ - which is one way of seeing the Scratch website - it's important that code is legible, makes sense, and corresponds accurately to what the project actually does. If hacking the JSON makes projects that don't behave how their scripts indicate they'd behave, or which can't be re-created with the normal editor, then I think it's potentially really confusing for anyone viewing the code. If some way of doing that becomes common, I'd recommend we think about validating uploads and rejecting hand JSON edits that can't be recreated in the editor. But if it's not much of an issue, we won't have to.

But as for making scripts by hacking the JSON that *can* be accurately represented / recreated in the editor - knock yourself out!
Ok, cool, that sounds good. I understand how you feel about new users getting confused and deterred by complex stuff. I'm sure in the future we will have plugins that let you modify the JSON very easily, and I predict there will be lots of “hacks” in common usage.

Speaking of JSON-hacking, by the way, I did in fact start the Scratch 2.0 to Snap! converter for Jens, and I have managed to convert quite a lot of complex projects with clones and sounds already (around 3 days in development!). So kudos to whoever set down the new format, it's extremely flexible and sensibly made, as compared to the binary 1.4 format that got us all nauseous. One suggestion, though, would be to encapsulate the entire current project data into a larger JSON object which stores the creator, the project notes/instructions, the date modified/created, and the view/loveit/fave counts. Currently the APIs only let you get data of your own project, and that too only if you're logged in. That makes it really awkward to download this data via an external source (ie. my Python program…). Alternatively, just make this API accessible to everyone—I don't really see why it should be private.
comp500
Scratcher
100+ posts

How to hack your own magic custom blocks

Hardmath123 wrote:

Lightnin wrote:

Hardmath123 wrote:

Hardmath123 wrote:

Lightnin wrote:

This is a cool hack, but my concern is that when anyone who doesn't know what you've done (or how you've done it) tries to view your project, they won't be able to understand your scripts - they won't even make sense.

I wouldn't mind at all if this was being done only with downloaded, local projects. But these are public, shared ones, that people are likely to “see inside”.

Any thoughts on the issue?
Hmm. It's definitely a problem. I personally see doing this JSON-hacking a lot in the future, and not just for nefarious purposes—putting together an abnormally large script is much easier with a simply Python program. Also, being able to do this allows us to read Scratch projects, too, so I can imagine being able to implement a nice Scratch 2.0 to Snap! converter for Jens and Brian, or do a similar fun project.

That said, it would definitely be confusing and intimidating to a new user; when I saw nXIII's highscore project I was totally lost (ok, intrigued, impressed and curious, but still admittedly lost).

One possible solution may be to change the way block definitions are stored, so that you can't hack in special inputs. You should only be able to have string and number and boolean inputs, the rest can gracefully become string inputs. That lets us continue messing with blocks in the JSON, but prevents odd-looking blocks. One issue with that is being able to stuff blocks into others offline—it can be awkward to explain how I fit a reporter into a dropdown to every new Scratcher who asks. Yet having, for example, a variable in the <key {} pressed?> block, is extremely useful.

I suppose the truth is that you can't completely disallow hacks just like you can't completely disallow chat rooms—there will always be the ingenuous, enterprising people who get around any walls you put up. But making the source completely closed and not letting anyone explore is pretty unfair, too. So I think the best ways is to actively discourage making scary-looking hacked blocks, but allow smaller things like stuffing reporters into dropdowns or making really long scripts with external programs.
Bump. Lightnin? Can you please read this?

Sorry, I did - just didn't get to respond to it. Thanks for pinging me about it with a comment to remind me.

A couple days ago we started a discussion on this by email, and John said:

“His suggestion would prevent making user-defined blocks with drop-down menu parameters via JSON. That's pretty easy and probably worth doing. It doesn't prevent all ”impossible to construct“ scripts but it would prevent user-defined blocks with input slots that can't be created via our block definition dialog.”

So it's likely on his list, with the 2000 other things.

The main concern I have about this technique is that if we have a ‘public code repository’ - which is one way of seeing the Scratch website - it's important that code is legible, makes sense, and corresponds accurately to what the project actually does. If hacking the JSON makes projects that don't behave how their scripts indicate they'd behave, or which can't be re-created with the normal editor, then I think it's potentially really confusing for anyone viewing the code. If some way of doing that becomes common, I'd recommend we think about validating uploads and rejecting hand JSON edits that can't be recreated in the editor. But if it's not much of an issue, we won't have to.

But as for making scripts by hacking the JSON that *can* be accurately represented / recreated in the editor - knock yourself out!
Ok, cool, that sounds good. I understand how you feel about new users getting confused and deterred by complex stuff. I'm sure in the future we will have plugins that let you modify the JSON very easily, and I predict there will be lots of “hacks” in common usage.

Speaking of JSON-hacking, by the way, I did in fact start the Scratch 2.0 to Snap! converter for Jens, and I have managed to convert quite a lot of complex projects with clones and sounds already (around 3 days in development!). So kudos to whoever set down the new format, it's extremely flexible and sensibly made, as compared to the binary 1.4 format that got us all nauseous. One suggestion, though, would be to encapsulate the entire current project data into a larger JSON object which stores the creator, the project notes/instructions, the date modified/created, and the view/loveit/fave counts. Currently the APIs only let you get data of your own project, and that too only if you're logged in. That makes it really awkward to download this data via an external source (ie. my Python program…). Alternatively, just make this API accessible to everyone—I don't really see why it should be private.
Agree.


Ubuntu 13.04: Chrome 29.0.1547.76, Flash 11.8 (release 800) Windows 7: Same Both: Dell Inspiron 545: Dual-Core w/3GB RAM… let's stop boasting now…
For more info ask me on my profile page…
AttackScratch.php
blob8108
Scratcher
1000+ posts

How to hack your own magic custom blocks

Lightnin wrote:

my concern is that when anyone who doesn't know what you've done (or how you've done it) tries to view your project, they won't be able to understand your scripts

Is it worth pointing out that things like Hardmath's “Magic KEYPRESS block” were already possible in 1.4? example

Powered by DjangoBB

Standard | Mobile