< Talk:Block Plugin (1.4)

Revision as of 23:11, 30 August 2012 by JSO (talk | contribs) (Hat blocks and c blocks fit in reporter block spaces)

Obsolete blocks and block shapes

I don't think the block shapes are a bug, nor do I think it's possible to implement the realistic ones ^^ Obsolete blocks are dark-red in the Scratch program too btw.
Jonathanpb (talk | contribs) 11:22, 2 January 2012 (UTC)

indeed - I think I got all colors from screenshots I made :)
JSO (talk | contribs) 11:28, 2 January 2012 (UTC)
I mean the actual block that says "obsolete!". It appears dark red. Look:
Not light red.
Scimonster (talk | contribs) 11:37, 2 January 2012 (UTC)
Obsolete Block.png
(Just putting the picture for reference). I suppose it could be a bit lighter.
Lucario621 (talk | contribs) 16:58, 2 January 2012 (UTC)

I think you could create booleans, if not perfectly, with an SVG image or the triangles, in different colors and positions. That way you could crop it with CSS, and also zoom it to be correct for nested booleans.
I made you the puzzle piece HTML/CSS, you just have to put it in to the JS. :P here.
Scimonster (talk | contribs) 13:32, 2 January 2012 (UTC)

I don't think the obsolete block bug is an actual bug. When the Block Syntax was made, the obsolete block was not included. It's something the creator (JSO) would have to deal with. :/
Sku2000 (talk | contribs) 01:38, 31 March 2012 (UTC)

I'm not sure if Java actually has any code for vector graphics.
3sal2 (talk | contribs) 20:18, 27 April 2012 (UTC)

Also, try "#ff0000" instead of that dark red color.
3sal2 (talk | contribs) 21:03, 4 May 2012 (UTC)

There may be errors in the screenshot color. Where did you get the screenshot colors?
3sal2 (talk | contribs) 20:12, 3 June 2012 (UTC)

Putting ~~~ after bugs

I'm rethinking this, and if you ask me, they're really not needed. For the main bullets, there can be no signature, however if JSO wants to comment on it, than he will put his signature. Here's an example:

Do you think this makes more sense?
Lucario621 (talk | contribs) 16:55, 2 January 2012 (UTC)

It might.
Scimonster (talk | contribs) 17:29, 2 January 2012 (UTC)
Jonathanpb (talk | contribs) 21:57, 2 January 2012 (UTC)


Why do we want to have this bug report thing in the main namespace? For sure, a Block Plugin article will be useful, but why this subpage?
Scimonster (talk | contribs) 17:31, 2 January 2012 (UTC)

Because this plugin isn't just for the wiki. It will be later added to the forums, so it can be a full article. As for this subpage, rather than including all of the bugs on Block Plugin, we can have it on a subpage, Block Plugin/Bugs.
Lucario621 (talk | contribs) 19:31, 2 January 2012 (UTC)


When I put a variable on one side of the block and a number on the other side of the <[] > []> block the block is obsolete.

<(dfhg) > [234]>

Bsteward (talk | contribs) 23:53, 2 January 2012 (UTC)

Like I said on the CP, use round brackets for the numerical values in less that or greater than equations for now:
<(dfhg) > (234)>

JSO (talk | contribs) 23:57, 2 January 2012 (UTC)
What if I am comparing text?
If I use rounded brackets it comes out as a variable:
<(dfhg) > (adfs)>

If I use square brackets it is obsolete:

<(dfhg) > [adfs]>
I know this is rarely done but it could be used when alphabetizing things.
Bsteward (talk | contribs) 00:07, 3 January 2012 (UTC)

Bsteward is right ^^ Less than, greater than, and equal to all use textboxes; text works in the blocks too. ^^

Did some testing with variables and textboxes in those three blocks btw ^^

With the less than block: <[a] < [b]> is:

<[a] < [b]>

<(a) < (b)> is:

<(a) < (b)>

<(a) < [b]> is:

<(a) < [b]>

<[a] < (b)> is:

<[a] < (b)>

When one value is a variable and one is the default textbox, it gets messed up :S

