Coping with the loss of Z-indexes in MV

Z-indexes in RPG Maker MV is vastly different from those in any maker before it. In fact, there technically isn’t a Z index. Object height in MV is based on when the object was added to the drawing layer. In the past, creating a sprite and giving it a bitmap was enough to make it visible on the screen; In MV, you need to create the sprite, add the bitmap, and then give it to the scene to draw it.
 
There are a couple ways to add things to the list of objects to draw, addChild, and addWindow.
 
How object depth works
 
RPG Maker MV uses the Pixi.js v2 library to handle all rendering of the game on the screen. Pixi.js itself does not support z-indexes, which is why MV does not have them. Instead, object depth depends on what order objects are added to a drawable surface.
 
The Scene_Base class inherits from the PIXI.Stage class, which is essentially just a class that holds objects to be drawn on screen. These objects are drawn in the order they are added into the list, meaning that objects will drawn above those added before them.
 
addChild / addChildAt
 
addChild and addChildAt are Pixi’s ways to add an object to the list. addChild will internally just call addChildAt with the index being the next spot in the array.
 
addChild takes one argument, the object to add to the list.
addChildAt takes two arguments, the object to add, and the location to put it. Using this, you can effectively choose the Z-index of your object, but only when first adding it.
 
addWindow
 
addWindow is a function implemented by MV itself. It adds objects to a specific layer that each scene creates, the Window Layer. However, sometimes this is not the desired behavior. An unwanted occurrence of putting multiple things on the same layer is that if they overlap, they overwrite each other. You can easily see this by using the default windowskin and placing two windows on top of each other. That's why addChild is recommended if you know there is a chance objects will overlap. If this won't happen, addWindow will suite your needs perfectly.

 
“But I need my z-indexes! There has to be some way to implement them!” - A lot of people, probably.

Well, there is. You’d need to implement this in some way.

EDIT: removed some stray tags.

EDIT: At some point the forums decided bold text wasn't cool.

edit: I completely misread the Opening post (my bad).

the z-indexes have nothing to do with the editor itself, if the windows and sprites n the game.

I suppose the only editor-related thing it'd affect is pictures, but I've heard this is similar to how they worked in Ace and below, but I don't know.

Could someone post a guide for the total idiot to understand how to order windows now in MV? My own interface is overlapping the messagewindow.. So I need it to be underneath it. But how exactly is this done?

