[Mod] HUD Plus [hudplus]

[octacian]

HUD Plus [hudplus]

• Version 0.1, alpha
• Code: MIT (see LICENSE), Media: CC-BY-SA 3.0
• Dependencies: hudlib

Note: HUD Plus requires that you have minetest-dev with this commit or later.

HUD Plus uses HUDLib to create a more intuitive set of HUDs for players. This mod is currently small, but it has the potential to become huge considering the simplicity and expandability of the HUDLib API. The mod will soon include hunger, armor, and improved health statbars. See below for more information on current and planned features. If you don't want any of the features offered by this mod, you can disable them by disabling the respective module. For example, to prevent HUD Plus from displaying information about the tool you are holding, simply add tool_info = false on a new line in modules.conf.

Features

• Item description and itemstring is displayed when selected in hotbar
• Displays tool information in bottom-left when selected in hotbar
• Clock to display time

Planned

• Replace default Health Statbar
• Hunger Statbar
• Armor Statbar

Download

Master (latest, stable)
...or Browse the code on GitHub

IMPORTANT: HUD Plus depends on hudlib, so don't forget to download and install that as well.

This is a rolling release (there are no specific versions), so it is save to simply download the latest master copy. Though it is recommended, you are not required to rename the resulting directory to hudplus.

[azekill_DIABLO]

good! finnaly a great mod that i really needed alot!

[Wuzzy]

Item description and itemstring is displayed when selected in hotbar

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.
The use case is 100% legit and I'm surprised it hasn't been done before in a non-subgame standalone mod. That's good!

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.

I could maybe look into improving my HUD Bars mod so that you can query it for exacty offsets to use. I talk to you again when this functionality is ready.

Hunger Statbar
Armor Startbar
Sprinting (?)

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

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.

API

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.

[octacian]

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.

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.

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.

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.

[hajo]

HUD Plus [hudplus]
This mod aims to create a better player HUD ..
* Item description and itemstring is displayed when selected in hotbar

Nice idea, but I get an error:

Code: Select all

ERROR[Main]: ServerError: Runtime error from mod 'hudplus' in callback environment_Step(): ...0.4.15\bin\..\mods\hudplus/modules/item_info/general.lua:13: attempt to call method 'get_meta' (a nil value)

Also, please add the meta-files depends.txt
and description.txt, eg. with text like this:

Code: Select all

HUD Plus by octacian - v2017-03

Display item description and itemstring when selected in hotbar.
(more features planned)

Forum : https://forum.minetest.net/viewtopic.php?f=9&t=16864&p=257211#p257211
github: https://github.com/octacian/hudplus

And use a screenshot of size 3:2, so it doesn't get distorted.

About planned features:
I would like my HUD to display the ingame-time,
to avoid typing the command "/time" every few minutes.

On singleplayer, I'm already using a small mod to display the time
at the center above the hotbar, see screenshot here.

(Based on testclock by kaeza, I just changed
the position and color, and dropped the seconds)

[bell07]

IMO a mod should do ONE thing, but it should do it right.

+1!
Sometimes I forgot about this Unix base philosophy too

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.)

The sprint bar should be provided ("registered in hudplus") by the mod that implements the sprint. So the API should support something like

Code: Select all

hudplus.register_hud("sprint", { min = 0, max = 100, step = -1, start = 90, regeneration=1, colour="red"})

and

Code: Select all

hudplus.set_value("sprint", 5)

(or sprint:set_value(5) if you like OO)

But how the HUD is displayed on screen (position, size, presentation) should be implemented in the hudplus mod.
The globalstep should be implemented in HUD-mod only for all registered hud's and update all bars using the registered information.

[octacian]

The sprint bar should be provided ("registered in hudplus") by the mod that implements the sprint. So the API should support something like

Code: Select all

hudplus.register_hud("sprint", { min = 0, max = 100, step = -1, start = 90, regeneration=1, colour="red"})

and

Code: Select all

hudplus.set_value("sprint", 5)

(or sprint:set_value(5) if you like OO)

But how the HUD is displayed on screen (position, size, presentation) should be implemented in the hudplus mod.
The globalstep should be implemented in HUD-mod only for all registered hud's and update all bars using the registered information.

That sounds about like what I'm planning! OFC the sprint bar will be an entirely separate mod, simply depending on HUD Plus.

[octacian]

Code: Select all

ERROR[Main]: ServerError: Runtime error from mod 'hudplus' in callback environment_Step(): ...0.4.15\bin\..\mods\hudplus/modules/item_info/general.lua:13: attempt to call method 'get_meta' (a nil value)

I keep forgetting that I can't assume everybody runs a recent build of minetest-dev xD
Added a note to the OP.

Also, please add the meta-files depends.txt
and description.txt, [edit by octacian] and mod.conf. And use a screenshot of size 3:2, so it doesn't get distorted.

Thanks for reminding me, must have slipped my mind! Will do right away.
And yes, IK the screenshot should of a 3:2 ratio so it isn't distorted in MT, but I'm not too worried about that more so that it looks good on the forums. Maybe I'll replace the screenshot.png with a non-distorted image and just move the one used on the forums to a hidden file. On the other hand, I could submit a PR to MT so that images don't get distorted... We'll see how things go, but I'll do one or the other - the latter if it doesn't require changes to core formspecs.

