Thursday, April 19, 2012

Uniquely Identified Units

Note:

This is a partial continuation from This thread, which discusses several algorithms for associating gained experience with the mob(s) who gave the XP.

Question:

How would one go about disambiguating one mob from another? Let's think about the properties of a unit for a second...

  • First and foremost, each unit has a name. This name is only partial unique, yet narrows a mob down to a much smaller array of local units. Names are often based upon the type and general location of a unit, thus playing an important role of uniquely identifying it.

  • Second, each unit has a level. It is unlikely that this changes often, if ever.

  • Third, each unit has a maximum amount of hitpoints and mana. Can these change in WoW? Most games don't allow for such changes (for monsters, of course).

  • Fourth, each unit in WoW has a set of predefined statistical attributes (Strength, Agility, Stamina, Intellect and Spirit). These attributes are split into four categories: Base, Stat, Positive Buffs and Negative Buffs. As far as i'm aware, the base stats of a unit do not change during combat, whereas other stats can be affected via items/armor and buffs/debuffs.

  • Fifth, each unit has a base and armor defense. Again, AFAIK, base stats do not change during combat. The armor may be reduced with a debuff, or perhaps continuous damage.

  • Finally, some units have a rank which classifies whether or not this mob is either "normal", "elite", "rare", "rareelite" or "worldboss". This does not change.



So what exactly can we accumulate from all of this information?

So far, the best i've come up with is a structured table as follows:


Code:
-- Creates a unique unit table based upon the passed UnitID
CreateUniqueUnit(UnitID)
return {
["Name"] = UnitName(UnitID),
["Level"] = UnitLevel(UnitID),
["HPMax"] = UnitHealthMax(UnitID),
["MPMax"] = UnitManaMax(UnitID),
["Stats"] = {
["Strength"] = UnitStat(UnitID, 1),
["Agility"] = UnitStat(UnitID, 2),
["Stamina"] = UnitStat(UnitID, 3),
["Intellect"] = UnitStat(UnitID, 4),
["Spirit"] = UnitStat(UnitID, 5),
}
["Defense"] = UnitDefense(UnitID),
["Rank"] = UnitClassification(UnitID),
}
end

What else can further identify a unit? Any replies are very much appreciated.

Thanks in advance,

- MikeTV|||UnitHealthMax will only give you percentage for mobs, so it will always be just 100. AFAIR, most other listed functions are too applicable only to friendly units you can inspect or even only to "player" and "pet" units and will give you either stable or gibberish values otherwise. So, no, you can't use most of those for any kind of UIDs.|||Basically your best bet right now is just to wait for 2.4 when we get unique mob identifiers and a complete combat log overhaul.|||Actually, I'm not sure disambiguation is the biggest issue, at least not in the same way that you do, although I may be missing something.

I'll paraphrase something I mentioned in the other thread ;)


Quote:






.

.

I guess if 2 of the mobs have the same name & level, then you can assume that they will give the same xp, and it doesn't really matter which you remove from your buffer...

.

.

.

Unfortunately ..... I don't think you'll be able to get the Level for the Mob that was damaged[killed]...[from the Combat Log]

.

.





Assuming that at a given Player Level, you will get the same XP from Mobs of the same name and level themselves, then do you need to disambiguate them further?

(As an after thought, you could include Zone name / Heroic Raid information as part of the key, as mobs might give different xp based on these inputs....(?) )

I'm just wondering how you are going to determine the Level of Mobs that die in general, or determine any of their other details to help with disambiguation at their time of death.

As far as I can tell, you will only be able to tell the level of those that you have currently targetted when they die.

Otherwise you are limited to the combat log yes?

Which can't provide any of the keying details you mention above apart from the Mob name?

Sorry for being so pessimistic ;'( and I hope you see a way around this.