Scene_Map.prototype.createWindow = function(){ this.window = new Window_Foo(...); this.addChild(this.window); // now this.window could be added to some containers. But I also gotta add all build-in windows to a container everytime...}And then I add containers to them and add the windows to the right container and sort the containers? But then I would also have to add all existing windows (like Window_Message) to some container...

Or use addChildAt(). Which is gonna be messy I bet with lots of plugins with windows. That is what I use right now.

Also note that the index starts at 1 and NOT at 0 it seems (at least it does not work with addChildAt(0) for me).

Good lord why did they remove z-indices.. Can't we not just somehow sort the children?

You could override "createWindowLayer" and insert your own container before, so it will be displayed below all normal windows. Like you did i always advise to use your own container and not directly add the sprites to the scene. Remember that you need to add an "update" method to the container and call update on all of its children, so you can propagate update-calls correctly.

Ah this:

// rpg_scenes.jsScene_Base.prototype.createWindowLayer = function() { var width = Graphics.boxWidth; var height = Graphics.boxHeight; var x = (Graphics.width - width) / 2; var y = (Graphics.height - height) / 2; this._windowLayer = new WindowLayer(); this._windowLayer.move(x, y, width, height); this.addChild(this._windowLayer);};Yes but if your window is in between 2 build-in windows you still have to resort to the 'messy-method'. Luckily that is a rare case and I have no need for that. And for your own windows you can add a custom container here indeed and sort it.

You need to specifcy what object ot add when using addChildAt, it won't just know. You'd want to do

this.addChildAt(this.window, 0)to put it behind everything else. If you don't use addChildAt, the new object is automatically put in front of everything else.

also, there is a way to add Z-indexes back, as I mentioned in the OP, however I, nor has anyone else to my knowledge, implemented it into MV yet. If you really want them back, you'll need to find a way to implement this into MV. But really, it's not that bad to get used to the lack of Z-indexes after a while. I will be honest, though, when I first learned they were gone I thought they had lost their minds. But the reality is it's really not that important. We can still get by without them, so adding them back in isn't really that big of a deal. But, I suppose if the new method confuses you, or you really just want the old way back, you have the option of getting it back.

Sorry I forgot to add the window itself it here, I did it right in the real code.

I'm still not used to the new method. Adding z-indices would not hurt performance if you would only update them when changing a z-index. I don't know why one would remove them even though we rarely use them.

Nope I can really confirm that putting this code in Scene_Map:

this.addChildAt(this.window_foo, 0); // does not display the window at allthis.addChildAt(this.window_foo, 1); // works properlySo the index really starts at 1, not at 0.

But then I noticed that my GUI stays visible when fading out/in. It's on top of the fade-overlay...

This is where it happens:

Scene_Base.prototype.createFadeSprite = function(white) { if (!this._fadeSprite) { this._fadeSprite = new ScreenSprite(); this.addChild(this._fadeSprite); } if (white) { this._fadeSprite.setWhite(); } else { this._fadeSprite.setBlack(); }};But Scene_Map inherits from Scene_Base. Yet adding the child at 1 does not seem to put them underneath any sprites... Sprites have a whole different way of ordering compared to windows?

How do I order my window to be underneath the fading effect?

Using the methods described here, would it be possible to modify Scene_Battle so that actor sprites (and presumably animations and damage popups) overlap StatusWindow? By default, the sprites appear to be rendering behind the window.

Edit: sorta answered my own question. I was able to make some progress by loading a separate image along with the sprites, like so:

Sprite_Actor.prototype.initialize = function(battler) { Sprite_Battler.prototype.initialize.call(this, battler); this._actorHUD = new Sprite(); this._actorHUD.x = -119; this._actorHUD.y = -40; this.addChild(this._actorHUD); this._actorHUD.bitmap = ImageManager.loadPicture('Unit');};Now to see if I can not display the actual sprites while still displaying my HUD panel...

You want to add them in front of the status window? Well, if you change an object's parent, Pixi.js (the graphics library used by MV, which handles the object 'depth') will automatically handle it. So it you really want the status window behind everything in the battle, you might be able to just move the entire windowlayer to the bottom. I'm not sure how that would go with the battlebacks, though, the windows would probably be covered.

Thanks for the reply. I've been looking into it, and what I ultimately want to do is make the battle animations and damage popups draw above everything else.
 
Rearranging the display order causes the battlebacks to cover the windows, like you predicted. Makes me wonder if it's possible to split Scene_Battle's CreateSpirteset into two separate steps, e.g. one for background stuff and one for actor animations/popups.
 
Edit 3: Yup, definitely possible.

i need my z index >.<.

when i shift the graphic... using my plugin (EST - GRAPHIC SHIFT)... the image is not "z indexed" properly >.<.

example:

i create a table event. then i create a doll event. in that doll event i shift the graphic by 8 pixel to above... when they share same coordinate. the doll graphic is placed behind the table... >.<. because it's y value is lower...

i'm still finding the code where that executed... (making lower y value event graphic to at the back of higher y value event graphic).

then i will give them z index !!!

It's not really a loss, it not even a feature I used at all. I could get the concept of z indexes working with third party libraries but there really is no need.

after research MV do have z value... but only for some 'things'

event / player / follower / vehicle z formula:

z = priority type * 2 + 1

1) event = event priority type > below chara = 0, same as chara = 1, above chara = 2, tile event = 0

2) player / follower = priority type = 1

3) vehicle = airship => if driving priority type 2 else 0.

                    other vehicle => priority type = 1

source : rpg_objects.js

1) shadow = 6
2) balloon = 7
3) animation = 8
4) mouse destination sprite = 9
source : rpg_sprites.js

hope this help people that want to use z value.