Putting sprite's in their appropriate layers is a tad tricky at times, and when you have hundreds of sprites (taking into account clones), layers can be very messy, as Scratch gives you no direct way to analyze and manage them, but only indirect ways.

My proposal is simple:
1. Add a sensing reporter;

([layer v] of [Sprite1 v])

2. And another layer tool;

go to layer ()// category=looks

Also, why can't we make custom blocks by right-clicking in the scripts area? I hate having to make a custom-block then have it's define hat-block appear all the way at the upper-left corner, which can literally be miles away. Can we just right-click to have it appear on that spot?

Support both suggestions

It's easy enough to do “go to layer (N)”:

define go to layer (N) // note that the top layer is zero for the way it's written here
go to front
go back (N) layers // replace with N-1 if you want top layer to be one

You can also make the above custom block run without refresh, so there is no chance of flickering as the sprite moves to top then back down the layers.

A reporter for the sprite layer would be interesting… it'd certainly show how often the layer number you've set it to (using “go to layer”) gets changed, and how hard it is to keep track of it all…


More generally, I think a lot of the problem with layering is that it isn't obvious how the layering works for the sprites and reporters, both visible and invisible.

And, yes: note that I said “reporters”, and that I said “invisible”…

After spending a while investigating how the layering works in Scratch (I guess it's really in Flash), I finally understood that every object ever shown effectively becomes a layer - every sprite, every clone, every reporter (including every variable!), and that they all still take up a layer even when these things (sprites/clones/reporters/variables) are hidden from view. (Though I'd assume when a clone is actually deleted, it gets removed from the layering, and everything below it shifts up a layer.)

This is one of the reasons why it's so hard to use “go back (N) layers” effectively (and the same would be true of “go to layer”) - because you have to keep track of everything, including the variables, reporters, hidden sprites, etc…

I wonder if more useful layering blocks might be something like:

go to layer behind [sprite v] // category=looks
go to layer in front of [sprite v] // category=looks

The main problem I can see there is that you can't use it to get behind/in front of a clone, only an original sprite (though your original reporter has that problem, too - maybe it'd be more useful to just have a “layer” reporter?)


With regard to placement of custom blocks, this issue has been an annoyance for a considerable time…

Part of the reason for the

go to layer ()// category=looks

would be you could use that directly with the reporter sensor. This

go back ([layer v] of [Sprite1 v]) layers

would seem a lot more pointless to me than this:

go to layer ([layer v] of [Sprite1 v])// category=looks

^That still wouldn't work exactly though, so what would be best is the “go to layer infront of/behind” suggestion you made.

No one would like to see this? Honestly I think this is a little thing, that'd be a large help when dealing with large volumes of clones.

This is nearly as complicated as the work around, in either case you have to know how many sprites are on screen, at which point “go back x layers” is the same as “go to layer x”…
I duno, layering is a pain on it's own, and not much can be done.

Well the sensor at least would be sweet, no?

xlk wrote:

This is nearly as complicated as the work around, in either case you have to know how many sprites are on screen, at which point “go back x layers” is the same as “go to layer x”…
I duno, layering is a pain on it's own, and not much can be done.

I agree.

Well what about the

([layer v] of [Sprite1 v])

suggestion? And what about

go to layer infront of [Sprite1 v]// category=looks

? Those would both be useful no?

dusty22 wrote:

Well what about the

([layer v] of [Sprite1 v])

suggestion? And what about

go to layer infront of [Sprite1 v]// category=looks

? Those would both be useful no?

I think it would be useful, but I'm afraid current mechanics of layers would not allow to implement this. I am not sure, but I think that currently new layers are created on demand. Let's say you have on sprite ‘A’ at layer 4 and another one, ‘B’ at layer 5. Now a new sprite is created and moved inbetween A and B. This would create a new layer 5 for the new sprite and shift the others back one layer.

So there is no absolute layer number, which is most likely the reason that current blocks only provide relative numbers for changing the layer. With the new blocks you suggested, Scratch would need to switch to an absolute layer model, requiring a lot of changes in the current model and we might to lose the possibility to by always able move something onto a layer inbetween two sprites.

tricky - this issue is causing me worlds of pain - what about this - could this feasible do you think?

go to front
repeat until <behind [ otherSprite v]?>
go back (1) layers
end

I'm quite a noob at scratch, could someone tell me what the red blocks are?

djsaintjay wrote:

I'm quite a noob at scratch, could someone tell me what the red blocks are?

They're blocks that aren't in Scratch.

Ok thank you.

Oops. I mean Scratch 2.

whats scratch 2?

masterminymike wrote:

whats scratch 2?

Scratch 2.0

Support

If this would be implemented, then a local layer block would be needed, as a clone couldn't find it own layer without it.

<layer>// category=looks

this is outdated but sadly layering problems ruined my game and i'm disapointed D:<