(Just an afterthought, but you'll need to take in to account the characters "rested" state where they gain double xp, and what happens when they leave this state...)



Edit: lol, I wasn't aware 2.4 was going to add the features that Tunga mentions. Although even then you may have trouble unless the unique identifier is going to be passed as an argument in combat log ( / chat log) messages...fingers crossed :)|||Basically in 2.4 combat events are being replaced with a set of neat bit coded events, it's brilliant and efficient and can be interpreted into events as you like (and the client's combat log will just be interpreting this data in the same way that a mod can). This redesign includes unique unit IDs and a few oter things that will make things such as damage and threat tracking a lot easier for mods to do.

See here: http://forums.worldofwarcraft.com/th...68233433&sid=1|||@Rowaa:

Yeah, I think you're right. I already knew there were functions that WoW gets a little funky about with UIDs other than yourself/pet, but not everything appears to be documented as of yet. For example, I've noticed a few mobs returning 0 for all base stats, despite the lack of wowwiki mentioning it to be so =/


Quote:








Basically your best bet right now is just to wait for 2.4 when we get unique mob identifiers and a complete combat log overhaul.




Thanks! I agree, I could truely use such an update. Unfortunately, the closest thing to a release date for 2.4.0 is a rumor that "it will be this year"... Which is regrettably harsh for most people to deal with. Besides, if I could find a way to include backwards-compatibility (at least to a small degree of functionality), it's likely to get more attention. Not to mention, it's good coding practice while I wait for the 2.4 patch


Quote:








Assuming that at a given Player Level, you will get the same XP from Mobs of the same name and level themselves, then do you need to disambiguate them further?




Now who can deny how nice it would be to provide a full scale, spider-querying, self-adjusting, in-game implementation of a "Who, what, where, why and how?" for any given unit in WoW?... which, sadly, is not possible without further disambiguation. But with it, one example feature that could be independantly used is the ability to see exactly where the best XP zones are for your level, the names of mobs in that area, what they drop and so forth -- all which could adjust on it's own while you and others play.


Quote:








As an after thought, you could include Zone name / Heroic Raid information as part of the key, as mobs might give different xp based on these inputs....(?)




This information was already included within the table. But for simplicity's sake, it has been left out for now.


Quote:








I'm just wondering how you are going to determine the Level of Mobs that die in general, or determine any of their other details to help with disambiguation at their time of death




This is where my unit buffer class comes in handy. It's nearly able to record any and all specifics of virtually any size mob with a simple wave of the mouse. This information is parsed and queried before combat, and after a combat log event. And if a matching dead unit was found within range, educated guesses will be made, and possibly an option to correct any mistaken guesses could be implemented. Of course, if the mentioned units had something to uniquely identify them (such as a name:level:basestats string), no guessing would be necessary...


Quote:








Otherwise you are limited to the combat log yes?

Which can't provide any of the keying details you mention above apart from the Mob name?




No. The combat log will only provide two essential pieces of information... What died, and who may have killed it. Thus, until the 2.4 patch, the combat log will simply be used as an event trigger to search the buffer for related deaths in order to associate the link between a buffered mob and a dead mob. I'd explain this process further if this post weren't so friggin' gargantuan already. =P|||I think you've misunderstood me ;P

In summary I was just trying to highlight that with the current level of information from the game - you could fill your buffer with as much detail as you wanted (even including a unique Mob identifier, the name of the Mobs children, and which schools they go to....), and it would never do you any good, because if the only notification of a Mob dying is the combat log, then you can't link back to the buffer because you don't get the same level of "disambiguation" you did when filling the buffer in the first place.

(Although, I still maintain that if you could get the Level of Mob from the combat log, then that would have sufficed)

Hopefully, the new release will make it all much easier for you. GL ;)|||Thanks again Telic! As usual, you've been an excellent supply of help.

I think what I was trying to say before, is that the combat log doesn't need to supply any disambiguation other than the name of the unit and the person who has slain it. Any extra info (such as the level of the unit and so forth) would be bonus information and would greatly simplify/optimize the algorithm, but is not entirely necessary in order to pull it off.

A snapshot of surrounding units is taken each time the combat log is updated (when PlayerX has slain "____"). Thus, it's easy to tell which unit has died. Then, you take those units and compare ("guesstimate") them to the units in the original buffer, and shazam! -- you have unit association. The only problem is that it's too memory intensive like this, and still not entirely accurate, which ultimately isn't worth it... Especially when you have large numbered mobs. So yes, it is slightly possible to do before the new patch, but there's hardly any point in doing so.

I will simply await for the arrival of the 2.4 patch. Thanks!

No comments:

Post a Comment