Hi, in case anyone needs it. It is very hacky, but it works more or less.
You have to run init Layer System before using the other blocks.
I cant see it! Can yoh put the (assumably, a reporter: idk, but i want to know what it is) definition script pic in here?
Hi everybody!
Some comments here. You can play with layers without any JS code. You can get...
- Number of layers:
- My layer number:
- And you can go to a layer number with some calculations (using those "number of layers" and "your layer number") or just doing:
That's all!
Joan
@shushforshasha: not sure why you can't see the project. I've changed the URL so it doesn't contain any spaces.
@jguille2: that way is ok with a few objects, but in more complex projects you really need proper layers.
Oh, very interesting! I've already asked for better layers support.
What values can be assigned to layers? unsigned ints? Are holes allowed? For example: 1, 2, 3, 100, 200...?
UPD. Played with it. Great! That's exactly what was so badly needed for projects with many sprites and many sprites classes. Thank you! Saving your blocks to use them in my projects
As I understand, you have to call INIT LAYER SYSTEM at the start of the program, right?
And one minor drawback: LAYER # returns nothing if layers is not set. May be it's better to have same default value?
Yes, your post is the reason I shared this in the first place :).
The way it is done, you always should give each sprite a layer number at start. I cannot give them a default value (for that, this should be done in snap's code).
Hi David,
Maybe I'm missing something...
Why do you think my solution is only for a few objects? Test it with hundred of clones... and is is ok.
Joan
With your system, the order of the objects is relative, and I needed some absolute layers at some point, so I made these blocks. Anyway, the great thing about snap is how easy is for us to extend its functionality. I just shared them because Pavelbel had the same limitation.
Your system is better in the sense that the code is made with blocks, so better to learn 
I definitely miss something.
(maybe I need to talk with you in Spanish... my English skills are very poor 
)
Of course, layer order is relative. It's the visualization order! If you move one object to the bottom layer, it will be on the 1 layer. If you move one object to the upper layer, it will have the greatest ordering number.
If you want to do other things, you can build a list with all the sprites, and use it to talk to them. You don't need "order numbers", neither "names", because sprites are first class actors.
Joan
Hi Joan! I agree with David that your approach isn't so practical with many objects and object classes.
Here are some toughts.
Yes, it's good for clones of one object, but not for many different.
The major drawback of the "original" layer system is that these layers are not fixed. Each new sprite or clone of a sprite appears on top. And when you send it several levels back it alters the other sprites' layers values.
Here is an example. Imagine a top-down view game where there are several floor sprites (and their clones), several sprites for characters (player, enemies, NPC...) and also sprites for UI (health, mana, items equipped, minimap etc). Each of these object classes can have different number of elements. And there is a rendering rule: UI is always above the characters, and characters are above the floor. How would you preserve the correct rendering order with your approach? More specifically, I'm clonning a new floor sprite. Initially it's on top of all the others. What layer should I assign to it? I always need to know how much "above" sprites are present right now to do it correctly.
And what with David's approach? I decide that layers 1...100 will be reserved for floor sprites, 101...200 for characters and 201...300 for UI and that's all. I just assign a new layer number from range 1...100 to the new floor sprite regardeless of how many chars and UI sprites I now have. I can even use one single layer value for all floor sprites, another value for chars and one more for UI and assign these 3 values to appropriate sprites - because the rendering order inside these classes isn't important. It's way easier to manage.
Another example is an isometric game where the rendering order will be defined by object's distance from camera. You just assign this distance values to sprites layers and you immediately get right rendering order. But how will you manage it with original layers system? I just can't imagine.
To illustrate what Pavel said... This is what I'm currently working on. It was virtually impossible to manage the layers with just blocks, believe me, I tried.
Sé escribir + leer español. :)
@jguille2 already did what i asked, and when i have a pc again, i can maybe use this! I was trying to get a "screenshot" of the stage, with layers the right way.
Your engl eeeeee sh iz bettr den min.
No really. You sound like you know more English than me.
Thanks David and Pavelbel,
I see you want to have a "layer grouping" (layers inside other layers).
But maybe you don't need that layer grouping... just grouping sprites.
If you are basing all with clones (layer for different clone types), you already have those groupings. Using "my clones", "my other clones" ,"myself" and/or "my parent" you get your list with all the objects of your layer.
If you need a different grouping, you can create your lists ("floor", "characters", "ui"...) and add to these all the related sprites when you create them.
And with this groupings, you can do everything: how many ["length of (layer)"], a custom order (the order of that list)...
And to move them to "their layer space", you can do with the blocks I commented, and you only need where their "place" is. And to know it, just something like
And then, you can put this sprite on the bottom of the "layer6". And if you want to put in the top, just ask for the index of "layer7".
All this, only to show Snap! ways to do this.
Joan
I used this on screenshotting, and it worked. Just one problem, it moves everything depending on where the sprite who is taking the screenshot is from 0, 0
Hi @davidgasku!
I've just found a project of famous scratcher griffpatch where he performs depth-sorting, the one you need for isometric game: https://scratch.mit.edu/projects/307388424/ So, it is possible
Your pirates project looks absolutely amazing btw