Luanti 5.12.0

[Krock]

Luanti 5.12.0 has been released!

Blog post: https://blog.luanti.org/2025/05/24/5.12.0-released/

Highlights

• We have switched to SDL for input. This comes with many benefits
• Android: New (optional) dig/place buttons as an alternative to short/long tapping.
• Main menu: New Reviews tab for ContentDB pages.
• Main menu: The server list is now more intuitive to use when searching or removing favourites.
• The default UI style was changed from 3D to flat design.

Changelog: https://docs.luanti.org/about/changelog/#5110--5120
Source code: https://github.com/luanti-org/luanti/tree/5.12.0

Compatibility notes

• This is the first release to use SDL2 on all platforms. Key bindings now use scancodes instead of printable characters. You will be prompted to recheck your key assignments when starting Luanti 5.12.0 the first time.
• Modding: Stricter node and item registration checks were implemented to avoid bad practices in mods.
• Modding: Multiple fixes related to mesh scaling and skinned meshes.

For details, please have a look a the changelog

Downloads

Refer to the Assets section on the GitHub release page: Luanti 5.12.0

Which file do I need to download?

• Windows: win64 (common), win32 (old systems)
• MacOS: macos*_arm64 (for Apple Silicon), macos*_x86_64 (for Intel systems)
• Android: arm64-v8a (common), armabi-v7a (older devices), x86 (ChromeOS, budget), x86_64 (ChromeOS)
• Linux: check for updates in your package manager (WIP)

[ROllerozxa]

This is the first release to use SDL2.

Yay for SDL! Been a long time coming.

I have also gotten my builds of Luanti updated for 5.12.0, if anyone is using those:

• Luanti Windows RUN_IN_PLACE=0 builds
• Luanti Linux AppImage builds
• Luanti Linux headless server builds

[Nininik]

HELLL YEAHHHHHHH!1!1!1!1!1!1!11!!11!1!1!1
Question. Can we still register nodes with the : prefix? Like :ugx:blockfromanothermodbutsamename

[TenPlus1]

W00t! thanks devs and devesses for the new release :)

[Krock]

Question. Can we still register nodes with the : prefix? Like :ugx:blockfromanothermodbutsamename

Yes. That is documented and thus still allowed. What has been restricted is undocumented behaviour, such as:

• Adding new keys to registration tables in the async or emerge (Lua) environment (the values originate from the main Lua thread, thus modifying those does not make sense)
• Additional warnings when trying to use metatables. (Those conflicts with the builtin code to "assign" default values to item definitions)
• Registering or overwriting any items/ABMs/whatsoever after the server has already been fully initialized.

If you're curious about the effective code changes, please have a look at this PR.

[MatyasP]

1) When it will be placed on main site luanti.org?
2) And what is meant under the "migration"? Is it all "opening / using worlds, created in older versions, in 5.12+ versions", or only "upgrading / converting world to coords definition by 5.12+"?
3) Are or could be openable worlds created before 5.12 in game on 5.12+ "in compatibility with older versions" (with reading and writing in older coords)?
4) Could be created (in near future) tool for converting newer (or to-newer-converted) worlds to older coords definition (if will be technically possible for the specific world)?
5) Are 5.11 and older mods combatible with 5.12 worlds without mod update (mainly, AdvTrains)?

[Blockhead]

1) When it will be placed on main site luanti.org?

The main page: When someone with permission gets to it
The downloads: When each platform updates. For instance, there is always a lag between release on GitHub and when F-Droid and Google Play will publish the latest version.

2) And what is meant under the "migration"? Is it all "opening / using worlds, created in older versions, in 5.12+ versions", or only "upgrading / converting world to coords definition by 5.12+"?

You have to make an effort to migrate, it's not automatic. sfan6 recommended switching database backends to force it.

3) Are or could be openable worlds created before 5.12 in game on 5.12+ "in compatibility with older versions" (with reading and writing in older coords)?

If a world was created in 5.12, it will never be compatible with older versions.
If a world was created before 5.12 and never migrated, it is still compatible with older versions (at least back to the last breaking change in 5.7 which moved from zlib to zstd).
If the world was migrated on 5.12 (see previous answer), it will never be compatible with older versions afterwards.

4) Could be created (in near future) tool for converting newer (or to-newer-converted) worlds to older coords definition (if will be technically possible for the specific world)?

If you want such a tool you need to make it. It should not be too difficult, but I expect that the core developers want to focus only on migrating forwards and not backwards. The only change to world database storage is that the x, y and z coordinates are now individual keys/columns instead of the old packed format.

