Wuzzy wrote:I think this feature alone is worth a mod on its own, no need to add 1000 other features on top. IMO a mod should do ONE thing, but it should do it right.
My first suggestion is to make sure this mod is more or less compatible with other HUD mods to make sure the displayed item name is always placed correctly and never overlaps with something.
Yes, it's true that you don't need to make a mod with a bunch of other features on top, but the point of this mod is to in the end provide a good API for registering and managing HUD elements, but more on that later. I think I might release another mod with that specific feature relying only on the default API.
I've considered keeping compatibility with other HUD mods, however, I hope to be able to replace these HUD mods (no offense :P) as there are areas I see in most of them that need to be improved, but in ways where it's better for me to just create my own mod.
Wuzzy wrote:Oh god, please not another mod which conflates gameplay with HUD. This is a bad idea because it creates a strong coupling and leads directly into dependency hell. :-( We already had a mod which did the exact same mistake.
Besides, have you never heard of the
HUD Bars [hudbars] mod? This mod together with [hbarmor], [hbhunger] and [sprint] already does all of this. I'm excited to hear your plan on how you are going to crush the competition. :D
Yes, I've changed my mind about doing a sprint bar: not a chance! (Though I might provide it in a separate mod for those who must have it.) I honestly hate the concept, thought I thought about doing it in this mod for the reason I just stated. I had not previously heard of hudbars, and it sounds pretty nice, but my goals extend past HUD bars to making managing HUDs themselves far easier.
Wuzzy wrote:Tool Status
I don't understand what you mean. Maybe damage percentage because you think the “progress bar” is not good enough? I don't see the need, but it's probably OK.
I mean displaying in the corner the exact number of uses compared to the total number of uses and possibly other bits of tool capability-related information.
Wuzzy wrote:I don't get it. I have briefly looked at API.md but it mostly just looks like a very thin wrapper around Minetest's HUD functions. What's the point? I would be better off when I just use the Minetest API.
Yes, that's true. It is essentially a thin wrapper from the MT API, but that's only for now. The reason why I'm writing a custom API, is because I prefer a system of referring to HUD elements by name rather than by ID, and to have the ability to get a list of all the HUDs on a player followed by performing some action on them. I also plan to automatically handle that of moving an HUD if there is already an HUD in the position where you want to add it (though I could only do this if both HUDs were registered using this mod, as I can't get a list of other HUDs to my knowledge).
One fairly useful thing that's already implemented, is the ability to show/hide HUDs without actually having to redefine them each time. Aside from that, I have and will implement several callback functions on HUDs allowing easier implementation of things like globalstep or adding the HUD to all players. Overall though, the reason this mod provides an API is in an attempt to make creating HUDs a more simple process and allow for mods to make better use of the HUDs themselves.
