WoWAnalyzer icon indicating copy to clipboard operation
WoWAnalyzer copied to clipboard

Adding Boss features info

Open Iskalla opened this issue 8 years ago • 18 comments

When reviewing the Completeness of Moonkin, Zero came across a log with a green parse, that only had one problem: downtime. After analyzing the log, its obvious that the main problems are lack of proper legendaries for the fight and lack of tier sets.

I've been thinking about a possible solution to reflect this in the analysis that requires as little maintenance each tier as possible. Best idea I've come up with is to have some sort of static info on encounters, with specific parameters, that would allow us to somehow check for best leggos, tier sets (ofc would have to make it clear that this is based on general features of the encounter and won't be 100% exact at all times). This would only have to be changed once per tier.

Once this is done, an analysis for optimal (or usable) talents / legendaries should be easy to implement - maybe add a tab about it? -, tier sets would require more each-tier-coding, but maybe there's a cleaner solution, if someone came up with something...

For now I've thought of something like this:

image

With that info I could make something work for moonkin, idk if other classes would need more info. A bit of feedback and any suggestion on what else to add would be appreciated

This relates directly to issue #16

Iskalla avatar Sep 26 '17 07:09 Iskalla

This looks exactly like what I had in mind! 👌 A few questions and suggestions mixed:

  • How about changing singleTarget to targetType which is an enum? Would make it more obvious that single target means it's not considered an AoE boss (true or false isn't as explicit).
  • Is addWaves the same as meaning a AoE boss?
  • Should this include a cleave property?
  • What determines add health; at what point is it low, medium or high?
  • How could secondaryPrioTarget be used?
  • What determines high, medium or low movement?

Also it would be nice if the boss ids object was used for boss ids and the difficulties were via an enum.

MartijnHols avatar Sep 26 '17 18:09 MartijnHols

How about changing singleTarget to targetType which is an enum? Would make it more obvious that single target means it's not considered an AoE boss (true or false isn't as explicit). Also it would be nice if the boss ids object was used for boss ids and the difficulties were via an enum.

Yeah, all of this sounds better :)

Is addWaves the same as meaning a AoE boss?

Not necessarily. An AoE boss is a boss where you spend most of the time hitting more than one target. A good example is Mistress: It's a ST boss with add waves, you need to dps adds at certain points of the fights, but you are most of the time doing ST damage to the boss An AoE boss could be Desolate Host, where you are DPSing more than one target for most of the fight.

Should this include a cleave property?

Could you elaborate on this? Do you mean as "if more than one target, you can hit both at the same time"? Or something else?

What determines add health; at what point is it low, medium or high?

That's pure feelycraft right now in my head 😛 I suppose we could get some numbers for healt based on Avg DPS of classes, but i'd have to give it some thought. For moonkins this is really important, as we dont have burst AoE damage and we don't even try to AoE packs with low health (tbh i just know right now cause i know in which bosses i should dump all my AoE, just do it at the beginning or pretty much ignore adds, cause it'd be a dps loss)

How could secondaryPrioTarget be used?

I'm thinking something such as Maiden add in Fallen Avatar, some classes equip or talent differently to have burst damage on target change or every X time, while maintaining the thing ST. I'm not really sure about this property, but I think it might be useful for some specs.

What determines high, medium or low movement?

Yet again, pure practice and feelycraft. I'd say this is an easy thing to determine, tho. Most fights are in general considered Medium movement. Low movement are patchwerk fights were you pretty much don't have to move - think hc Goroth, for instance - High movement fights are the ones where there are mechanics that make you move at all times o every maybe 20s or so - think Mythic Mistress where you need to move for every tornado, to get and drop fishes, to soak or place beams, to get out or in the jellyfish AoE, to dodge or soak purple pools, to dodge the whale's jump, etc.

I'd say most fights would be considered Medium movement, unless is pretty obvious that you either move little or a lot.

We definitely should so something as usable by everyone as possible, and I suppose without objective metrics this could be tricky... I don't really know how to tackle all these feelycrafting issues ^^u

Iskalla avatar Sep 27 '17 09:09 Iskalla

As for FightType (or TargetType or whatever), i do think that cleave should be part of it. For example, Frost Mage is a two target cleave heavy spec, and some talents are better for two target cleave than AoE. The problem is that some fights are both Cleave and AoE .... like High Botanist Telarn for example, or Mythic DI. There is almost always a secondary target that you can cleave onto, but there are also waves of adds.

