define [Fill [list] with [a],(n) times]
repeat (n)
|add [a] to [list v]

$ cd ~/path/to/zip's/folder
$ unzip Hack.zip

• project.json!
  
• 0.png: this is the image which contains pen trails/stamps
  
• 1,2,3.svg: costumes and backgrounds
  
• 0.wav: sounds
  

{
	"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
	}
}

			"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"]]]
						]]]],

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?

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?

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.

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.

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?

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!

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!

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.

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