Treat built-in hotbar, nametags, minimap, crosshair like Lua HUD elements

[Warr1024]

Minetest version

Minetest 5.2.0-dev-44458896 (Linux)
Using Irrlicht 1.8.4
BUILD_TYPE=Release
RUN_IN_PLACE=1
USE_GETTEXT=0
USE_SOUND=1
USE_CURL=1
USE_FREETYPE=1
USE_LUAJIT=0
STATIC_SHAREDIR="."

OS / Hardware

Operating system:

• Linux 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

CPU:

• Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz

Summary

Unable to draw HUDs beneath built-in HUDs using z_index.

Steps to reproduce

Minimal test case mod init.lua:

minetest.register_on_joinplayer(function(player)
        player:hud_add({
                hud_elem_type = "image",
                position = {x = 0.5, y = 0.5},
                text = "[combine:1x1^[noalpha",
                scale = {x = -100, y = -100},
                z_index = -1000000000
        })
end)

Applied on top of MTG (or probably most other games).

Expected result

A full-screen black HUD covers the entire screen, with all existing built-in HUD elements drawn over top of it.

Actual result

• Correct: New HUD is drawn beneath health bar and chat.
• Incorrect: New HUD obscures hotbar and crosshair.

[SmallJoker]

minetest/doc/lua_api.txt

Lines 1263 to 1266 in 4445889

	The `z_index` field specifies the order of HUD elements from back to front.
	Lower z-index elements are displayed behind higher z-index elements. Elements
	with same z-index are displayed in an arbitrary order. Default 0.
	Supports negative values.

If this does not work, please rephrase this as a bug report. z_index was added for this purpose.

[Warr1024]

Oops, according to the doc, it should be z_index not z_order, right?

Well, I tested it both ways and it behaved the same...

[Warr1024]

All the Lua-defined HUD elements are all drawn together at https://github.com/minetest/minetest/blob/master/src/client/render/core.cpp#L90, so they are always above the crosshair and hotbar, and always beneath the nametags and minimap.

[SmallJoker]

You are right that it's currently impossible to change the order of C++-defined HUD elements. They would need to be treated like Lua HUD elements (or even added from Lua rather than C++).
Updated title.

[Warr1024]

Actually defining them in Lua would be awesome, because not only could they then be subject to the same sorting rules, but it would also provide a template for replacing them, or creating additional elements that connect with them properly.

Right now, defining Lua HUD elements that align properly with the built-in ones is a lot of guess-work and fine-tuning, and requires taking into account things like custom font sizes, different screen sizes and DPI, and different scaling options, and in some cases it's not possible to reliably align elements at all.

[hecktest]

+1 for unhardcoding anything that can be unhardcoded. The hearts bar belongs in minetest_game and it's just a nuisance otherwise. So is the built-in concept of "health" or "breath".

[SmallJoker]

For minimap, see #9079.

[Wuzzy2]

👍 I need this for MCL2 when the player wears a pumpkin as head armor. The screen is supposed to

Personally, I don't care whether crosshair and hotbar are hardcoded or not. Obviously, unhardcoding would be nice, but is no means neccessary.
It would be good enough if the offending HUD elements are subject to the same z_index rules as any Lua HUD elements.

For a quick lazy fix: Render crosshair and hotbar after all Lua HUD elements are those are critical. I can see no use case for obstructing those, tbh.

[rubenwardy]

I've had this exact issue recently, and ended up having to make my own hotbar element

I can see no use case for obstructing those, tbh

Custom damage/poison colors. Styling that only partially obscures

[Wuzzy2]

Yeah, right. My quick lazy fix was dumb. So there is no quick lazy fix, apparently.