Minetest Forums

HUD Library [hudlib]

• Version: 0.1, beta
• License: MIT (see LICENSE)
• View on GitHub

HUDLib aims to create a very simple and easy to use API in front of a powerful and complex backend. Sure, there are other mods that introduce APIs to simplify HUD development, but they all focus on some type of statbar (used for things like health) and don't support other HUD elements. However, HUDLib will support all available HUD elements (including statbars and waypoints), wrapping them in an API built to lessen the amount of code you need to make your HUD not only look nice but also be functional.

Why HUDLib?

When stacked up against other HUD libraries, HUDLib excels in that it supports all HUD elements and has an intuitive API allowing you to do more with less code (see features for more information). However, how does it stack up compared to the default Minetest HUD API?

• HUDs are identified by a name chosen by the modder rather than by arbitrary IDs
• HUDLib supports hiding/showing HUDs without entirely removing them add having to redefine them manually
• HUDs can be registered that will be shown to all players
• HUDs can be removed from all players with one line of code
• All of the HUDs attached to a specific player can be retrieved, including specifics about each HUD (e.g. original definition table, visibility, etc...)
• Callbacks can be added to the HUD definition to be automatically called (e.g. on_step, on_hide, etc...) not unlike those supported within node definitions
• HUDs can be automatically hidden by defining hide_after in the HUD definition
• ...and more!

Features

• hudlib.after which uses a named queueing system replaces minetest.after
• HUDs are referenced by a name chosen by the modder
• Hiding/Showing HUDs without having to redefine the HUD
• Showing an HUD to all players
• Removing an HUD from all players
• Auto-hiding HUDs
• Callbacks in HUD definition
  • on_step
  • on_show
  • on_hide
• List all HUDs attached to a player
• Remove all HUDs attached to a player
• Statbar API
• Waypoint API
• Custom APIs for each element type
• Parent-Child Constraints (e.g. the child's position is made relative to the parent's)

Planned

• Auto-repositioning of HUDs to avoid overlap (?)
• API to register settings to manage HUDs via chatcommand or configuration file

API

For information on the API available for use by other mods (this is the API used by HUD Plus), see the documentation.

Download

Master (latest, often unstable)
Version 0.1 (latest, stable)
...or View all releases on GitHub

Note: HUDLib does not register any HUDs, but only provides an API. If you'd like to see how HUDLib can be used, see HUD Plus, the mod in which this API was originally developed.

Choose one of the downloads above and extract the ZIP. Though it is recommended, you are not required to rename the resulting directory to hudlib. If you are not sure what to choose, look for the first version labeled as "latest, stable."

As I already said in the other thread, I'm not excited about this mod. As a modder myself, I don't see the benefit from using this mod, so I won't use it.

hudlib.after which uses a named queueing system replaces minetest.after

HUDs are referenced by a name chosen by the modder

List all HUDs attached to a player

Remove all HUDs attached to a player

It's not that these are bad ideas. I'm also not at all against the greater goal behind this mod.
But I don't like the proliferation of mods which exist only for perceived missing features in Minetest. Just fix Minetest!

Your mod looks like it wants to be very, VERY generic because it touches one of the most basic features of the API. The thing with mods like this one is, even have a “better” API (whatever that means), it's still an additional dependency which you have to carry along.
But the bigger problem is that with mods like this modders have still to invest time in learning this additional API.
Suppose the official API is, in fact, trash. Let me make a thought experiment:
Average Modder Sam realizes this and find several API mods which claim to make life easier. But now what? Learning the official API is no longer enough, now Average Modder Sam also has to learn BlaLib and WhateverLib and FooLib2000 to be able to do Random Task X. But then it turns out FooLib2000 was trash, but Average Modder Sam first had to learn it before realizing it, which costs more time, etc. etc. etc. Ironically, this makes it more difficult, not easier to do Random Task X. This is always the fallacy of wrapper mods which attempt to make life easier.
You can't get around that, no matter how simple your API will be. I don't think many modders have the motivation to learn those additional APIs, especially when the net benefit is not obvious.

But I can totally understand if you say that Minetest's Lua API has holes. Have you talked to the core developers about this? PLEASE talk to the core developers, it is very important. Minetest's Lua API is far from finished and even less “polished” and they are aware of this. But they still need to know where exactly modders struggle. Improving the official API is the right way to go IMO. Complaining about things or giving feedback can also help, as long the developers know.
Writing wrapper APIs just leads to more and more fragmentation. I think our modding community already suffers enough from NIH and many incompatible mods which do basically the same thing.

When stacked up against other HUD libraries, HUDLib excels in that it supports all HUD elements and has an intuitive API allowing you to do more with less code (see features for more information). However, how does it stack up compared to the default Minetest HUD API?

I don't like this attitude. Minetest is not your enemy. xD

