Was checking out InterXeptor 3D just now (to compare render speed against my new 3d framework), and discovered some kind of corruption in the scripts - red “undefined” blocks appearing.

InterXeptor is here: http://scratch.mit.edu/projects/10085324/

When I first looked at the scripts I found two of them in the “move one ship” custom block of the “Ships+Lasers” sprite (it was obvious something was wrong in there because the enemy ships were not moving sensibly). However, on subsequent loads of the page there's only one that's persistent (right after “if ship dist < 550 then…”). IIRC, there should probably be some custom block there (will check against a downloaded version). [Checked… what's been replaced is a single block that sets a variable - it's just the “x” component equivalent (“xreltarget” and “ship xdiff”) to the “y” and “z” components in the two blocks just below it.]

Looking at the json I see [[“0”], on the offending line.
As it happens, I also downloaded the first case with the other “undefined” in it (the one that subsequently disappeared). The json for that also has [“0”], on the other offending line (which replaces a chunk of scripting that subsequently reappeared).

I've also seen this happen in one of my projects recently.
Mentioned that here: http://scratch.mit.edu/discuss/topic/11056/

Anyone else seen this? Anyone on ST able to check it out to see if there could be some project corruption problem starting to appear here?

Thanks.

It hasn't happened to me (I haven't checked yet). But I have found that custom blocks in the backpack will turn into red “undefined” blocks which really frustrates me when I need a custom block urgently. I'm afraid this glitch can't be resolved by means other than redoing the scripts.

Yeah, the custom block becoming “undefined” kinda makes a degree of sense if you drag it into a sprite that doesn't have that block defined - though I preferred it when it used to just turn red to show it didn't exist (but kept the block title and parameters intact).

But it's when you drag it back into the same sprite, where that block is perfectly well defined, that it's dead annoying - most reasonably complex script will have a custom block in it somewhere, so it makes the backpack kinda useless for shifting around such stuff…

The “undefined” blocks above are obviously something different, though - chunks of script getting corrupted somehow. (Was wrong in original post when I said I thought it corresponded to a custom block - it looks like just a single “set xreltarget to (ship xdiff) * 5” block is corrupted).

All very

Is anyone else seeing this corruption with the red “undefined” blocks?

I've just had it happen again in another of my projects (the non-experimental 3d demo this time - was comparing speeds against experimental version again, but it went quite obviously wrong when I ran it - fixed it all now [I think!], but…)

Here are a couple of screenshots:

http://imgur.com/LBuF5gu
http://imgur.com/6rKQxMw

In the first one it has corrupted a single block that should set variable “tmpx” in a similar way to the “set tmpy” and “set tmpz” blocks just below it.
For the second one the “when I receive start main loop” should have the same custom block as the “when I receive unpaused” just underneath.

Is it just me? Is it just because these projects are more complicated than the usual?
I'd have thought if this problem was more widespread there would be numerous complaints here…?

Anyone…?

ProdigyZeta7 wrote:

It hasn't happened to me (I haven't checked yet). But I have found that custom blocks in the backpack will turn into red “undefined” blocks which really frustrates me when I need a custom block urgently. I'm afraid this glitch can't be resolved by means other than redoing the scripts.

Well, instead of dragging the custom block, you have to just drag the definition into the backpack instead.

Back onto topic, no, I haven't seen this problem yet.

Very odd…and concerning. I would be very interested in any other cases that show up - so this is basically a bump.

@Paddle2See:

Wondering if the blank costume glitch mentioned in “Questions about Scratch” could be related corruption?
See my post about it.

Ah - this is most likely because copying a script into the backpack does not automatically include the definitions of custom blocks within that script. Probably it should - and Johnm says he has an implementation that will solve this about half way done. But it's not corruption - just something that should work but doesn't yet. (This has always been the case.)

Hi @Lightnin.

No, I'm not using the backpack here. We do cover the custom block backpack issue at one point in the discussion above - I know all about that, and how I work around it. (Good to hear that you're on the case with that, though.)

