Sprite Layer reporter

Sonickyle

There should be a new integer in the Looks sction that when the tickbox is ticked, it'll display what layer the sprite is on (with 0 being the topmost). The tickbox would behave like what happens when you tick the tickbox next to:

(costume #)

It could be called:

(layer #)

AonymousGuy

Workaround:

set [layer # v] to [0]
go to front
go back (x) layers
change [layer # v] by (x)

Travellingcritic

AonymousGuy wrote:

Workaround:

set [layer # v] to [0]
go to front
go back (x) layers
change [layer # v] by (x)

Yeah, but the block ould be more effective, you could create a 3d (2.5d) game where size could represent the layer number. I am aware that you could do the same thing with variables, but this would save a lot of bock space. Also to note is size, and the

[spriteI]'s [size] //catigory=sensing

Sonickyle

Travellingcritic wrote:
AonymousGuy wrote:
Workaround:
set [layer # v] to [0]
go to front
go back (x) layers
change [layer # v] by (x)
Yeah, but the block ould be more effective, you could create a 3d (2.5d) game where size could represent the layer number. I am aware that you could do the same thing with variables, but this would save a lot of bock space. Also to note is size, and the
[spriteI]'s [size] //catigory=sensing

This would have to be added too:

([layer v] of [Sprite1 v])

cobraguy

Hmm… Do you have any examples for when the block could be used?

YoghurtMaster

They should add this:

(Layer #)
go infront of [ sprite]
go behind of [ sprite]

stickfiregames

AonymousGuy wrote:

Workaround:

set [layer # v] to [0]
go to front
go back (x) layers
change [layer # v] by (x)

That wouldn't work.

Support.

daves777

Support

DaSpudLord

stickfiregames wrote:
AonymousGuy wrote:
Workaround:
set [layer # v] to [0]
go to front
go back (x) layers
change [layer # v] by (x)
That wouldn't work.

Support.

How?

Semi-support as per the workaround.

stickfiregames

DaSpudLord wrote:
stickfiregames wrote:
AonymousGuy wrote:
Workaround:
set [layer # v] to [0]
go to front
go back (x) layers
change [layer # v] by (x)
That wouldn't work.

Support.
How?

Semi-support as per the workaround.

Layers are effectively a list. When a sprite moves back, all the sprites it passesd move forward a layer, so their layer # variables would no longer be accurate

Zekrom01

75% support due to workaround.
dang it 60second rule

theonlygusti

AonymousGuy wrote:

Workaround:

set [layer # v] to [0]
go to front
go back (x) layers
change [layer # v] by (x)

Not a valid work-around.

Say another Sprite were to now [go to front], this Sprite's (layer #) variable wouldn't be updated.

I support this.

(layer # :: looks)

Last edited by theonlygusti (Oct. 7, 2015 20:22:46)

theonlygusti

Zekrom01 wrote:
75% support due to workaround.
dang it 60second rule

There is no work-around.

stickfiregames wrote:
Layers are effectively a list. When a sprite moves back, all the sprites it passesd move forward a layer, so their layer # variables would no longer be accurate

Cream_E_Cookie

Support!

AlveKatt

Why isn't better layer support a thing?

Please give us more control over this.

Scratcher1002

Cream_E_Cookie wrote:
Support!

Leadrien2366

Support.

JonathanSchaffer

Travellingcritic wrote:
AonymousGuy wrote:
Workaround:
set [layer # v] to [0]
go to front
go back (x) layers
change [layer # v] by (x)
Yeah, but the block ould be more effective, you could create a 3d (2.5d) game where size could represent the layer number. I am aware that you could do the same thing with variables, but this would save a lot of bock space. Also to note is size, and the
[spriteI]'s [size] //catigory=sensing

([sprite1 v]'s [size v]::sensing)

mlcreater

Four suggestions that duplicate this one (I came here because one of them is from 4 hours ago):

panda-wat

maybe while the

 (layer::looks)

block is being made the ST can also add to the other sprite report reporter block like this?

 ([layer v] of (sprite v)

also I support!

Last edited by panda-wat (July 11, 2020 22:53:08)

Discuss Scratch