It is worth recommending at this point that if you intend to migrate a world, back it up first in case you will ever consider returning to older engine versions.

5) Are 5.11 and older mods combatible with 5.12 worlds without mod update (mainly, AdvTrains)?

Advtrains worked fine on 5.12-dev last time I checked, and that version was close to this release. And it certainly loads, and platforms loads and so on.

Any mods that were broken by the increase in strictness for node and item registration checks were doing something very wrong. I expect we will see news from any such mods soon, and it may take some software re-architecting to fix dependencies (one of the main reasons people would register after world load is to try to avoid dependency problems that shouldn't exist if the mods were more modular; anyway it's one of my favourite topics).

[Linuxdirk]

Whatever was done: It gave me a performance boost.

On same hardware and settings I now have 45-55 FPS instead of 30-40 FPS.

[MatyasP]

Thank you for you answers!

2) And what is meant under the "migration"? Is it all "opening / using worlds, created in older versions, in 5.12+ versions", or only "upgrading / converting world to coords definition by 5.12+"?

You have to make an effort to migrate, it's not automatic. sfan6 recommended switching database backends to force it.

How much big is the data size increase of map.sqlite between older and newer version? Over 50%, about 10%, under the 1%...? Or is it very, very individual?

[Wuzzy]

It’s such a small change but I think the new flat buttons in the default style make perfect sense. The gradient buttons were such an oddball.

Still, I believe the whole default style is so depressing, it needs a complete redo as there is too much artistic inconsitency (weird mix of pixel style and "tech demo looks"). I know there has been a lot of debate that went nowhere but I wonder if the main menu could be improved JUST by theming alone, i.e. make a high-quality formspec style, no additional programming or layouting; just to get the ball rolling.

The controls rework is a welcome change; finally we get to rebind ALL the keys without minetest.conf hackery! :-) The old keybind menu was so ancient, I’m glad to see it replaced.

Then the Lua API updates are usually the ones I’m most interested in, and not much happened here, but it’s the small things that can be important: The camera mode can now be forced, allowing me to improve the Repixture spyglass. You can now force a formspec to stay open. It’s the small things, especially the de-hardcoding of all things Luanti should not be underestimated. :-)

The "node" visual for entities is also very useful. I noticed this update seems to finally fix ALL rendering bugs of falling nodes if the node that is falling has an obscure drawtype. I’ve tested it in DevTest. This is of special interest for me because in the past I manually hacked so many special cases into the falling node builtin code to fix issues like wrongly rotated falling stairs, or nodes with the wrong color, etc. And it still didn’t cover everything. But now all of that is cleanly fixed by that new visual; every falling node now looks like the real node. I think the only exception is world-aligned nodes, where the falling node might look different as a normal node, depending on its coordinates. But I can’t think of a reasonable rule, so I don’t think this is even a bug. But all drawtypes where there is no excuse to be rendered incorrectly, those work now.

I’m disappointed the PR for hypertext tooltips has been stalling for a very long time; it would be a very welcome addition to gamedevs and players. I really wish this PR will succeed one day.

[Blockhead]

How much big is the data size increase of map.sqlite between older and newer version? Over 50%, about 10%, under the 1%...? Or is it very, very individual?

I don't have the data to compare; the effect should be slightly bigger, but negligible. It only changes the keys and not the block data, which is by far the biggest size. Unless I haven't accounted for something like indexes - but Luanti does not use range queries (as sfan5 has mentioned before), so there won't normally be custom indexes in the database, just the normal one on the compound key x, y, z.

[Blockhead]

It’s such a small change but I think the new flat buttons in the default style make perfect sense. The gradient buttons were such an oddball.

Still, I believe the whole default style is so depressing
...

I think it looks more so now that the gradients are gone. They lightened it up a bit, but now that's gone. I will miss the gradients personally, but I know I'm the minority. Another odd piece of Irrlicht gone (at least I think this was inherited from there).

, it needs a complete redo as there is too much artistic inconsitency (weird mix of pixel style and "tech demo looks"). I know there has been a lot of debate that went nowhere but I wonder if the main menu could be improved JUST by theming alone, i.e. make a high-quality formspec style, no additional programming or layouting; just to get the ball rolling.

Yes, it would be good if we could not let perfect be the enemy of better about this.

The controls rework is a welcome change; finally we get to rebind ALL the keys without minetest.conf hackery! :-) The old keybind menu was so ancient, I’m glad to see it replaced.

Personally I have to say I found it much quicker to just click controls and see all my controls in one place. Now I have to click settings then Keyboard and Mouse, and then scroll to the right section. I used to be able to see them all in one screen. This probably works better for mobile users though; the old menu probably had touch targets that were too small.

