new layer sensing blocks, <behind [sprite]?> and (layer)

yavuz61035

support, because

AnotherScratcher wrote:
animations!!!

also (possibly) new block idea:

erase all in layer (layer :: custom) :: pen

fox_creations

support! i had also had this pain with these blocks.

wolfbomb

StevenTheSquare wrote:
BlackDragon450 wrote:
when green flag clicked
set x to (bacon)
forever
if <touching ((sprite1) + (player)) ?> then
set costume# to [17]
end
That's… costume, not layer? Not sure you understood the suggestion.

Also, 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!

I support this, but this is an easier workaround (kinda) while this isn't implemented.

when green flag clicked
set [ORDER v] to [1]
broadcast [Order sprites v]

when I receive [Order sprites v]
say (ORDER)
change [ORDER v] by (1)

the sprite in the front will say 1, while the one behind will say 2 and then the one behind that 3 etc…

This works because the one in the front receives broadcasts first. Then the one behind that, behind that, etc. You can use this principle to do many things. For example, make all instances/clones add cloneID(An ID unique to every instance of a clone) to a list. They will add their cloneID from top to bottom. The top item in the list is the clone in front. You can use this information to do whatever you want. Maybe make an auto orderer that orders the clones by Y value. Run with this ^w^

wolfbomb

yavuz61035 wrote:
support, because

AnotherScratcher wrote:
animations!!!

also (possibly) new block idea:
erase all in layer (layer :: custom) :: pen

This wouldn't work as only one sprite can be in a single layer.

wolfbomb

yavuz61035 wrote:
support, because

AnotherScratcher wrote:
animations!!!

also (possibly) new block idea:
erase all in layer (layer :: custom) :: pen

This wouldn't make sense as only one sprite can be in a single layer. This would technically delete all in a layer, but it would only be a single clone. You could just do this instead

when green flag clicked
broadcast [DeleteAtLayer v]

when I receive [DeleteAtLayer v]
if <(Layer :: sensing) = [Some Number]> then
delete this clone
\(or\) :: #000000
hide
end

Last edited by wolfbomb (March 2, 2022 21:10:13)

TheAnimalKingdom42

This would be very useful! It also wouldn't be difficult to implement. The reporter would be great.

define Go to layer(layer)
go to [back] layer
go forward ((layer) - (1)) layers

This workaround is pretty buggy.
I support this!

StevenTheSquare

in response to all the proposed workarounds:

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!

musicROCKS013

Support. This would really help layer control, which is much needed for bigger projects.

you could also use this

set layer to ()

StevenTheSquare

bump

StevenTheSquare

bump

R_Ravenclaw

Oh this is a great idea! Don't know why it hasn't been implemented, it seems so simple and obviously helpful.

Some questions though: say I have Sprite A on Layer 2, and then I send Sprite B to Layer 2 using the new block. Would Sprite B “push out” Sprite A to Layer 3? So basically shift all sprites in layers 2, 3, 4, etc. by one layer to the front?

Also what if there are only, say, 3 sprites, and I try sending one to Layer 10? Would it not do anything, or just send the sprite to the highest layer available (3)?

StevenTheSquare

R_Ravenclaw wrote:
Oh this is a great idea! Don't know why it hasn't been implemented, it seems so simple and obviously helpful.

Some questions though: say I have Sprite A on Layer 2, and then I send Sprite B to Layer 2 using the new block. Would Sprite B “push out” Sprite A to Layer 3? So basically shift all sprites in layers 2, 3, 4, etc. by one layer to the front?

Also what if there are only, say, 3 sprites, and I try sending one to Layer 10? Would it not do anything, or just send the sprite to the highest layer available (3)?

I think the way it works, is like, when a sprite moves up, the other ones move down. so like if Cat is in layer 1, Giga is in layer 2, and Gobo is in layer 3, and Tera is in layer 4, and you move Cat to layer 3, now Giga moves to layer 1 and Gobo moves to layer 2, but Tera didn't move and is still in layer 4.

Last edited by StevenTheSquare (March 14, 2022 23:08:27)

1080GBA

you can use a list and change the order of sprite names in the list when you use the layer blocks

VedanshS933

Support! People have already mentioned why and it's soo easy to use. Probably also add a forward block

forward of [Sprite1 v] ? :: boolean sensing

1080GBA

VedanshS933 wrote:
Support! People have already mentioned why and it's soo easy to use. Probably also add a forward block
forward of [Sprite1 v] ? :: boolean sensing 

i told you, use a list

RubiksRocker

I have found layering in Scratch quite hard, especially as there are only two blocks designated just for layering, even though it's very important in certain 3D projects and some games where you only want a Sprite to come to the front at a certain time. And sometimes, if i have two sprites on the same layer, it glitches and swaps between the two all the time.
I often use the following script:

forever
go to front
set [ghost v] effect to (0)
go to x: (0) y: (0)
end

for Thumbnails when I want to send them to the front.

I would love to see these blocks added to Scratch in the future as it would make layering a whole lot easier.

op456

It could implement all new opportunities in coding, I'd definitely be behind it.

EDGE_X

I have seen your project about this kind of thing, and I totally agree, this would be an amazing idea for Scratch.

I don't however see a bucketfull of useful things that this would do though, only just your typical randomizer I guess.

dertermenter

bump

1080GBA

you []

Discuss Scratch