For example, currently if you were to set two info views to share the same weight, they would sort themselves alphabetically. It would be nice if several info views could share a line, as it can be kinda cluttered having several small lines all on their own, especially with larger font sizes.

@maruohon Would you be interested in a PR that implements this functionality, or would it be just turned down? I have implemented a similar functionality for Wynntils (a specialized mod for the Wynncraft Minecraft MMRPG server), were we have a framework of functions that return some relevant data, and a simple but specialized language that allows you to call these functions, so you can do stuff like "Speed: {speed}". We also have simple math and logic, so you can do comparisons and conditions, etc.

I think it would be feasible to port this to MiniHUD, but it's no point in me even trying unless I know there is a chance that it will be accepted.

@magicus I won't pull any new features to the current 1.13+ branches of the mods, as those are "pre-rewrite old code" and are in minimal life support mode. Any new features will go to the main development code, which is the ornithe_1.12.2 branch of the mods. And this will then obviously also need a completely new config menu as well. And the new malilib code is vastly more flexible and has more basic widgets to do things, i.e. needing less new code than the old code version in the current 1.13+ branches.

But basically I have very similar plans for the info lines, with the {FOO} style placeholders/replacements, thus making all the info lines fully configurable. I still haven't figured out all the small details of how I want them to work, since I haven't started actively working on it yet. Mainly things like how to do color support based on conditions, so that things like the TPS/MSPT line could be with user configurable colors and thresholds.

Ok, thanks, that's good to know! Would you require/appreciate any assistance in getting the ornithe branch to production? Do you have any development discord?

Thanks, but mostly I've been working on any new features and code myself, as I enjoy designing and implementing stuff myself. Unfortunately in the past couple of years any progress on any mod stuff has crawled to a halt, as a combination of no time and/or energy left after work, spending a lot of time just on user support for the mods, and also being somewhat burnt out on modding and starting to do other stuff in my free time. So the client mods rewrite stuff has kinda stalled for the time being. I'm hoping I'll have some time (and motivation) to work on the mods during my summer holidays, but... I've also had that same hope for several past holidays and almost never ended up doing anything for the mods, so... 🤷

My Discord server is here: https://discord.gg/2FgywHj

It's mostly focused on user support and other generic stuff, but there are also a few development channels. Lately those dev channels have mostly been used for talking about the snapshot changes and porting to new MC versions, which has been done by various members of the community since like 1.18-ish. I've mostly lost interest in new MC versions and porting to new versions is not something I've found interesting in a long time now, so usually other people have PR'd in the ports to new MC versions lately.

I understand fully. I'll start lurking in the dev channels to see if I can pick up on anything I can help with. Thanks once again for providing The Mods, the truly essential set of mods.

Fully customizable info lines are planned. They are also partially implemented several months ago already, but I didn't finish that stuff yet and I've been mostly busy with countless other things since then so I haven't had the time to continue working on that yet.

The current idea for that is that the user can freely set the entire string for each info line, and you can use special placeholders which will get replaced by the actual value you are interested in, such as a coordinate, a light level, or whatever the particular info type/placeholder represents. I still need to decide how I want to handle possible predetermined value coloring in that system, or if I'll just keep it hard coded like it's now (such as the TPS and MSPT value coloring depending on how close to 50 ms/tick the value is).

That sounds like a great plan. Thanks for all the work you've done for this project.