About planned features:
I would like my HUD to display the ingame-time,
to avoid typing the command "/time" every few minutes.

Sounds like a great idea, adding to planned features. Before implementing too much more though, I think I ought to create an API allowing easy registration of per-HUD settings so as to enable, disable, and possibly change other features of an HUD per-player.

[bell07]

I would like my HUD to display the ingame-time,

Sounds like a great idea

Please keep in mind the orienteering mod viewtopic.php?t=15247 does integrate this feature to the gameplay, reachable by crafting and usage of the "clock" item. So take this feature optional or into an own mod. Maybe you can take a fork of the orienteering mod that uses your API.

[hajo]

screenshot of size 3:2, so it doesn't get distorted.

And yes, IK the screenshot should of a 3:2 ratio so it isn't distorted in MT,
but I'm not too worried about that more so that it looks good on the forums.
Maybe I'll replace the screenshot.png with a non-distorted image

Just cutting up that image, to only the central part, improves the appearance in the mods-tab:

[octacian]

Just cutting up that image, to only the central part, improves the appearance in the mods-tab

For now, I've moved the thinner image to a file called .gh-screenshot.png and used an image with a ratio of 3:2 in the screenshot.png.

[Byakuren]

Could you make this mod have just the API, and separate the actual stat bars into their own mods?

And what problems do you see with existing APIs like hudbars?

[octacian]

Could you make this mod have just the API, and separate the actual stat bars into their own mods?

I think I'll definitely split the API itself into another mod called hudlib as there will be some people who just want the API and not the other things. ATM, if you want to disable the other things you have to either delete the modules or set them all to false in modules.conf which is a bit inconvenient. But yes, I'll split this into two mods: hudlib (the library) and HUD Plus (this mod).

And what problems do you see with existing APIs like hudbars?

Well, I don't like either the feature set or the approach of the other existing APIs. Most of the existing APIs target only statbars, however, I plan to introduce APIs to target all of the different HUDs (including statbars and waypoints). Yes, IK, it can be better to have do one thing right in each mod, but in this case they go together. I will also support an HUD Bars type format as does the hudbars mod. Now, the real question is, what makes my API better than using the default API?

For one thing, my API keeps a list of all the HUDs attached to a player (assuming they've been registered using the API), referencing each by a name defined by the modder rather than a generated ID. My API allows showing and hiding an HUD without having to entirely redefine it after "removal." Not only that, but with one extra line of code you can register an HUD that is automatically applied to all players. HUDs also have callbacks, like on_step, on_show, on_hide, etc... (documented in API). I've also replaced minetest.after which is still heavily used by many mods with a custom queue based of globalstep in which each item is given a name. I'm also planning on implementing child-parent connections, where the child's position and other properties can be relative to the specified parent (useful for attaching an image to text). Though this will likely require an engine change to implement as I believe I'd need to be able to get the screen size, I also plan on implementing a feature where HUDs will automatically reposition themselves (unless disabled) if they overlap with another.

That's about it though. I'll be improving the API documentation soon, as though it is there it's a bit messy. I will split this into a second mod as well, and will outline the above reason as to why it's preferable to other mods in the README.

[octacian]

hajo: The clock HUD has been added. I'll soon work on some updates to HUDLib allowing HUD Plus to easily define settings changeable via a command which would allow you to configure the position of the clock and whether it not it is shown.

To All (Byakuren in particular though):
I've moved the library into it's own mod, HUDLib. Make sure that when you update HUD Plus, update HUDLib (and vice-versa). HUD Plus is no longer versioned but is a rolling release for simplicity's sake.

Both the library and this mod have been progressing quickly as of late, and this mod will soon receive statbars to replace and improve default ones. I am no longer planning on implementing waypoints as a part of this mod; they belong in their own mod.

[Wuzzy]

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?

Apart from HUD Bars: You also said you feel unhappy with the Minetest API. Then why not just improving the official API, then? Making Minetest mods with the express purpose to work around limitations of the API, or just making a “wrapper mod” is never a good idea in the long run. It might be a short-term solution, but your mod is doomed to become obsolete as soon Minetest's API implements the features you were missing. I think time would be better spent to try to work out a solution with the Minetest developers right from the start. Celeron55 himself urged all modders to give feedback about the modding API. Have you at least filed some feature requests on GitHub? Or posted something in the Feature Requests forum? It's not like Minetest's modding API is set in stone.
Also, improving the official API has the huge benefit that it will actually be used and becomes automatically the standard.

I doubt your API in this mod will find a lot of acceptance from the modding community. I will almost certainly not use it because I see it as redundant.

Frankly, I have the impression that this mod is going to be a perfect example of the Not Invented Here syndrome.

[hajo]

Code: Select all

ERROR[Main]: ServerError: Runtime error from mod 'hudplus' in callback environment_Step(): ... method 'get_meta'

I keep forgetting that I can't assume everybody runs a recent build of minetest-dev

With minetest-dev as a requirement, using&testing is pretty much restricted
to singleplayer, and developers.
Nobody would roll out such a mod on a live server.

Don't forget that many users connect to MT with mobile devices.

[Milan*]

Nobody would roll out such a mod on a live server.

This isn't true, also some "release mods" sometimes get features only git clients can handle.
This also matches to servers on git state - and there are alot.
I wrote originally a bit more to this topic but this forum redirected me to the login page and i am not in the mood to write everything again.