As for the format you posted the screenshot of, I like it, but i think the heading should be the bosses name instead of its ID ... that way if you are looking at someones code it is a lot easier to tell what boss they are referring to if its something like boss.MISTRESS_SASSZINE as opposed to boss.2037 (unless im mistaken in the way that would be listed).

As for the difficulties, it might take up a little more space, but would it be better to split by difficulty first and then split by boss? I have no idea if that would be better or not, but might make it a little easier to read and follow.

i.e.

MYTHIC = [ MISTRESS_SASSZINE: { id: 2037, fightType: AOE, movement: HIGH, addHealth: MEDIUM }],

HEROIC = [ MISTRESS_SASSZINE: { id: 2037, fightType: AOE movement: MEDIUM addHealth: LOW }],

Also, speaking of downtime and movement, what about bosses that have intermission phases where you cant fight the boss or where you shouldnt fight the boss, like Intermission 1 on KJ? It is a setting that would rarely get used, but it increases the player's downtime and makes that stat meaningless since you cant really decipher how much of that downtime was intermission and how much was the player not doing anything.

Additionally, as a bit of an aside, it might be cool to at some point be able to do stuff like "How much avoidable damage did the player take?" where the bosses abilities and spells are loaded somewhere similar to how class spells are. Not really something that is needed, but could help a player get better if they knew how much damage they took and how much of it was avoidable.

Sharrq avatar Nov 10 '17 19:11 Sharrq

Would it be possible to maintain a list of current attackable ennemies ? Does an add that spawns generate an event ? Or could we imply what adds are up by the damage done to them (assuming at any given point, if a add is up, someone is going to hit it) ? Maybe this would give more accurate results in suggesting what to use at what point ?

karlpralow avatar Nov 10 '17 20:11 karlpralow

What if an add spawns off to the side and no one attacks it? Like the engineers on garrosh?

It's rare, but possible I suppose

Sharrq avatar Nov 10 '17 20:11 Sharrq

Specific cases could be handled with a npc blacklist. I think the issue with saying "fightType: AOE" is some specs will AoE at x number of targets, some wont. Some classes will start AoEing with 2 targets, some do at 4 targets. Having the enemy count would let classes handle their own recomendations with very low impact on current architecture.

A balance druid could do something like On By Player Cast { if enemyCount > 3 and Casted Starsurge then recommend using starfall more}.

karlpralow avatar Nov 10 '17 20:11 karlpralow

Some brilliant mathematician could even figure out if there was clumps of adds or were they seperated (For cleaving suggestions)

karlpralow avatar Nov 10 '17 20:11 karlpralow

I added boss settings to the Results branch, initially for better image management but I also reserved space for boss specific settings. The objects are already usable in analyzers via the this.owner.boss prop, so it wouldn't be hard to add boss specific settings. I haven't thought that out completely yet, one thing that would greatly help in doing so is a very specific example of a situation where you would want to know this. Could anyone describe a specific boss in Antorus that would require different analysis from other bosses and how exactly that should modify your results? With that I think we figure out how to solve it and set a precedent for other similar problems.

Example: https://github.com/WoWAnalyzer/WoWAnalyzer/blob/results-2.0/src/Raids/AntorusTheBurningThrone/Aggramar.js

MartijnHols avatar Dec 19 '17 11:12 MartijnHols

The reason I ask for the above is that I think something like "base downtime" might be preferred over "boss_movement" as it's much more specific. I'm thinking "base downtime" could be something like the duration of the Time Stop on Elisande which could then be subtracted from downtime and maybe other places that need it. Perhaps pods on Argus would be a consideration too?

boss_movement is pretty vague and I think it will be hard to say how much it affects metrics.

MartijnHols avatar Dec 19 '17 11:12 MartijnHols

The only thing I really care about is whether the fight has aoe or cleave... Cause then I can do things like "this is an aoe fight but you never used Blizzard" or this is an aoe fight, this talent would be better.

The down time reduction would be good also.

I tried to add settings to those boss files, but I ran into issues with git so I'm just going to wait till it goes live and then add to it

Sharrq avatar Dec 19 '17 14:12 Sharrq

What determines if it's an AoE fight? I guess for Blizzard you'd want to know something like:

bossAvailableTime: 0-100% 2targetsAvailableTime: 0-100% 3targetsAvailableTime: 0-100% 4targetsAvailableTime: 0-100% 5targetsAvailableTime: 0-100%

