Please Add: Send Forward/Send Backward Commands...

<font size="5">Please Add: Send Forward/Send Backward Commands...</font>

Hi,

I've been using "Construct 2" for a few days now.

I have a suggestion for the IDE:

Currently there is only

"Send To Bottom Layer"/"Send To Top Layer"

Z Order commands in the IDE.

I think it would be helpful to add:

"Send Backward"/"Send Forward" Z Order commands.

Hopefully you can add this to the next update, thanks!

JeZ+Lee

For now you might notice those say "move to bottom", "move to layer", and "move to top".

Move to bottom, and move to top mean place on top or bottom of their respective layers, not some other layer.

For now you might notice those say "move to bottom", "move to layer", and "move to top".

Move to bottom, and move to top mean place on top or bottom of their respective layers, not some other layer.i,

Understand...

I think these new commands would be very helpful if they were added.

JeZ+Lee

They would be immensely helpful and it's been asked. I have no idea why it hasn't been added yet, unless for some reason Ashley thinks the current commands are enough or it would be difficult to add the new ones. It would make things a TON easier for a lot of normal tasks.

They would be immensely helpful and it's been asked. I have no idea why it hasn't been added yet, unless for some reason Ashley thinks the current commands are enough or it would be difficult to add the new ones. It would make things a TON easier for a lot of normal tasks.i,

Microsoft Publisher has similar commands:

• Bring to front
• Bring forward
• Send to back
• Send backwards

I don't understand why SCIRRA does not include

bring forward/send backward commands in the IDE?

JeZ+Lee

Wouldn't a z-index be more appropriate?

Bring fw/bw is nice, but the most useful would be Number z-ordering, like in actionscript...

I've seen Ashley 's reply here, but I would agree with linkman that it just eats cpu

I'm doing something like this, and ordering everything every second just gives back nice freezes... while I could handle it in a much lighter way when each instance is created on a 6-level number-based depth system

"For each with families" does NOT work with more than one object type, so until families become more robust, it's not a very useful argument.

Couldn't you get away with a variable numbered say 1-10 and move your objects to layers based on their value?

What might be nice for the family issue is a for each object in layer.

If it was possible to group dissimilar objects like that.

Basically:

For each object on layer 0, ordered by self.y, send to front.

Any thoughts Ashley, or were you planning on going with an index at some point?

Hopefully we'll be adding better Z order controls for both the editor and runtime in future.

C-7 - families work great AFAIK and don't have any issues with for-each. You might want to make a post to the bugs forum if you think there is a problem.

Good to hear Ashley!

Also I can confirm "for each families" do work for me

— E Bear I need to have everything on the same layer because there's an effect applied to it, and I can't apply it on several layers for both performance and the look I'm after

Hopefully we'll be adding better Z order controls for both the editor and runtime in future.

C-7 - families work great AFAIK and don't have any issues with for-each. You might want to make a post to the bugs forum if you think there is a problem.

Ashley Do they allow more than one object type? They work fine if you build your entire level out of one object type. I never said there was a bug, just that it is severely limiting. I can only z-order based on y by either hackishly using an array (which it seems I may have to resort to), or using Rex's plugin that does it by layer. But with the plugin, I can't exclude anything.

If I'm using a spriter object, for instance, it will shuffle the objects in with everything else as opposed to keeping them relative to the scml object. So I can't use a family and include the objects I want because I use both tiled backgrounds AND sprites (and scml, but that's beside the point). And I can't simply use the plugin because the spriter body parts are z-ordered with everything else.

It could at least be gotten around with "move forward"/"move backward", but there is no really usable solution to this, to my knowledge, unless I essentially load all y values into an array every tick or so, sort it, and z-order based on that.

Hi, I am the original poster. Better z order controls in next release would be great! - Just need "Bring Forward"/"Send Backwards" commands to be added to the IDE, thanks! - JeZ+Lee

Just thought of a couple things that might help for now, and it's not too hard to do.

Pick all the instances, sort by position (X/Y), and bring the highest/lowest to the top/bottom as desired.

Give instances a variable that denotes their "depth" and you can then arrange the Z-order on the fly by comparing the "depth" variable.

Ashley, that might be a very simple way to implement Z-ordering: a built-in depth variable.