KuiNameplates

KuiNameplates

11M Downloads

add options to use name-only on players, enemies in combat with the player

AterNoxis opened this issue · 6 comments

commented

After update to 2.18 “name-only” mode do not work as it worked before.
Now I always see health bar on tracked NPC when it in combat not with me (I don’t hit it nor agro it).
Before 2.18 update I can see health bar on tracked NPC only in combat with me.

I tried all possible combination on “name-only” setting page.
I have Russian localization if its mater.

commented

Also now enemy players «name-only» mode obeys the same rules as enemy NPC.
But I used to behavior wen enemy players always was with health bar, despite «name-only» mode for enemy NPC.

commented

I tested 2.18-6-g1ac1bc9-alpha and I managed to set it as in 2.17.5.
But something feels not quite right…

  1. I can see name-only (on hostile NPC in combat not with me) only when marked both option «nameonly_damaged_enemies (Damaged enemies)» and «nameonly_combat_hostile (Enemies in combat)». «nameonly_damaged_enemies (Damaged enemies)» by itself do nothing.

  2. What is this option for? «nameonly_all_enemies (Attackable)». It seems like it just integral part of «nameonly_enemies (Hostile enemies)».

  3. «nameonly_neutral Neutral enemies)» become inactive when «nameonly_enemies (Hostile enemies)» marked. But it didn’t act as inactive, nor should it.
    «nameonly_neutral (Neutral NPC)» should have same set of rules as «nameonly_enemies (Hostile enemies)», or just be part of it.

  4. And now, can I suggest a new layout for name-only setting page? Because current state of it is far from «simplify name-only config page» )))

wowscrnshot_100518_140521

commented
  1. By itself, nameonly_damaged_enemies allows name-only to show on damaged enemies, as the name implies. Unless I broke it.

  2. some enemies are unattackable. They've always been shown in name-only mode by default.

  3. nameonly_neutral is implicit if you have nameonly_all_enemies enabled. That should be in the tooltip. It otherwise does follow the same rules.

  4. I assume you've made some modification to the locale file, because that's not what it should look like. And I can't really design the UI around the idea that people will modify the locale and make all the titles too long.

commented

I do not modify anything. It’s just Photoshop for better understanding meaning of options (because Russian translation in a bad condition). And to make it easier to explain =)

  1. So, do I understand correctly? :
    nameonly_damaged_enemies – shows name-only on enemy, which have not full health.
    nameonly_combat_hostile – shows name-only on enemy, which are in combat with you.
    So currently with nameonly_damaged_enemies marked, I still see health bar on damaged enemies, which are in combat NOT with me. Is this correct behavior? And this options work only for some exception when enemies have not full health but not in combat?
  2. Unattackable enemies? Hm, ok. I think this is an exception that I have not encountered. Becouse I use auto show nameplates only in combat and on important or quest NPC.
  3. «nameonly_neutral is implicit if you have nameonly_all_enemies enabled» but not in current version.
    Now if I unmark nameonly_neutral, and then mark nameonly_all_enemies – I will see health bar on neutral, and name-only on hostile.
commented

Oh! Sorry, I was on mobile and.. somehow completely missed the difference in font. The locale should be falling back to english where a translation doesn't exist, .. I guess I broke that. #346

  1. If nameonly_damaged_enemies is not checked, name-only mode shouldn't enable on enemies which aren't at maximum health. There's no other obscure logic there.
    If nameonly_combat_hostile is not checked, name-only mode shouldn't enable on enemies which are in any combat, regardless of whether or not you are involved.
    All of the options match the above pattern; unchecking an option disables name-only mode on the units it refers to, This should be made clearer by the locale, but of course, it's broken.
  2. Yup, there aren't many in BFA, but it used to be significant enough that I included them by default.
  3. I'm not entirely sure why they imply each-other, I think there was a reason, but maybe it was just something I copied over from old logic. I'll look at that when I get the chance.
commented

Pretty sure this is OK other than the delay, covered here: #348