Anybody who's ever tried to make a game or animation with multiple moving sprites can tell you that layers are a pain.
Yes, you have blocks like:

go to front
go back (1) layers

But there's no way to tell in code which sprites are in what layers, or say, I want this sprite to be in front of that sprite but not this sprite. To solve this problem, I propose that we make a block similar to

<touching [ v] ?>

that would look like

<behind [sprite1 v]?  :: sensing>

It would be really useful, for like, if I wanted sprite2 to be behind sprite3 but in front of sprite1. You could do a script like

when I receive [sprite2 in middle]
if <behind [sprite1 v]?  :: sensing> then
go forward (1) layers :: looks
end
if <not<behind [sprite3 v]?  :: sensing>> then
go back (1) layers
end

You could also make one of those variable blocks that are like,

<<(costume #)or(size)>or<(backdrop name)or(backdrop #)>>

but it's

(layer  :: looks)

This simple sensing block would make layers INFINITELY less painful to order. And, if you put it in the backdrop, it would always be true, no matter what, since the backdrop is layer 0.


If you support this, please reply “support” and why you support it. Maybe also add some other suggestions?

Here is the project version of this post.


Blocks other people suggested in this discussion:
fdreerf also suggested

([layer v] of [sprite v] :: sensing)

fireincarnate also suggested

go (1) layer [in front of v] [sprite1 v] :: looks
go (1) layer [behind v] [sprite1 v] :: looks

GoldBackthewebAlext also suggested

set pen layer to (2) :: pen
(total layers :: looks)

IndianRuby718 also suggested

erase pen in layer (2) :: pen
go to layer (4) :: looks  

Haluria_games also suggested

set layer to (0) ::looks // kinda the same as "go to layer" but I want to show the ST options

SUPPORTERS: (132)
Because the list is so long, I moved it to the notes of the project.


edit: why variables are not a good workaround
trying to use variables as a workaround for the layer problem is incredibly complicated and doesn't really work. This is because, while two variables can be equal, two things can't be in the same layer in scratch. variables also can't take the backdrop, clones, or pen into account. local variables (variables for only this sprite) don't work to fix the clone situation, because the other sprites can't see the local variables. Even assuming you need no clones or pen, setting up a variable comparison system gets exponentially more complicated for every new sprite you create, so for projects with 6 or 7 sprites, it's crazy complicated to try to make a workaround. Imagine how crazy it would be for a project with 20 sprites, like a MAP or game!

Here are some fixed blocks for you:

<behind [sprite1 v]? :: sensing>

(layer :: looks)

Out of curiosity, why choose “behind sprite” rather than “in front of sprite” (or possibly “overlapping sprite”)?

Support. I can see when it can be useful, and I can't think of an efficient workaround.

By the way, you can make a block colored as if it was in a certain category like this:
For example, this:
becomes:

I'm a boolean :: sensing boolean

And you can make dropdowns by adding "[ v]" (space + small V). You can put some text before the space in brackets. This:
Becomes:

A dropdown! [Yay! v]

Thank you guys! Very helpful, I didn't know how to do that before now And the choice of “behind” was because “in front of” is more characters.

Thanks to Slushy70 for supporting from my profile! We now have 3 supporters!

Thanks to @StevenTheSquare for making this to help out so it is not such a pain

Why does it say i have 0 post i have 45 posts

nice, this will help other scratchers develop their projects further without any layer problem, I had this problem before but i sorted it out..

Workaround:

go to [front v] :: looks
set [layer v] to [Infinity] // make it a local variable for each sprite

go to [back v] :: looks
set [layer v] to [0]

go [front v] (x) layers :: looks
change [layer v] by (1)

go [back v] (x) layers :: looks
change [layer v] by (-1)

<(layer) < ([layer v] of (sprite))> // behind
<(layer) > ([layer v] of (sprite))> // in front of

Seth_Zaw, that workaround assumes that sprites don't eclipse one another, but you can't have two sprites in the same layer. Also, that wouldn't work for projects using clones or pen. Additionally, for projects involving more than 6 or 7 moving sprites (and/or clones of sprites) it would get increasingly more complicated having to say what's behind or in front of what else. That said, thanks for trying to help. Also, if each of those variables is personal to the sprite, you can't drag them into other sprites to see if one is bigger than the other. Plus, the workaround in some cases is more complex than the entire rest of the project!

Support. I can see how this would be very useful. If this is implemented, it will make animating so much easier.

I support this because it would be very useful, and the problem we have right now with the ones we have are…

go back () layers

That's perfectly fine to me, I'm talking about the one below.

go to front

You can't go forward by a certain number of layers. I couldn't find a block like this.

OurPrincess, thanks for the support! and, there ARE “go to back” and “go forwards () layers” blocks, they just aren't in the discussion forum block list for whatever reason.

OurPrincess wrote:

I support this because it would be very useful, and the problem we have right now with the ones we have are…

go back () layers

That's perfectly fine to me, I'm talking about the one below.

go to front

You can't go forward by a certain number of layers. I couldn't find a block like this.

Look in the editor and you'll see:

go [forward v] () layers :: looks

However, it wasn't there in 2.0, so it isn't in the forums' block palette.

ooh this is a really neat idea! i especially like it because it makes it pretty easy to make a new custom block, like this:

define go in front of (sprite)
repeat until <not <behind (sprite)? :: sensing>>
  go [forward v] (1) layers :: looks
end

_nix, that's perfect! exactly the sort of thing we need this block for! <3

Support!!!!

Support, it's something I could have used back when I did a lot of animating
(Also I've never used the forums and I don't have a signature, so h)

Support! Although I don't make animations often. But I can see how it will be useful in the future

Thanks to boroy07 for supporting via my profile! We now have 11 supporters!