Where available time would probably be based around time within Blizzard's radius.

MartijnHols avatar Dec 20 '17 18:12 MartijnHols

Ideally yes you would want to know how many mobs are up at any given time, but my understanding is that that is not possible given WCL Query constraints (As if a mob spawns and you never hit it and it never hits you, then it doesnt exist).

So I was settling more for just an understanding that x fight is an aoe fight because it has waves of adds that spawn. Like Harj, Mythic DI, High Command, Portal Keeper, Eonar.

You could also define a fight as being constant aoe (Mistress, Eonar) vs aoe waves (Harj, Portal Keeper, High Command). and that might be more helpful.

It wont be perfect, but its better than nothing i support.

Sharrq avatar Dec 20 '17 18:12 Sharrq

Yeah my idea is we feelycraft those numbers to store them as static values. Constant AOE is 2-whatever is the max targetsAvailableTime = 90% or something.

MartijnHols avatar Dec 20 '17 18:12 MartijnHols

i had a similar idea, providing a rough estimate of mob count at any given time. i.e. when Harj does spawn adds, there is 4-5 of them.

The closest we could probably get is knowing the timer on the abilities to know "every 25 second 3 adds spawn" or something like that, but even that can get weird

Sharrq avatar Dec 20 '17 18:12 Sharrq

So if Blizzard is effective from >=3 targets, you could look at the uptime of at least 3 targets (e.g. 60%) and assume 60% of the recommended efficiency that is the default.

MartijnHols avatar Dec 20 '17 18:12 MartijnHols

Yea it just gets tricky cause like ...

Ideally on Portal Keeper, you would cast Blizzard at least once every time the imp portal comes up .... unless you are in a portal group in which case you might not even be on the platform.

And even still, you dont really have any way of knowing when the adds died, you would only know roughly how often they spawn .... but better than nothing.

And yes, for Blizzard specifically 3+ Targets is ideal and should be used pretty close to on cooldown when there are 3+ Targets cause each hit of Blizzard lowers the cooldown on Frozen Orb by like 0.5 seconds.

We would just have to keep things fairly loose and generic with aoe suggestions cause we cant say for sure whether any adds are up or not or how long adds were up or anything like that.

Sharrq avatar Dec 20 '17 18:12 Sharrq

Also just to add, it might also be helpful to add a setting to disregard or hide downtime on certain boss fights (Like Eonar) where the downtime stat is pretty much worthless because your downtime is dictated by how high or low your DPS is (Kill stuff faster = more downtime, Kill stuff slower = Less Downtime)

(Saw this posted in mage discord) https://images-ext-2.discordapp.net/external/19YgdTRwF9S7Imer7vnmdtqxhfojCjVZxaU71zo5EPQ/https/i.imgur.com/Ohdt4Hp.png

Or to set a lower downtime threshold for fights like Imonar where your downtime is dictated by how quickly your raid can cross the bridge

Sharrq avatar Dec 20 '17 18:12 Sharrq

Making suggestions based on the encounter gets problematic when tactics and assignments are vastly different from guild to guild. This is particularly the case when it comes to adds and AOE. Since there is almost always a boss to hit, it is often correct to ignore hitting adds and let classes that have more efficient AOE kill the adds. However, AOEing will usually result in the better parse, so we would have to make a choice between suggesting something that either A) goes against the common tactic used for the encounter or B) Does not yield the highest DPS. A great example of this is Fallen Avatar. If we suggest cleaving on the maiden it would be misleading for a player that is not assigned to cleave on it and vice versa. The same is the case on pretty much any encounter with multiple targets. Even on council bosses expectations will be different based on whether the bosses are tanked in cleave range or not.

I think the best way to go about AOE suggestions is basing it on what the player does. For instance, if a player has a talent or legendary that increases the damage of an AOE spell that they aint casting, it would be reasonable to suggest that they use another talent/legendary. Another example could be looking at the number of targets hit by an AOE spell. For instance, if blizzard only hit 1 target the player shouldn't have cast it.

tl;dr: We can say when a player didn't use an AOE spell, talent, legendary or similar effectively, but I don't think we should be deciding if they should be AOEing or not on any given encounter.

Just to clarify, I still think boss specific parameters has other uses, like unavoidable downtime (KJ or argus transitions for instance) or similar. I just don't think AOE suggestions should be boss specific.

Gebuz avatar Jan 02 '18 10:01 Gebuz