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

Individual Nametags configuration for each EntityType #4355

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

crazycat256
Copy link
Contributor

@crazycat256 crazycat256 commented Jan 25, 2024

Type of change

  • Bug fix
  • New feature

Description

Changes:

  • Allows configuring nametags differently for each EntityType.
  • Adds a "trough-walls" option.

This notably allows knowing the health of nearby mobs without having the screen filled with nametags.

Checklist:

  • My code follows the style guidelines of this project.
  • I have added comments to my code in more complex areas.
  • I have tested the code in both development and production environments.

@Theboiboi8
Copy link

What's the expected behavior for through-walls when it's disabled? The current approach has rather lackluster and unrefined results, and a different approach might be better.

@crazycat256
Copy link
Contributor Author

@Theboiboi8 The expected behavior when disabled is simply not to display nametags of entities that are not directly visible to the player.

What do you think could be improved?

@Theboiboi8
Copy link

Nametags don't render even when part of the entity is in view, so you can be looking at most of the entity and still not see any nametags. i.e.
image
In this example, nametags are enabled, through-walls is set to false, and I'm using a fake player (.fake-player) to have a non-moving entity. As observed, even though part (most) of the fake player is directly visible, the nametag doesn't appear.
image
In contrast, when the player moves ever so slightly to the right, as to view more of the fake player, the nametag appears, as observed in the above screenshot.

I feel as though this isn't the correct behavior, and I feel that when at least part of an entity is showing, nametags should, logically, appear, as otherwise issues like the one illustrated previously occur and hinder the player.

@crazycat256
Copy link
Contributor Author

This looks at the position of the player's eye. Indeed, player parts can appear without the nametag being displayed but that does not seem problematic to me.
The main objective of this PR is to allow the player to know the health of the entities around him without having a lot of nametags for the mobs in the caves.

@Theboiboi8
Copy link

Theboiboi8 commented Jan 25, 2024

The problem, I feel, with this approach, is that given the nametag is hidden if the player doesn't see the eyes of the entity, wouldn't that present an issue with mobs that the player is fighting, but not seeing the eyes of? If, for example, the player is fighting an enderman and hiding under a 2 block tall roof, wouldn't it be better to see the health of the enderman even though the eyes aren't in direct view?
As for mobs in caves, it would make little difference whether the visibility is based on whether the player sees the eyes of the entity or if the player sees part of the entity, regardless of eye visibility. On the contrary, the player may be facing a mob that is obscured partly by a block and trying to see the mob's health, but not succeeding in doing so as the mob's eyes arent in direct view.

@crazycat256
Copy link
Contributor Author

It would be quite complicated because it would mean raycasting all over the entity, which would rapidly reduce fps

@Theboiboi8
Copy link

replacing

((IVec3d) vec2).set(entity.getX(), entity.getY() + entity.getStandingEyeHeight(), entity.getZ());

with

((IVec3d) vec2).set(entity.getX() + entity.getWidth(), entity.getY() + entity.getStandingEyeHeight(), entity.getZ() + entity.getWidth());

in the isBehindWall(Entity entity) boolean seems to yield okay results without compromising on FPS (~5 FPS difference vs without this change, within normal FPS fluctuation range for MC on my machine). This solution isn't perfect, particularly when it comes to the Y-axis, but it does offer a simple and acceptable solution for the problem outlined in my initial comment.

@crazycat256
Copy link
Contributor Author

This modification just adds an unwanted offset to the eye position.
Place your fake-player to the left of your blocks to see this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants