< Talk:Block Plugin (1.4)

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:
obsolete!
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)
Agreed.
Jonathanpb (talk | contribs) 21:57, 2 January 2012 (UTC)

Namespace

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)

Bug?

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)
Weird... I don't notice any obsolete blocks in this section on my computer.
Mathfreak231 (talk | contribs) 15:50, 19 January 2013 (UTC)
It was fixed...
Scimonster (talk | contribs) 19:42, 19 January 2013 (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)
Thanks
Bsteward (talk | contribs) 21:29, 3 January 2012 (UTC)

Comments

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)

────────────────────────────────────────────────────────────────────────────────────────────────────

//What are you talking about?

Curiouscrab (talk | contribs) 23:23, 23 January 2013 (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]
end
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:

(size)

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:
size
loud?

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

(size)
<loud?>

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

Umm
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]
end
if <<<(x) > [-1]> and <(y) > [-1]>> and <<(x) < [20]> and <(y) < [14]>>>
    say [hi!]
end

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#)
end
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) seconds
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) It looks like it has been fixed.
3sal2 (talk | contribs) 22:58, 18 May 2013 (UTC)

Is this a bug?

else

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.

else
move (10) steps
end

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:

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


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 is 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
end
if <repeat until>
do more stuff
end

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)
Yes, but with the other blocks put into the wrong spaces, they alter their shape to fit the slot you are trying to fit it into. Example:
if <move (10) steps>
do something
But hat blocks and c blocks retain their shape when put into the wrong space.


Joefarebrother (talk | contribs) 19:20, 31 August 2012 (UTC)

When such blocks are inserted in () tokens, they render as a variable.
3sal2 (talk | contribs) 17:12, 22 September 2012 (UTC)
Now they look funny.
3sal2 (talk | contribs) 00:46, 20 May 2013 (UTC)

Wrapping text inputs

When text inputs are long enough to wrap, they cause rendering problems. Example:

say [really really really really really really really really really  really really really really really really really really really really really really really long] for (2) secs


Joefarebrother (talk | contribs) 19:33, 27 September 2012 (UTC)

Although I supposed you could consider that a bug, it's very rare to have that much text used at once - it would be better to just use a few say blocks, with some of the text in each block. I doubt a bug as minor as this would be fixed.
Lucario621 (talk | contribs) 23:28, 5 October 2012 (UTC)

The parser ignores names of stack blocks shorter than three characters.

I found the source of this "bug". Line 55:

if (script[i].length>2) {

According to the comment in the line above, this is to "ignore whitelines etc.". Couldn't this just be done with a regex?

if (script[i].match(/\s*/) == script[i]) {

Not that it matters much, because there aren't any blocks less than 3 characters.
Scimonster (talk | contribs) 17:48, 30 October 2012 (UTC)

"Sometimes 'Sprite1' at the end of a block causes rendering errors."

  • "Sprite1" is not at the end of the block.
  • There is no block of the form [Sprite1 v] go to [Sprite2 v]

So is it really a bug?
Mathfreak231 (talk | contribs) 23:16, 23 January 2013 (UTC) UPDATE: I gave the bug a different reason, and today I moved it down to the "Resolved Bugs" section.
Mathfreak231 (talk | contribs) 14:00, 26 January 2013 (UTC)

"Comments glitch out of the page if too long."

Not on my computer... There is a horizontal scroll bar and the block stays inside a box so you can scroll through the comment.
Mathfreak231 (talk | contribs) 23:21, 23 January 2013 (UTC)

Most bugs fixed

Apparently, the new version fixed all of the bugs that aren't technical limitations.

Example:

stop all sounds
stop all pinks


3sal2 (talk | contribs) 23:04, 18 May 2013 (UTC)

I was going to suggest we lock this page, and make a new bugs page for the new plugin (if we even need one -- the Github issues page works fine for me!).
Blob8108 (talk | contribs) 08:33, 19 May 2013 (UTC)
Agree with Blob. Either mark this page for heavy cleanup, or make a new one. In the meantime, I'm gonna clean up some of the bugs on this page in my userspace. MF231 12:28, 19 May 2013 (UTC)

Bug fixes

A lot of the bugs have been fixed, but I don't have time to fix the article. Could someone else do it?
OrcaCat (talk | contribs) 15:18, 24 May 2013 (UTC)

Read the section above.
Blob8108 (talk | contribs) 15:54, 24 May 2013 (UTC)
Whoops, I immediately clicked "Add topic".
OrcaCat (talk | contribs) 03:03, 25 May 2013 (UTC)

Sorry

Change Gabriel in the "bottom C" example to XYZ.
3sal2 (talk | contribs) 22:51, 16 November 2014 (UTC)

Yes Done
jvvg (talk | contribs) 00:55, 17 November 2014 (UTC)