PkmnQ wrote:

I found the crash glitch that you were talking about.
Step 1: Create a normal block.
Step 2: Right click the define block, and click edit.
Step 3: Rename it to %c. This is where the magic happens.
Step 4: Press ok. Nothing happens, no surprise, we've seen that before, press cancel.
Step 5: Right click the define block again, and click edit again.

PkmnQ wrote:

To freeze the editor,
Step 1: Create a normal block.
Step 2: Drag in the block.
Step 3: Right click either the define block or the custom block, then click edit.
Step 4: Rename to %c.
Step 5: Press ok, then cancel.
Step 6: Click on the blank block.

PkmnQ wrote:

Some additional odd things:

• If the definition of a block contains itself, you need to rename the block multiple times to get all blocks glitchy. The define block has the lowest “priority”.
  
• If you do something that moves the block (like dragging a define block, dragging an if block that contains it, or placing blocks before it) it gets displaced.
  
• If you add a block onto the bottom of a glitched block (that includes putting a reporter/boolean in another slot), it gets cut in half.
  
• Blocks that got cut in half stay that way, and cannot be displaced.
  
• You cannot move glitched blocks using hat blocks, as trying to do so freezes the editor.
  
• If you put a reporter/boolean in a custom block, then glitch it, the boolean stays of course, but when you cut it in half, the boolean gets removed.
  

None of this makes sense.

wow, that IS odd. but in the world of glitches and bugs, it is normal

I wonder if there's a way to cut a normal block in half.

bump

bump

chrdagos wrote:

PkmnQ wrote:

I found the crash glitch that you were talking about.
Step 1: Create a normal block.
Step 2: Right click the define block, and click edit.
Step 3: Rename it to %c. This is where the magic happens.
Step 4: Press ok. Nothing happens, no surprise, we've seen that before, press cancel.
Step 5: Right click the define block again, and click edit again.

PkmnQ wrote:

To freeze the editor,
Step 1: Create a normal block.
Step 2: Drag in the block.
Step 3: Right click either the define block or the custom block, then click edit.
Step 4: Rename to %c.
Step 5: Press ok, then cancel.
Step 6: Click on the blank block.

PkmnQ wrote:

Some additional odd things:

• If the definition of a block contains itself, you need to rename the block multiple times to get all blocks glitchy. The define block has the lowest “priority”.
  
• If you do something that moves the block (like dragging a define block, dragging an if block that contains it, or placing blocks before it) it gets displaced.
  
• If you add a block onto the bottom of a glitched block (that includes putting a reporter/boolean in another slot), it gets cut in half.
  
• Blocks that got cut in half stay that way, and cannot be displaced.
  
• You cannot move glitched blocks using hat blocks, as trying to do so freezes the editor.
  
• If you put a reporter/boolean in a custom block, then glitch it, the boolean stays of course, but when you cut it in half, the boolean gets removed.
  

None of this makes sense.

wow, that IS odd. but in the world of glitches and bugs, it is normal

update: just found a crazy thing that can be done with this glitch. if you wanna see wat I mean, then follow he steps below:

1. make a custom block with AT LEAST 1 number/text input. it should look something like this:

*something* [number/text input]

2. put a reporter block in the reporter input
3. Drag in the block.
4. Right click either the define block or the custom block, then click edit.
5. delete whatever was in the label thing and type “%c”
6. Press ok, then cancel.
7. drag a “repeat ()” block towards the custom block, and when the custom block darts away, drag it away from the

define 

block.
8. right-click and click “undo”.
9. repeat step 8 two more times.

bump.

chrdagos wrote:

chrdagos wrote:

PkmnQ wrote:

I found the crash glitch that you were talking about.
Step 1: Create a normal block.
Step 2: Right click the define block, and click edit.
Step 3: Rename it to %c. This is where the magic happens.
Step 4: Press ok. Nothing happens, no surprise, we've seen that before, press cancel.
Step 5: Right click the define block again, and click edit again.

PkmnQ wrote:

To freeze the editor,
Step 1: Create a normal block.
Step 2: Drag in the block.
Step 3: Right click either the define block or the custom block, then click edit.
Step 4: Rename to %c.
Step 5: Press ok, then cancel.
Step 6: Click on the blank block.

PkmnQ wrote:

Some additional odd things:

• If the definition of a block contains itself, you need to rename the block multiple times to get all blocks glitchy. The define block has the lowest “priority”.
  
• If you do something that moves the block (like dragging a define block, dragging an if block that contains it, or placing blocks before it) it gets displaced.
  
• If you add a block onto the bottom of a glitched block (that includes putting a reporter/boolean in another slot), it gets cut in half.
  
• Blocks that got cut in half stay that way, and cannot be displaced.
  
• You cannot move glitched blocks using hat blocks, as trying to do so freezes the editor.
  
• If you put a reporter/boolean in a custom block, then glitch it, the boolean stays of course, but when you cut it in half, the boolean gets removed.
  

None of this makes sense.

wow, that IS odd. but in the world of glitches and bugs, it is normal

update: just found a crazy thing that can be done with this glitch. if you wanna see wat I mean, then follow he steps below:

1. make a custom block with AT LEAST 1 number/text input. it should look something like this:

*something* [number/text input]

2. put a reporter block in the reporter input
3. Drag in the block.
4. Right click either the define block or the custom block, then click edit.
5. delete whatever was in the label thing and type “%c”
6. Press ok, then cancel.
7. drag a “repeat ()” block towards the custom block, and when the custom block darts away, drag it away from the

define 

block.
8. right-click and click “undo”.
9. repeat step 8 two more times.

just found an easier way to do this:

1. make a custom block with AT LEAST 1 number/text input. it should look something like this:

*something* [number/text input]

2. put a reporter block in the reporter input
3. Drag in the block.
4. Right click either the define block or the custom block, then click edit.
5. delete whatever was in the label thing and type “%c”
6. delete the

define 

block.

I just made a glitchy custom block, and when I inspected it, I found this:

Uncaught Error: Found an custom procedure with an invalid type: c
at Blockly.BlockSvg.i.ScratchBlocks.ProcedureUtils.createAllInputs_ (projects.bundle.js:159)
at Blockly.BlockSvg.i.ScratchBlocks.ProcedureUtils.updateDisplay_ (projects.bundle.js:159)
at Blockly.BlockSvg.i.ScratchBlocks.ProcedureUtils.callerDomToMutation (projects.bundle.js:159)
at Object.Blockly.Procedures.mutateCallersAndPrototype (projects.bundle.js:159)
at Object.callback (projects.bundle.js:159)
at i (projects.bundle.js:92)
at projects.bundle.js:57
at common.bundle.js:38
at d (common.bundle.js:16)
at projects.bundle.js:125
at common.bundle.js:38
at Object.onRequestCloseCustomProcedures (projects.bundle.js:166)
at t.value (projects.bundle.js:166)
at Object.n (projects.bundle.js:52)
at t.value (projects.bundle.js:166)
at n (projects.bundle.js:52)
at Object.u (common.bundle.js:22)
at Object.invokeGuardedCallback (common.bundle.js:30)
at Object.invokeGuardedCallbackAndCatchFirstError (common.bundle.js:30)
at m (common.bundle.js:22)
at y (common.bundle.js:22)
at b (common.bundle.js:22)
at Array.forEach (<anonymous>)
at g (common.bundle.js:22)
at $ (common.bundle.js:22)
at Gn (common.bundle.js:30)
at Ce (common.bundle.js:22)
at batchedUpdates (common.bundle.js:22)
at Q (common.bundle.js:22)
at Le (common.bundle.js:22)

I did “%c” for this. and if I do any other letter, the “invalid type” is changed. like if I do “%i”, the “invalid type” is, well, i
I hope this can help the scratch team.
Edit: on the same line as the Uncaught Error thing, there was (common.bundle.js:22)

bump

bump

bump

chrdagos wrote:

My browser / operating system: Windows NT 10.0, Chrome 75.0.3770.142, No Flash version detected

So today I was having some fun with custom blocks when I decided to see what will happen if I named a custom block “%”.
and it was crazy. all of the blocks were piled onto each other in one place! and when I tried “%b”, and clicked the Boolean input, I got a weird-looking block. So I looked on the scratch wiki for answers, and I got one on the “variables” page.

So Scratch Team…

how did you miss this glitch?
(P.S. I advise you to play around with this glitch, like naming a custom block “%b”, clicking the Boolean input, and clicking the text box thing.)

messed around with it https://scratch.mit.edu/projects/377197544/ the page became laggy

edit: the forever blocks aren't working correctly

bump

bump

chrdagos wrote:

1. make a custom block with AT LEAST 1 number/text input. it should look something like this:

*something* [number/text input]

2. put a reporter block in the reporter input
3. Drag in the block.
4. Right click either the define block or the custom block, then click edit.
5. delete whatever was in the label thing and type “%c”
6. delete the

define 

block.

Whoa.
If you press see project page then see inside, it goes back to normal. And by normal I mean the block still stays but with a normal label.
You don't need the reporter, by the way.

chrdagos wrote:

I just made a glitchy custom block, and when I inspected it, I found this:

Uncaught Error: Found an custom procedure with an invalid type: c
at Blockly.BlockSvg.i.ScratchBlocks.ProcedureUtils.createAllInputs_ (projects.bundle.js:159)
at Blockly.BlockSvg.i.ScratchBlocks.ProcedureUtils.updateDisplay_ (projects.bundle.js:159)
at Blockly.BlockSvg.i.ScratchBlocks.ProcedureUtils.callerDomToMutation (projects.bundle.js:159)
at Object.Blockly.Procedures.mutateCallersAndPrototype (projects.bundle.js:159)
at Object.callback (projects.bundle.js:159)
at i (projects.bundle.js:92)
at projects.bundle.js:57
at common.bundle.js:38
at d (common.bundle.js:16)
at projects.bundle.js:125
at common.bundle.js:38
at Object.onRequestCloseCustomProcedures (projects.bundle.js:166)
at t.value (projects.bundle.js:166)
at Object.n (projects.bundle.js:52)
at t.value (projects.bundle.js:166)
at n (projects.bundle.js:52)
at Object.u (common.bundle.js:22)
at Object.invokeGuardedCallback (common.bundle.js:30)
at Object.invokeGuardedCallbackAndCatchFirstError (common.bundle.js:30)
at m (common.bundle.js:22)
at y (common.bundle.js:22)
at b (common.bundle.js:22)
at Array.forEach (<anonymous>)
at g (common.bundle.js:22)
at $ (common.bundle.js:22)
at Gn (common.bundle.js:30)
at Ce (common.bundle.js:22)
at batchedUpdates (common.bundle.js:22)
at Q (common.bundle.js:22)
at Le (common.bundle.js:22)

I did “%c” for this. and if I do any other letter, the “invalid type” is changed. like if I do “%i”, the “invalid type” is, well, i
I hope this can help the scratch team.
Edit: on the same line as the Uncaught Error thing, there was (common.bundle.js:22)

The console is right, it are invalid types. The only valid types i know are “%s” (string input) “%n” (number input) and “%m” (menu).

I tried to recreate that bug and yep, the same thing happened.

instead of the receive Input you can also use a variable.

repeat until <Variable = True>
do something
end