Now with the greater than block:

<[a] > [b]> is:

<[a] > [b]>

<(a) > (b)> is:

<(a) > (b)>

<(a) > [b]> is:

<(a) > [b]>

<[a] > (b)> is:

<[a] > (b)>

With the equal to block:

<[a] = [b]> is:

<[a] = [b]>

<(a) = (b)> is:

<(a) = (b)>

<(a) = [b]> is:

<(a) = [b]>

<[a] = (b)> is:

<[a] = (b)>

With the less than block, having one variable and one textbox makes the block not render properly (and it shows as obsolete).

With the greater than block, it renders properly in all situations but shows as obsolete in the latter two.

The equal to block works perfectly :)
Jonathanpb (talk | contribs) 06:07, 3 January 2012 (UTC)

Hehehe :) I just fixed it, your post looks perfectly fine now. Always remember to place spaces around the < or > in the less than or greater than blocks, that's how the code identifies them.
when I receive [game: jump v]
if <(a) > [b]>
if <(a) < [b]>
if <[a] > (b)>
if <[a] < (b)>

JSO (talk | contribs) 11:31, 3 January 2012 (UTC)
By the way, that's what the block looks like in Scratch 1.4.
3sal2 (talk | contribs) 18:40, 6 May 2012 (UTC)

Touching color block

How do you do the color in the touching block?
Bsteward (talk | contribs) 13:18, 3 January 2012 (UTC)

