UnitThreatSituation()

https://wowpedia.fandom.com/wiki/API_UnitThreatSituation

That’s a hot mess.

It was apparently cribbed mostly from a copyrighted work that itself is a hot mess.

The table on that page has two unexplained columns in it, one labeled “Aggro” and the other labeled “Tanking” - the latter being a role, the former being - I don’t know what.

The explanation of the scope of the function seems to be saying that only ‘player’ is a valid “unit” parm (from the “explanation” that pet aggro isn’t counted if the player isn’t aggro’d by the “mobunit” as well).

If that’s true, then wouldn’t the “unit” parm be limited to only ‘player’? If it’s not true, then what’s the deal with pet’s not showing aggro as described in second sentence of the explanatory text?

The X and checkmark indicators in the table are unclear - not that I can’t read them - but in that there’s utterly no explanation as to what they MEAN. They’re just there.

I really could use a good explanation of what the return values of this MEAN (I know it returns nil, 0, 1, 2, and 3).

If it means something different for a Tanking toon than a non-Tanking toon, I need that as well.

Anyone who can chime in on this, please do.

I’m working on another ADA extension for ElvUI and I’m stuck on how to interpret the data coming back from this function.

Mobs keep track of ‘threat’ as a number for everyone they’re in combat with. Generally, they target the first person added to the threat list and will switch targets if someone else’s threat exceeds the current target’s threat by a percentage (10% or 30% depending on distance).

“Tanking” means this unit is the mob’s primary target
“Aggro” means this unit’s threat is >= the primary target’s threat

I think there might be some confusion here between the unitid ‘player’ and player characters as opposed to non-player characters.
I’m not familiar with the corner cases around this function but my intuition is:

  • unitids other than ‘player’ are valid
  • results may be meaningless if the first argument refers to a non-player character

I understand the idea of the threat number.

I’m saying the web page explaining it is a hot mess.

Only two of the five threat states in that table, for instance. Either put them all in there or take the table out. (the five states are: “not on threat table,” “low threat,” “above low threat,” “high threat,” and “primary target”). The phrase “primary target” is misused in a few clones of this table on related pages (there is only ONE primary target but in at least one instance of this table on a related page that description is used in for two threat states).

I don’t know if the problem is that the editors of that page don’t use English as a primary language or if they’re products of the American public school system and don’t know how to use the one language they purport to have mastery of. :slight_smile:

Unfortunately, threat information didn’t exist earlier in WoW’s history. If it had been in Vanilla or BC, there might have been developer remarks saved at blue.cardplace.com.

Being introduced when it was (3.0?), the pages in question were written starting in 2008 and were likely the product of trial and error by ordinary users who wanted to share what they learned.

I believe the other reference, wowprog, also benefited from user submissions circa the same time period (based on its copyright and license info). So its hard to conclude which came first. I suspect both at times contained information written first in the other.

As a wiki, such volunteer contributors are welcome from everywhere. I’ve interacted with several from diverse backgrounds, and their English appears just fine.

One thing that is required, though, is for contributors to be polite and civil when collaborating with other volunteers to make the wiki a better place. It would be nice if you also afforded the same courtesy from the UI forums as well.

2 Likes

I’d buy that whole “respect the contributors” thing if I hadn’t had experience on the wiki with one of your senior contributors systematically reverting every grammar correction I made for three months back when I was actively trying to help. I’d give you the name (he’s still active there) but I think the “name and shame” rule applies regardless of who and where you’re doing it. Contact me either through the wiki message board (my personal one) or in-game at Kaldara#11970 if you want it for verification and validation (there was disciplinary action taken against him eventually - and an apology from someone in authority in the old organization).

Apparently he took offense to my correcting one of HIS entries and decided to punish me by reverting everything I’d done.

So “civil” is fine if it works both ways. When it doesn’t, then the side that started it doesn’t really get to complain when it’s turned back on them.

And I was seriously concerned about the level of language mastery of contributors to that site. There are some very, very dodgy things going on with regards to clarity and grammar.

Again, I’m done attempting to correct them myself. I don’t need that level of abuse from anyone. The fact that I spent 30-odd years in IT, much of it in a Technical Writer role makes me well-qualified to question the quality of the writing there.

This is incorrect. There is a reason it’s laid out in a table.

But as I am a “product of the American public school system” I’m feeling insulted and have no interest in explaining it to you.

The five return values are nil, 0, 1, 2, and 3. I can count to five just fine.

What those mean is precisely what I’m trying to find out.

Part of knowing is knowing what you don’t know and in this case I know what I don’t know.

The table only covers TWO of the FOUR color changing states and only from the perspective of tanking.

I used the “talk” page there to explain what was wrong with it. If I understood the meanings well enough I’d have provide a suggestion on how to fix it.