This is a nearly drop-in replacement for minetest.after, except it can be considered to be slightly more advanced. It uses global steps instead, which are also considered more reliable.

Yes, minetest.after is a very cruel function and a source of endless pain and bugs. I feel your pain.
But the solution to that is to fix this in the official API. Having a reliable timing system is very important, but I guess Minetest doesn't have one (yet). I strongly doubt that any Lua mod is actually able to make a more reliable AND precise (!) timing system than Minetest itself. Is there an issue on GitHub yet?

hudlib.parse_time(<time (string)>)
Parses a string containing sets separated by spaces, each containing any amount of numbers and one alpha-numeric character. You can have as many sets as you want, each one representing either a second, minute, or hour. If no alpha-numeric character follows a set or it is followed by s, it is intepreted as seconds. If m follows a set, it is intepreted as minutes, while h is intepreted as hours.

This function is very strange and its purpose seems very esoteric. What strange circumstances have led to the decision to include this function? Besides, using “m” for minutes is bad, it should have been “min” (SI unit).
But in any case this function seems very out of place.



Don't get me wrong: It's good that you want to help making the HUD easier to use. BUT I think it will be much more helpful for everyone if the official API gets fixed instead.

This sounds really interesting, but I think I agree with Wuzzy.

Of course it is beter to improve the base API. But the base API is mostly very generic to give the modders all possibilities he needs. In some cases it is legitim to get an additional abstraction layer API that allow easier implement specific tasks. The best sample is lua integration itself. Why we need this layer? We can develop mods directly in C/C++. Why we use irrlicht? We can use the Opengl-API directly ...

Therefore I see no reason to worry about a new layer in general. Of course the layer should have additional value. I did not looked in detail to hudlib because of no project at the time, but if it is something like smartfs for formspecs, I like it.

@octacian, Do not let you tell the mod is useless as long as you uses it self.

Wuzzy wrote:Writing wrapper APIs just leads to more and more fragmentation. I think our modding community already suffers enough from NIH and many incompatible mods which do basically the same thing.

I actually agree TBH. Especially when it comes to entities (though that's not at all meant as a comparison to justify this mod).

Wuzzy wrote:Don't get me wrong: It's good that you want to help making the HUD easier to use. BUT I think it will be much more helpful for everyone if the official API gets fixed instead.

Yes, I understand. Not quite sure why I didn't think of this originally. I personally don't like adding another dependency in either, so really not sure.

I think what I'll do though, is submit an issue to MT suggesting a new HUD API (one that'd be easier to use and more consistent). If it receives interest from devs and others, I'll give it a try (unless someone else does too). Otherwise, I'll continue adding the features that I find important to this mod. Either way, this mod has still been useful as a proof of how a better API could work and also helped me with figuring out the logic for things like a named queue.

In the end, this mod was meant as an improvement to BlockMen's betterhud mod. In fact, it originally began as a fork, then I decided to rewrite from scratch. The end goal is quite like BlockMen's mod, but with a slightly cleaner API (I hope lol) and support for non-statbar elements.

Wuzzy wrote:I don't like this attitude. Minetest is not your enemy. xD

Yeah yeah, IK, maybe I'll try to reword :rotfl:

Wuzzy wrote:This function is very strange and its purpose seems very esoteric. What strange circumstances have led to the decision to include this function? Besides, using “m” for minutes is bad, it should have been “min” (SI unit).
But in any case this function seems very out of place.

The purpose was to allow choosing the intervals of time for the do_every callback without having to rely only on seconds (though on second consideration, this might actually be better).

Wuzzy in HUD Plus thread wrote: I summarize: HUD Bars is bad because it doesn't do everything at once. This argument is not convincing.
Is there anything in HUD Bars which would prevent other HUD mods which concentrate on other parts of the HUD from doing their job?

Yeah, I worded that terribly. HUD Bars is not bad, I simply find it inconvenient because I personally rarely work on only statbar elements, but rather with all at once. With that in mind, a mod using partly HUD Bars and partly not could get confusing. In fact, I will likely still implement a simplistic statbar API in this mod which will support HUD Bars, and that code would be nearly directly copied from your mod. This is probably worded terribly too, but my point is that I don't think the mod in itself is bad, but for my application I don't like using different methods (even if just for naming) across related parts of the code.

So.. hopefully that all made sense. I will though submit an issue to GitHub suggesting a new API for all HUD elements which if it gets enough interest, I will attempt to implement.

So.. hopefully that all made sense. I will though submit an issue to GitHub suggesting a new API for all HUD elements which if it gets enough interest, I will attempt to implement.

Great, I'm checking this out.

In due time, will this lib also implement new HUD features?

Deleted

clean, polished and perfectly done, like always. (+ another nice BBcoded post, with a lil' header)