touching color [#FF0000]?
if <<touching color [#FF0000]?> or <color [#00FF00] is touching [#0000FF]?>>

JSO (talk | contribs) 14:51, 3 January 2012 (UTC)
Bsteward (talk | contribs) 21:29, 3 January 2012 (UTC)


Is there a way to do comments with Scratch Blocks?
Bsteward (talk | contribs) 21:35, 3 January 2012 (UTC)

I don't think so, but IMO it's not very important ^^
Jonathanpb (talk | contribs) 23:20, 3 January 2012 (UTC)
Then how will we transfer scripts with comments in them?
Bsteward (talk | contribs) 23:22, 3 January 2012 (UTC)
I don't think the comments are completely necessary :S You can always explain the stuff before or after the script I guess.
Jonathanpb (talk | contribs) 23:30, 3 January 2012 (UTC)
There's no current way to add comments, and I don't think we're planning to add them. For converting the images, try playing the comments as normal text to the right of the script(s), or simply explain what the comments were trying to say below or above the image.
Lucario621 (talk | contribs) 23:52, 3 January 2012 (UTC)
Or... just leave the image for that one.
Scimonster (talk | contribs) 05:20, 4 January 2012 (UTC)
Or just bring back the 1.2.1 beta comment block! (Probably not XD)
SJRCS_011 (talk | contribs)23:02, 4 January 2012 (UTC)
I was actually thinking that we could do that, to show comments.
Scimonster (talk | contribs) 05:44, 5 January 2012 (UTC)
Honestly? Wow. I had only been joking around when I said that. Maybe it would work, though.
SJRCS_011 (talk | contribs)22:40, 5 January 2012 (UTC)
If you hadn't said it I would have. :P
Scimonster (talk | contribs) 09:08, 6 January 2012 (UTC)

The color bug mentioned

  • Colors can be entered into a text area by using HEX format.

Isn't that how you're supposed to do colors? I don't think it's a bug :S
Jonathanpb (talk | contribs) 06:39, 4 January 2012 (UTC)

It turns a text area into a color area. See?
Scimonster (talk | contribs) 06:42, 4 January 2012 (UTC)
Hmm, you're right. It should only work for one block.
Lucario621 (talk | contribs) 18:04, 4 January 2012 (UTC)
Ahh I see now ^^ There are several blocks that use the colorbox btw :P
Jonathanpb (talk | contribs) 22:38, 4 January 2012 (UTC)
Ohhh yeah I forgot. I was only thinking about the sensing one ;).
Lucario621 (talk | contribs) 23:02, 4 January 2012 (UTC)
That's what it's supposed to do. The plugin renders the syntax into blocks, and only compares to scratch's block library to render the block in the correct color (and to distinguish variables from reporter blocks etc). That means that as long as your syntax is correct, it will render something. And that's what it's supposed to do: remember that everyone should be able to use this on the forums. It shouldn't crash on some added spaces. It doesn't check if supplied parameters are correct.
repeat [some wrong input] unt [#ABCDEF] il (variable)
  go [sprite1 v] to x: (variable) y: [3]
Technically, the syntax you enter is stripped from all parameters and spaces until only a unique block name is left: "gotox:y:", "repeatuntil", "touchingcolor". Using that unique block name, the plugin loads some parameters (like the correct block type and color) from a library. This is not a bug. This is intended. You're supposed to enter correct syntax, and the plugin will always attempt to render something even if you screwed up completely.
JSO (talk | contribs) 19:01, 7 January 2012 (UTC)
Well then, how about you make a different type of input for colors, so that it doesn't get mixed up. Perhaps |FF0000| or !FF0000!.
Scimonster (talk | contribs) 19:07, 7 January 2012 (UTC)
"doesn't get messed up" ? who is ever going to accidently type a # with 6 hex characters when they meant to type a text input?
JSO (talk | contribs) 19:37, 7 January 2012 (UTC)
I agree with JSO, this isn't a bug. When is # with 6 hex ever going to be in a text input?
Bsteward (talk | contribs) 19:41, 7 January 2012 (UTC)
When you want to do something with colors. ^^
Scimonster (talk | contribs) 19:45, 7 January 2012 (UTC)

The When Sprite Clicked block

The glitch with the insert might be able to be fixed like this: The parser looks for "when", and if it finds "clicked" at the end, if the middle text is not "gf", it treats it as the sprite name. This means using no brackets there.

Just for reference, this block is transcribed on the pages: (update this please!)

Scimonster (talk | contribs) 08:43, 4 January 2012 (UTC)

Uhh... it does need brackets. If there are no brackets, it will render as an obsolete stack block:

when Sprite1 clicked

So, your idea is nonsense.
3sal2 (talk | contribs) 21:27, 4 May 2012 (UTC)

The need for brackets is due to a limitation. Fortunately, it's called "when I am clicked" in Scratch 2.0 alpha. When 2.0 beta is released in July 2012, "whenclicked" should be changed to "whenIamclicked". That can fix the textbox/dropdown problem.
3sal2 (talk | contribs) 20:17, 3 June 2012 (UTC)

Reporter blocks are shaped like Stack blocks

One bug on the list says "Reporter blocks are shaped like Stack blocks when alone." However I can't seem to recreate that bug:


Am I doing something wrong? Or should we remove that bug from the list?
Lucario621 (talk | contribs) 18:55, 7 January 2012 (UTC)

Hmm, it seems Scimonster caught onto this too. I guess it was fixed.
Lucario621 (talk | contribs) 18:56, 7 January 2012 (UTC)
You missed the parentheses. Reporters and Booleans won't spontaneously render as a reporter or Boolean block without parentheses () or angle brackets <>. For example:

If it is in either set, it will render properly:


Thus, it is not a bug.
3sal2 (talk | contribs) 21:23, 4 May 2012 (UTC)

There's a bug in a script that I can't find

Jonathanpb (talk | contribs) 04:26, 18 January 2012 (UTC)

It still gets confused between the start of a Boolean and a less than block. That's the bug.
Scimonster (talk | contribs) 08:05, 18 January 2012 (UTC)

Really a bug?

Is this really a bug:

  • Reporter blocks render as stack blocks and not obsolete when not in parentheses
costume #

If you use proper syntax it renders fine:

(costume #)

Bsteward (talk | contribs) 22:08, 22 January 2012 (UTC)
I don't think that's a bug either.
Lucario621 (talk | contribs) 22:14, 22 January 2012 (UTC)
Yeah, JSO said the parser tries to render as much as it can.
Scimonster (talk | contribs) 08:11, 23 January 2012 (UTC)

Spaces between question marks and the query

Is it really a bug that "set size to (100) %" doesn't work? I thought people were supposed to use "set size to (100)%" :S
Jonathanpb (talk | contribs) 00:00, 1 February 2012 (UTC)

set size to (100)%
set size to (100) %
I suppose it isn't exactly a bug, but more of a suggestion. I think it should stay.
Lucario621 (talk | contribs) 00:16, 1 February 2012 (UTC)
I think it is a bug (btw you misspelled that Luc), because JSO said it ignores all spaces and arguments.
Scimonster (talk | contribs) 08:01, 1 February 2012 (UTC)
The parser thinks ") %" and similar strings at the end of a block are all the same as blank. That's the bug.
3sal2 (talk | contribs) 20:22, 3 June 2012 (UTC)
It doesn't happen on the forums... Must be a technical limitation.
3sal2 (talk | contribs) 19:40, 20 June 2012 (UTC)

gt & lt

I was working on a Python script to read all the sprites in a Scratch project file and convert all the scripts to [scratchblocks] format.

I had found a whole list of bugs with the blocksplugin itself, but it seems the test html page I made didn't convert > and < to gt and lt properly, so I can't replicate them here... :P

Anyway: first, not really a bug — can't have empty dropdowns, eg. broadcast [ v]

broadcast [ v]

There is one bug I can replicate here, which is this:

if <<<(x) > [-1]> and <(y) > [-1]>> and <<(x) < [20]> and <(y) < [14]>>>
     say [hi]
if <<<(x) > [-1]> and <(y) > [-1]>> and <<(x) < [20]> and <(y) < [14]>>>
    say [hi!]

Which is really weird :/

Blob8108 (talk | contribs) 16:51, 25 July 2012 (UTC)

Stop all pinks

The block plugin does not recognize the Stop all sounds block, only "Stop all pinks". I really wonder what's wrong. The last section of this page says it might be a typo. Can anyone figure it out?
3sal2 (talk | contribs) 20:49, 14 April 2012 (UTC)

I'm pretty sure it's a typo. On line 571 of blocksplugin.js, it says: 'stopallpinks': ['pink','stack'], ...looks like a typo to me :)
Blob8108 (talk | contribs) 20:57, 14 April 2012 (UTC)

Obsolete blocks

I can make blocks like
I am not in scratch
is that a bug?

nintendo100 (talk | contribs)

No, that's intended. However they show in a dark red color to show that they are not available in Scratch 1.4. :)
Lucario621 (talk | contribs) 19:55, 26 April 2012 (UTC)

Boolean block shapes

Well, Boolean blocks and inserts are shaped like reporter blocks, such as in these examples:

when gf clicked
repeat until <loud?>
say (costume#)
stop script
forever if <>

Why? I know is because of a limitation, but what causes the limitation? I think it's due to no vector graphics in Java.
3sal2 (talk | contribs) 21:17, 4 May 2012 (UTC)

The limitation is that there's no simple/easy/practical way to add the bumps (< and >) to the blocks with HTML/CSS. The block plugin doesn't use Java.
Lucario621 (talk | contribs) 22:39, 4 May 2012 (UTC)
The bock plugin also uses JavaScript, not to be confused with Java (The two are very different). As Lucario said there is a very practical way to make the bumps (< and >) with css, but it could be done with an svg image.
Bsteward (talk | contribs) 23:08, 4 May 2012 (UTC)
You mean no practical way? :P
I suggested SVG images a while ago too.
Scimonster (talk | contribs) 18:32, 5 May 2012 (UTC)

Whatever language the block plugin was written in, I don't think that vector images are supported by that language.
3sal2 (talk | contribs) 18:08, 6 May 2012 (UTC)

Vector images won't work. I suggest Flash-based shape rendering.
3sal2 (talk | contribs) 20:23, 3 June 2012 (UTC)

3sal, there are a couple reasons why this is not in flash. First of all, JSO originally used PHP to make the plugin. He then switched to JS to reduce the load on the server. To rewrite it completely in Flash, which is completely different from using CSS and JS or PHP, would require a lot more time to be put in, and JSO was working on this for a while. Second, Flash is not supported on iDevices and on laptops without Flash installed. CSS and JS, on the other hand, at least work to some extent on IE8, and (presumably) work well on other, more modern browsers (Chrome, FF 4+, Opera, IE8, etc.). Third, Flash is very hard to modify once compiled. JSO would have to recompile and re-upload every time he wanted to make a bug fix. In JS, all you have to do is edit a text file on the website. Fourth, I believe that Flash editors cost money, so why not go the free option? Fifth, HTML5 does support vector graphics (through SVG or HTML5 canvas), but, so far, JSO has not implemented it.
SJRCS_011 (talk | contribs) 19:31, 30 July 2012 (UTC)

Motor blocks not supported

As you can see, there are no motor blocks in the plugin:

motor on
motor off
motor power (100)
motor on for (1) secs
motor direction [this way v]

They render as obsolete. PicoBoard-related blocks are also not supported:

when gf clicked
wait until <sensor [button pressed v]?>
say ([slider v] sensor value) for (1) secs

The Sensor ()? block also shows up as obsolete, and the () Sensor Value block renders as a variable. Why? If this is intentional, show that it is not a bug. Not everyone has the needed equipment. If not, try to fix it.
3sal2 (talk | contribs) 18:36, 6 May 2012 (UTC)

It seems like JSO just forgot to include them.
Scimonster (talk | contribs) 18:48, 6 May 2012 (UTC)

I began a new topic, and one post suggested that JSO is "lazy". I think that's why JSO forgot about it. Besides, where did you get your information?
3sal2 (talk | contribs) 20:10, 3 June 2012 (UTC)

Is this a bug?


Else does not need if.
James07 (talk | contribs) 17:50, 12 May 2012 (UTC)

Apparently, here's what it should be:

The if/else block can render incorrectly without if.

move (10) steps

But I have no idea.
3sal2 (talk | contribs) 17:15, 13 May 2012 (UTC)

I don't think it's a bug. It never occurs if proper syntax is used.
Bsteward (talk | contribs)19:55, 13 May 2012 (UTC)

My theory: The parser identifies "else" separately. Example:

move (10) steps
if <loud?>
say []
go to front

3sal2 (talk | contribs) 20:08, 3 June 2012 (UTC)

That's probably it. Checking the code should confirm it.
Scimonster (talk | contribs) 10:43, 4 June 2012 (UTC)

Reporters can fit in Boolean places

if (tempo)
do something

James07 (talk | contribs) 15:41, 31 May 2012 (UTC)

Not a bug. It identifies blocks by their shapes. It doesn't care abut the expected argument types.
Scimonster (talk | contribs) 17:06, 31 May 2012 (UTC)
That argument ignorance the key to my sandbox.
3sal2 (talk | contribs) 20:13, 3 June 2012 (UTC)

Hat blocks and c blocks fit in reporter block spaces

if <when gf clicked> 
do stuff
if <repeat until>
do more stuff

Why does this happen?
Joefarebrother (talk | contribs) 19:46, 30 August 2012 (UTC)

Because it doesn't check the shape; only the color and label, i think. That's a cool bug though.
repeat until <move (10) steps>
That is also this bug.
Scimonster (talk | contribs) 20:00, 30 August 2012 (UTC)
This isn't really as much of a "bug" as it is an area that the block plugin doesn't (and will probably not) cover - syntax checking. The intended use is for allowing scripts that have been made correctly to be displayed on the wiki and forum; it's the job of the user to put the blocks in the right order.
Lucario621 (talk | contribs) 22:00, 30 August 2012 (UTC)
The plugin that renders the Scratch blocks on the wiki and forums indeed doesn't do syntax checking, and it might never do. It basically always tries to render at least something, to give the user an indication of what's wrong. It could very easily detect malicious syntax and just render an "error" block or something; but this makes it easier for people to get used to working with it - as you can see on the forums: some new Scratchers have some difficulty with the blocks syntax, but people correct and help them and they get a lot of opportunities to learn over time.
JSO (talk | contribs) 23:11, 30 August 2012 (UTC)