Clearly the table on that page is missing SOMETHING as there is at least one row where the “situation” they’re claiming the X and checkmark “explain” are both showing that that situation doesn’t apply (so what situation DOES apply?).

Are you talking about this?

Used in the source code here:
https://www.townlong-yak.com/framexml/live/UnitFrame.lua#935


I don’t really understand what you are asking for. Have you encountered more than the four values that are known and documented on that page?

Stop. Being respectful to people today shouldn’t be conditional on what someone else did two years ago.

@Dahk, my question on that page the other day was responded to with INACCURATE mansplaining and a statement based on that that the suggestion I made to complete the table was without merit.

That was neither respectful nor two years ago.

There are five return possibilities from that function, although one of them is “nil”.

But “nil” in this case has meaning other than “unknown” in that “nil” means “not on the threat table for that unit”.

Four of them are integral, one is not. Five return values.

Based on the source code (using the link already provided), GetThreatStatusColor() appears intended only for use with three return values: 1, 2 and 3.

I just simply went online and played around. It seems the function accepts any argument (number, nil, string, table, etc.) and does two things:

  • If it is a number with decimal portion, use its floor()
  • Return one of the following five colours
        1 -> 1.00, 1.00, 0.47     yellow
        2 -> 1.00, 0.60, 0.00     orange
        3 -> 1.00, 0.00, 0.00     red
       -1 -> 1.00, 1.00, 1.00     white
      0/0 -> 1.00, 1.00, 1.00     white  (same as -1)
otherwise -> 0.69, 0.69, 0.69     grey

To be clear, ‘otherwise’ includes 0, -2, +4, and anything that isn’t a number.

I already wrote the addon I was working on (ElvUI_Black_and_White) and followed much the same path to enlightenment you did - gives me some hope that I got it right because I respect your knowledge of the system.

From a practical standpoint (and from digging around a bit in how other addons interpret the data out of UnitThreatSituation(‘player’, ‘target’)):

nil --> Player is not on Target's threat table at all.
  0 --> Player is not Target's Primary Threat and does not threaten to become so.
  1 --> Player is not Target's Primary Threat but threatens to become so.
  2 --> Player is Target's Primary Threat but another unit threatens that position.
  3 --> Player is Target's Primary Threat and is secure in that position.

Additionally color change is also affected by tapped status. The interaction of the two is complex and part of why I wrote the addon in the first place.

Edited to consolidate the tabular data:

Self : Pet  : Threat String  : Tapped Threat String
-----+------+----------------+----------------------
 nil : none : <empty string> :      < <    > >
 nil :  nil : <empty string> :      < <    > >
 nil :    1 : S:(  ) P:(-+)  : < < S:(  ) P:(-+) > >
 nil :    2 : S:(  ) P:(+-)  : < < S:(  ) P:(+-) > >
 nil :    3 : S:(  ) P:(++)  : < < S:(  ) P:(++) > >
-----+------+----------------+----------------------
   0 : none :      --        :      < < -- > >
   0 :    0 : S:(--) P:(--)  : < < S:(--) P:(--) > >
   0 :    1 : S:(--) P:(-+)  : < < S:(--) P:(-+) > >
   0 :    2 : S:(--) P:(+-)  : < < S:(--) P:(+-) > >
   0 :    3 : S:(--) P:(++)  : < < S:(--) P:(++) > >
-----+------+----------------+----------------------
   1 : none :      -+        :      < < -+ > >
   1 :    0 : S:(-+) P:(--)  : < < S:(-+) P:(--) > >
   1 :    1 : S:(-+) P:(-+)  : < < S:(-+) P:(-+) > >
   1 :    2 : S:(-+) P:(+-)  : < < S:(-+) P:(+-) > >
   1 :    3 : S:(-+) P:(++)  : < < S:(-+) P:(++) > >
-----+------+----------------+----------------------
   2 : none :      +-        :      < < +- > >
   2 :    0 : S:(+-) P:(--)  : < < S:(+-) P:(--) > >
   2 :    1 : S:(+-) P:(-+)  : < < S:(+-) P:(-+) > >
   2 :    2 : S:(+-) P:(+-)  : < < S:(+-) P:(+-) > >
   2 :    3 : S:(+-) P:(++)  : < < S:(+-) P:(++) > >
-----+------+----------------+----------------------
   3 : none :      ++        :      < < ++ > >
   3 :    0 : S:(++) P:(--)  : < < S:(++) P:(--) > >
   3 :    1 : S:(++) P:(-+)  : < < S:(++) P:(-+) > >
   3 :    2 : S:(++) P:(+-)  : < < S:(++) P:(+-) > >
   3 :    3 : S:(++) P:(++)  : < < S:(++) P:(++) > >
-----+------+----------------+----------------------