Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show wielded item name above hotbar #8175

Closed
Wuzzy2 opened this issue Feb 4, 2019 · 10 comments
Closed

Show wielded item name above hotbar #8175

Wuzzy2 opened this issue Feb 4, 2019 · 10 comments
Labels
@ Client / Audiovisuals Concept approved Approved by a core dev: PRs welcomed! Feature request Issues that request the addition or enhancement of a feature Low priority Possible close

Comments

@Wuzzy2
Copy link
Contributor

Wuzzy2 commented Feb 4, 2019

Issue type
  • Feature request
Minetest version

0.4.17.1

Summary

Basically, do what the show_wielded_item mod (https://repo.or.cz/minetest_show_wielded_item.git) does, but available by default.

Details

I request to display the name of the wielded item (description) above the hotbar.
When you select a new item, the item name should show up for about 5 seconds.
If no item is selected, nothing should be displayed.
The display shall have (mostly) the same display rules as for item tooltips.
If the description has any newlines, only the first line shall be printed.

The fact that later lines will be dropped should be written down in the docs, just to be sure.

This display should also be toggable by a player HUD flag, similar to how modders can disable the builtin health bar or hotbar.

Justification

It's more convenient to see the item name immediately than having to press I.

This is an improvement that almost all games can benefit from, so this should not be limited to Minetest Game. Only in exceptional cases a game would not want to use this feature, therefore it should be enabled by default. But even those exceptional cases are covered thanks to the HUD flag, that can be disabled.

About dropping lines: Lines beyond the first line need to be dropped to avoid visual clutter. Also, it would probably become too much text otherwise.
Dropping lines should be relatively safe. It's already very common for infos beyond the first line to be of less importance or contain “bonus infos”.

@Wuzzy2
Copy link
Contributor Author

Wuzzy2 commented Feb 4, 2019

I am not sure whether color codes should be kept or stripped.
Pro: Consistency with tooltip. Looks nice maybe.
Contra: Might be hard to read against certain backgrounds (needs to be tested to be sure).

@rubenwardy
Copy link
Member

I'd strip the colour codes, and only read the first line

@paramat paramat added Feature request Issues that request the addition or enhancement of a feature @ Client / Audiovisuals labels Feb 4, 2019
@SmallJoker
Copy link
Member

I like the idea. A client-side implementation for this HUD-element would be the best solution to avoid lag issues which occur quite easily with SSMs.

@Warr1024
Copy link
Contributor

NodeCore does this as an SSM. No significant lag issues have been noted.

NodeCore also does support multiline, which is important for showing the contents of container objects. It also uses callbacks to define the description for things it displays, which can include more-or-less arbitrary customizations to the text that's shown. These things probably can't be done client-side, so if this feature is added to the engine, NodeCore would be forced to disable it anyway.

It seems like, to do this client-side, you'd at least need some way to allow the server to send the metadata for items to the client pre-emptively so it's available at the time it's displayed. If there are mods out there that clutter the description meta field with a wall of text, then you might want to at least add a separate hotbar_description meta field that can override it specifically for use in the hotbar tip.

@benrob0329
Copy link
Member

This seems fairly easy to do in Lua, and not every game would want it. I'd much rather see development effort go towards more general callbacks and APIs (such as Status Text and on_wield_change functionality) rather than specific features games can easily implement, especially given a couple generic API additions that are useful in other contexts.

@paramat
Copy link
Contributor

paramat commented Dec 31, 2019

👎 It is almost always known, or obvious, what is being wielded. After all, you end up staring at it. I cannot remember the last time i did not know what i was wielding.
In the rare cases it is not, the player can check in inventory. This would add unjustified code and visual clutter.

I do not understand why core devs are supporting something so unjustified. Please explain why this is necessary, the justification in the first post makes no sense, see my argument above for why.
This is easily done by a mod and should be.

With the core dev time we have MT is already borderline unmaintainable, it certainly will be if we make a habit of adding frivolous conveniences. See the roadmaps and please remember simplicity.

@paramat paramat added Concept approved Approved by a core dev: PRs welcomed! Low priority labels Dec 31, 2019
@rubenwardy
Copy link
Member

I support this from a game design point of view, but think this should be done in Lua

@Wuzzy2
Copy link
Contributor Author

Wuzzy2 commented Dec 31, 2019

It is almost always known, or obvious, what is being wielded. After all, you end up staring at it. I cannot remember the last time i did not know what i was wielding.

What about items with custom names (description set in meta)? Try to think a bit beyond Minetest Game. Also: You are not the user.

In the rare cases it is not, the player can check in inventory.

True. But that's less convenient. This is the main point of this issue. Showing it directly in UI is more convenient. Please do understand this.

This would add unjustified code and visual clutter.

Visual clutter? Oh, come on! Now you're just exaggerating here.

This is easily done by a mod and should be.

Yes, it can be done by mods, but no, it shouldn't be done like that.

You forget that mods need a roundtrip for this to work, so this adds a delay. My issue suggests a client-side change in the engine, which has (basically) no delay. It's always bad and annoying when the GUI has delays. If you ever used an user interface that is even slightly laggy, you will instantly understand, because it will annoy you to no end.

Also: A mod implementation doesn't really make sense as it basically will boil down to always the exact same code anyway.

With the core dev time we have MT is already borderline unmaintainable

The supposed “lack of core dev time” you like to claim so often is not grounds to shut down this discussion. You are also ignoring that there are many contributors to Minetest and over hundred PRs. Maybe one of them is interested in this.

, it certainly will be if we make a habit of adding frivolous conveniences. See the roadmaps and please remember simplicity.

If even such a rather simple and small change is resisted so hard by you, then I assume that you will disapprove of anything usability or GUI-related that is even mildly more complex than that. By that logic, you have to be ragingly opposed to, like, formspec rework because its even more complex.

You seem to be outright hostile to anything usability-related, that I find it hard to take you serious on these things.

Please explain why this is necessary, the justification in the first post makes no sense, see my argument above for why.

Well, it's not strictly neccessary, but it's a small usability improvement. But that doesn't make it a bad idea.

And well, I said the reason. It's more convenient than having to press I. Seeing your item instantly is faster than forcing you to press a key and move the key first. Why does this not make sense? This can be very useful if you're new in a game, especially if said game has thausands of items, and/or the game makes extensive use of custom item meta description. Just think outside the Minetest Game box. :-)

