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

Remove left panel EHP, saner Vaal/Guard skill defaults, better disabled gem readability #8340

Open
wants to merge 2 commits into
base: dev
Choose a base branch
from

Conversation

Subtractem
Copy link
Contributor

@Subtractem Subtractem commented Oct 17, 2024

EHP being so prominent in the left panel has been the source of much misinterpretation of the sturdiness of builds in PoE. While it can be a useful number to veterans, it is deceptive to folks that don't know exactly how it works. With the support of many prominent build makers, I'm hoping to remove it from the left panel display here. The number is much more useful with more clarity when taken with the context of the Calcs page.

This is configurable in the options panel for those who want to turn it back on.
CyYZTQs

Over the past couple years certain standards have arisen within the build community for what is a sane state to consider and share builds from. Chief among these is Vaal and Guard skills (both Vaal and non-Vaal) being disabled. I've made it so that this is the default upon character import. The non-Vaal version of that skill will now be enabled. This is very useful when reimporting a character multiple times so you are generally looking at the state you want the build to be configured in by default.

In addition, I've added a (Disabled) tag for the auto-generated skill labels so it's more clear what is turned on/off in a socket group at a glance.

An image of skills in a fresh import:
PZj9jTZ

@JustinStitt
Copy link
Contributor

JustinStitt commented Oct 21, 2024

I agree with the idea of disabling vaal/guard skills by default, so +1 to that.

But I don't quite like moving longstanding UI elements to different pages, intentional obfuscation of a commonly observed stat might not be the best UX choice.

edit: is there a better way to educate users about this stat's true meaning?

@Subtractem
Copy link
Contributor Author

But I don't quite like moving longstanding UI elements to different pages, intentional obfuscation of a commonly observed stat might not be the best UX choice.

Well, to be honest, the primary intention here is to remove it from prominence as it's more often harmful than helpful. This approach was proposed as a consensus from a plurality of the largest build creators. This more of a biased change proposal than QoL.

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.

2 participants