No, this is definitely some form of project corruption (whether my end because of flash, or something perhaps more worrying to do with the server and complicated projects, I don't know…)

Take a more careful read through what I've said - in particular, note that part where I say it's *not* a custom block that's becoming “undefined” (just regular script), and the part where I mention that I've seen the script ‘heal’ itself on a couple of occasions if I reload without getting caught out by the autosave, and see the other forum post where I saw a considerable chunk of scripting replaced by undefined in the same way…

Agh! Just had it happen again in another project (not yet shared).

Here's a pic of it: http://imgur.com/ogBZSX2

The undefined block has replaced a single block of script that should be just like the block above it, but with ‘y’ replacing ‘x’.
i.e: change y4in by ( (y4add) * (pen width) )

Could see as soon as I ran it that something had gone wrong (obviously, above missing block is meant to do something!)
Took quite a while to find it in amongst all the scripts I have in that sprite…

Happened this time when I ran the project (not even got as far as looking inside and could see it was running wrong) on my dell mini netbook (others I've noticed have been on mac mini) - and I'd just been editing it on the mac 5 mins earlier (and it was running fine when I saved it at that point).

I very much suspect some kind of low-memory Flash problem, since I know I'm pushing it with these scripts - first time I tried the project page the browser stopped responding for a couple of mins, and then flash crashed. Reloaded and it appeared to load fine, but I saw it wasn't running correctly, so went hunting for it. (Didn't mean to autosave it, ‘cos I wanted to check back on mac to see if that saw exactly the same undefined in same place - but I clicked on something I didn’t mean to while scrolling around - blame those too-translucent scrollbars, and the little gap between them and the edge of the editor pane…!)

Looks like we might have another example over here….

http://scratch.mit.edu/projects/2054618/

This is a very short project with only one sprite - so it's probably not related to a low-memory Flash problem. The project is quite old - possibly it's an obsolete block of some sort. Clearly, that is not the case with your projects - so this might be a totally separate issue.

right here: Your text to link here…

Masquerola wrote:

right here: Your text to link here…

That was the color fx block though…

Paddle2See wrote:

Looks like we might have another example over here….
http://scratch.mit.edu/projects/2054618/

The json for above clearly shows this is a block called “changeStretchBy” - probably from some mod (Panther?)
The slot for a number suggested as much (same as happens for that color fx test block, which I'm guessing was some kind of dev gfx testing, maybe to track down the recent Chrome lag issue…)

I'm becoming more covinced this is a problem at my end to do with Flash. I've seen it happen another couple of times, and noticed that if a project seems to be taking a while to load, and looking like it might crash (which it does sometimes, but ends up not in these cases), then that's when it tends to happen. If it looks like it's loaded normally (so not got stuck at the loading bar for longer than normal, and not locked up the browser for a while), then I've not seen it.

Also, those times it happened, and I was ready for it because it looked like it was struggling to load, if I then I just quit & restart Firefox, and reloaded the page again, the undefined blocks go away, and everything looks fine. It's the same behaviour I saw for a missing costume on a couple of occasions (as noted in my post above, and linked to another relevant forum topic).

My feeling right now is that you can probably not worry about it yourself unless you start to notice others reporting simlar things.
I'll keep an eye on it and see if I spot something that suggests otherwise…

But thanks anyway for looking out for it!

Hi, DadOfMrLog and everyone.

Thanks for reporting and digging so deeply into this problem. Actually, there are at least three problems:

1. Real undefined blocks, such as the “changeStretchBy” block in the project mentioned by Masquerola.
2. Broken calls to custom block definitions (e.g. caused by using the backpack to copy a script with calls to a custom block definition).
3. Certain commands getting turned into [[“0”].

The first problem is not a bug, since the stretch blocks were never supported by a released version of Scratch. (Those blocks were an experiment we tried in a pre-1.0 version of Scratch that some Scratchers discovered by looking at the Scratch source code. They actually worked in Scratch 1.4 but were never official and are not supported at all in Scratch 2.0.)

The second problem is definitely a bug. The backpack should copy all block definitions used by a script you put into the backpack. We're working on this, but it's a bit tricky since it involves including a set of (hidden) block definitions in the backpack entry for the script.

The third problem sounds like a bug, but I don't yet understand the cause. However, it doesn't look to me like random data corruption due to slow project loading. I think there must be some construct that's confusing the code that converts between blocks and JSON. If we can isolate that construct, the problem should be repeatable (even in a simple script) and probably quite easy to fix. (If anyone figures out how to reproduce the problem, please post here.) This is the first case like this that I've seen, so I'm hoping it's pretty rare. However, I'd certainly like to find and fix it as soon as possible.

DadOfMrLog, could this be related to editing or deleting a custom block definition?

– John

Hi John,

Thanks for looking at this.

Yes, the first two ways of getting “undefined” are not what I'm worried about here (in particular, I know about the custom block issue, and how I work around it - glad to hear you're on the case with that, though. )

The changeStretchBy block is interesting - hadn't heard of that before (but only been using Scratch since 2.0 anyway…) Would be real nice to have some kind of stretch graphic effect for a costume (like “set size”, but in only X or Y direction - I can imagine any method of combining both stretch and rotation operations on a costume could bring about a degree of confusion for some, though.

It's the third case that I see not infrequently. However, it's also not deterministic - so it can happen differently on different reloads, if I don't save in between. (Once I save, the damage is done - a case where the somewhat ‘trigger-happy’ autosave actually causes more trouble than it prevents, unfortunately…)

All of the cases apart from one have, so far, involved just a single (mainly non-custom) block getting replaced by “undefined”. (See the example pics above that I uploaded to imgur, and the related descriptions of the blocks replaced.)

The case where I saw much more script replaced was in topic http://scratch.mit.edu/discuss/topic/11056/. In that case, it was a whole chunk of script within, and including, a “repeat” block. Could be that it was still just that single block that got corrupted somehow, but it affected the whole of the content…?

BTW, I've left that case intact in the experimental ordering 3d demo project, so the undefined block is still there (since it only affects the ‘space dust’ which is hardly noticeable). You can compare against the equivalent “render dust” custom-block script of the “Dust” sprite in the other 3d demo (that doesn't use the 'experimental ordering) to see what it should look like.

Hope that helps!

these are the three types ive seen: (undefined)

Masquerola wrote:

these are the three types ive seen: (undefined)

hmm thats weird… only one showed up…

these are the three types ive seen: |undefined| |undefined( )| (undefined)

Ok, I think the stretch blocks could definately be of use. If it's a bug due to something being removed, re-add it! ^.^