Congrats

Since I haven't mentioned it yet, I do want to express my thanks to all the contributors for another release with great improvements and fixes. The release cadence is actually pretty good and not that hard to keep up with stable releases. There are changes along the way not everyone will agree with, but it's been a slow upwards trend all the way from 5.0.

[Astrobe]

Special thanks to the person(s) who added the 32 keybindings for the hotbar slots keybindings.

[MatyasP]

The controls rework is a welcome change; finally we get to rebind ALL the keys without minetest.conf hackery! :-) The old keybind menu was so ancient, I’m glad to see it replaced.

Personally I have to say I found it much quicker to just click controls and see all my controls in one place. Now I have to click settings then Keyboard and Mouse, and then scroll to the right section. I used to be able to see them all in one screen. This probably works better for mobile users though; the old menu probably had touch targets that were too small.

I think that actual place is more normal but not so simple as had been in older versions. Now, I must say to my friends that will join to Luanti server in future "download 5.10, set keys as on photo, copy minetest.conf and next to download the 5.12" - there will be simplier download 5.12 and shared minetest.conf

Actual keys settings are not bad... but I think that keybinds in older GUI variant is for PC players better.

[PiTTi]

Hi,
Thanks for your work on Luanti. I noticed that since the 5.12 update, my server no longer recognizes newly uploaded mods (no entry in the world.mt file), and temporarily disabled mods are deleted from the world.mt file. Is this my fault, or have I missed something, or is this intentional?

[ChrisZ]

Awesome! Thanks for your work!

One short question: Is there a reason you use SDL2 instead of SDL3? 🤔

[yw05]

One short question: Is there a reason you use SDL2 instead of SDL3? 🤔

SDL3 was not yet released when the CIrrDeviceSDL code was initially written.

[ChrisZ]

SDL3 was not yet released when the CIrrDeviceSDL code was initially written.

Ah, okay! So will it be ported to SDL3 in the next release?

[rubenwardy]

We plan to stay on SDL2 until all our supported platforms has SDL3 available (primarily Debian)

[yw05]

Ah, okay! So will it be ported to SDL3 in the next release?

I don't consider this likely given that the immediate gain from switching to SDL3 is IMO quite limited. Although I could imagine SDL3 being used in 5.15 or so, at which point SDL3 will (hopefully) be available in Debian.

In the meantime, we (currently) still allow building with non-SDL2 IrrlichtDevices. Dropping these devices and refactoring some parts of the codebase (particularly input handling) would make it easier to use more features provided by SDL.

[Linuxdirk]

(primarily Debian)

You’re doomed! Doomed! 🤣

It’s in the less outdated ones at least: https://packages.debian.org/search?keywords=libsdl3

Let’s hope they will implement it within the next few years.

[Blockhead]

(primarily Debian)

You’re doomed! Doomed! 🤣

It’s in the less outdated ones at least: https://packages.debian.org/search?keywords=libsdl3

Let’s hope they will implement it within the next few years.

Trixie should actually hit stable relatively soon, either in time for 5.13 or almost certainly for Luanti 5.14

[j8810kkw]

Just read the blog and there was a mention on texture filtering and many more stuff. It interests me, but one question. What was the "blur" thing that was talked about in the case of texture filtering?

[Blockhead]

Just read the blog and there was a mention on texture filtering and many more stuff. It interests me, but one question. What was the "blur" thing that was talked about in the case of texture filtering?

Texture filtering makes textures appear smoother by drawing the textures with "more detail" than the textures actually have, done through a bit of trickery that "blurs" from one pixel to the next. This looks atrocious on textures as low as 16 or 32 px wide, where a hard pixel looks better. But people looking to "max out" their graphics would usually turn filtering on even if they were still running a low resolution texture pack. Filtering is no longer applied to textures under 192 px wide, to improve the look of low resolution textures.

[j8810kkw]

Texture filtering makes textures appear smoother by drawing the textures with "more detail" than the textures actually have, done through a bit of trickery that "blurs" from one pixel to the next. This looks atrocious on textures as low as 16 or 32 px wide, where a hard pixel looks better. But people looking to "max out" their graphics would usually turn filtering on even if they were still running a low resolution texture pack. Filtering is no longer applied to textures under 192 px wide, to improve the look of low resolution textures.

Thanks BlockHead, I am making a little mod myself and am looking forward to testing this out.
Edit: I also have one question concerning the "Exitbutton" sign bug if it somehow affected the
engine or maybe it's limited to minetest_game's new update.