This happens in both the offline and online editor, and it is extremely devastating for larger projects.

Steps to reproduce:

1. Have at least one sprite
   
2. In the stage or another sprite, change the 2nd dropdown of this block to a sprite
   

   ([... v] of [Sprite1 v])

   It doesn't have to dragged out into the editor, just changing it in the block palette will do
   
3. Try to create a variable, list, or custom block
   
4. The creation will appear to fail because the variable/block is not added to the palette
   
5. Go to anywhere else, another sprite or the costume/sound editor, then go back to the scripts you were at
   
6. You will see all* scripts bunched together in one place, as well as the variable/block you just made showing up in the palette
   

*After testing, I found that scripts that I moved after alteration of the sensing block would remain where they were, but all the others that were not touched would be affected

Can you send over the project you're working in? Is this in the whole project or just the sprite? Thanks!

Banana

I can reproduce this:

banana439monkey wrote:

Can you send over the project you're working in? Is this in the whole project or just the sprite? Thanks!

Banana

You can easily recreate the bug in any project. It only affects the scripts of the sprite/stage you were just in.

I spent about an hour last night re-organizing the scripts, and found that the issue can be avoided:

• Duplicating the sensing block that has the sprite name used is safe
  
• Placing an operator in the target field is safe
  
• Clicking on the field but not changing the target to another sprite is safe
  
• Changing the sprite dropdown in a temp sprite and moving the block over to your working sprite is safe
  
• Changing the sprite dropdown, going to another sprite, and then going back to your original sprite is safe
  

It's just anytime the sensing block's target field changes manually, you have to avoid refreshing the editor.

Edit: More testing. I think I found an important trigger that doesn't require making a variable/custom block. You can change the blocks in the palette to these, but it won't work when dragged out:

([backdrop # v] of [Sprite1 v])
([costume # v] of [Stage v])

Meaning, there is a discrepancy between validating blocks in the editor versus validating them in the palette.

__init__ wrote:

I can reproduce this:

CR variable not showing.

Zro716 wrote:

banana439monkey wrote:

Can you send over the project you're working in? Is this in the whole project or just the sprite? Thanks!

Banana

You can easily recreate the bug in any project. It only affects the scripts of the sprite/stage you were just in.

I spent about an hour last night re-organizing the scripts, and found that the issue can be avoided:

• Duplicating the sensing block that has the sprite name used is safe
  
• Placing an operator in the target field is safe
  
• Clicking on the field but not changing the target to another sprite is safe
  
• Changing the sprite dropdown in a temp sprite and moving the block over to your working sprite is safe
  
• Changing the sprite dropdown, going to another sprite, and then going back to your original sprite is safe
  

It's just anytime the sensing block's target field changes manually, you have to avoid refreshing the editor.

Edit: More testing. I think I found an important trigger that doesn't require making a variable/custom block. You can change the blocks in the palette to these, but it won't work when dragged out:

([backdrop # v] of [Sprite1 v])
([costume # v] of [Stage v])

Meaning, there is a discrepancy between validating blocks in the editor versus validating them in the palette.

Can you define bunched together? From what I'm thinking, CNR. My browser / operating system: Windows NT 10.0, Chrome 74.0.3729.131, No Flash version detected

Banana

banana439monkey wrote:

Can you define bunched together? From what I'm thinking, CNR.

As seen in @__init__'s demo gif, all the sprite's scripts move to one place in the corner. Now for me, in one particular project they moved elsewhere in the editor because there were tons of scripts everywhere. It seems they don't move to the corner per se, but actually to wherever the origin of the workspace is.

I reported this bug back in January: https://github.com/LLK/scratch-gui/issues/4400

I did come up with a PR which fixed it, but that wasn't merged for a variety of sensible reasons: https://github.com/LLK/scratch-gui/issues/4400

Right now the ST is working on converting the normal categories to be internally stored the same way extensions are. This bug will probably be fixed when that's finished. (It's worth noting that that is a very large task, though – it'll probably still be a while before it's finished, though I think it's what a couple ST members are personally prioritizing their work-effort/time on.)

Happened to me too.

I came to the () of () block, selected a sprite in the right area, and then selected a private variable from said sprite in the left area and then Scratch froze for a couple seconds and the scripts area scrolled back to the top. I clicked on a different sprite, and then clicked back on the sprite I was editing and all the scripts were in a pile like the image above.

If it helps I was using Scratch with 80% page zoom and with the blocks zoomed out by three levels.

Alzter wrote:

If it helps I was using Scratch with 80% page zoom and with the blocks zoomed out by three levels.

When I first made the issue, I thought zoom level had to do with it too.. testing shows it probably doesn't really, though.

Funny you use Scratch zoomed so far out. I'm normally zoomed several levels in, in both the UI and the block workspace!

Happens a lot and is destructive.

Block Pile Up

all of my block keep going to the same place and it ruins everything

Disable the second menu in the block in the palette as a temporary fix?

([ v] of [Stage v]) // can't change second input in palette (until bug is fixed)

It even happened to griffpatch and he couldn't undo it.

Another way to reproduce this is to simply have two or more sprites, select one sprite as the second option in the of block, and then switch to the other sprite.

It even happend to me

This happened to me as well:

Not only that, but changing the word “Stage” to any sprite shifts your position in the code editor almost to the top and a bit to the right.

Now, personally, I clean up my code every time I add a new script to keep it organized (I can't stand to see overlapping code or inconsistencies in the distance between each). After this pileup happens, if you do “Clean up” again, it puts your scripts back in the order they would be if you had done “Clean up” before the glitch.

Edit: Slight typo

I think that this is a scratch 3.0 bug.

so glad this was patched!!!!

My browser / operating system: ChromeOS 13310.76.0, Chrome 85.0.4183.108, Flash 32.0 (release 0)

_nix wrote:

Alzter wrote:

If it helps I was using Scratch with 80% page zoom and with the blocks zoomed out by three levels.

When I first made the issue, I thought zoom level had to do with it too.. testing shows it probably doesn't really, though.

Funny you use Scratch zoomed so far out. I'm normally zoomed several levels in, in both the UI and the block workspace!

meanwhile i cant use scratch at 100% zoom because it looks way too big and i have to use 75%

scratch 3 scratch 2 huh?

HUH??? I think someone necroposted but it got sent to a dustbin because it said 412 and said I didn't have access…
I think I should report this to be closed anyways, last time someone posted was like a year ago.

scratchcode1_2_3 wrote:

HUH??? I think someone necroposted but it got sent to a dustbin because it said 412 and said I didn't have access…
I think I should report this to be closed anyways, last time someone posted was like a year ago.

Yeah they did, I saw the posts.

medians wrote:

scratchcode1_2_3 wrote:

HUH??? I think someone necroposted but it got sent to a dustbin because it said 412 and said I didn't have access…
I think I should report this to be closed anyways, last time someone posted was like a year ago.

Yeah they did, I saw the posts.

I didn't, but yep, /topic/412/ is the main deleted post thread. I kinda wish /unread/ would make sure the latest post is actually part of the thread the notification was for, but oh well

That said, fellow Scratcher @adroitwhiz fixed this bug in May/July 2020 (as DabDatBass pointed out lol), so I'll close this thread now! Yay for really destructive bugs getting fixed ^__^