, and not every game would want it.

That's why I suggested to add a HUD flag for it, so games can disable it.

I'd much rather see development effort go towards more general callbacks and APIs (such as Status Text and on_wield_change functionality) rather than specific features games can easily implement, especially given a couple generic API additions that are useful in other contexts.

This sounds much more complex and overkill just for displaying the item name.

@Warr1024
Copy link
Contributor

Warr1024 commented Jan 1, 2020

I use the server-side implementation in NodeCore, and it's actually a core gameplay element, since without an inventory screen, it's actually the only way players have to learn the names of things.

I also run a multiplayer server, as does another member of the NodeCore community, and among the things that people complain about, delayed HUD tips doesn't even rank. I've also tested gameplay under simulated high latency conditions (https://gist.github.com/Warr1024/a93e5ade411d674ed0a51a73f7f5eaed) and as network latency increases, enough aspects of the experience degrade that I hardly notice the delayed HUD tips.

If you want this feature, I'd recommend that you give the server-side implementation a serious chance first. If it really doesn't work, then you can have some empirical data proving that. If it does work, then it could be distributed as a mod that could become a de-facto standard, or could even be considered for inclusion in builtin, which could be done with a lot smaller, more isolated changes than doing it in C++.

@Zughy
Copy link
Member

Zughy commented Aug 13, 2022

Considering that Paramat is gone and #8175 (comment), possible close? I personally agree with the Lua implementation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@ Client / Audiovisuals Concept approved Approved by a core dev: PRs welcomed! Feature request Issues that request the addition or enhancement of a feature Low priority Possible close
Projects
None yet
Development

No branches or pull requests

7 participants