Raid/dungeons event and data

[Vlad]

I think Blizz are a bit messy, making different popups and API for the different situations, if you are getting the popup queue thing it's one function, then if you get it while inside it's another and so forth. I haven't tested myself, that is why I am so inaccurate too, just trying to give tips on what I find.

The LFR, LFD and LFG files together make the dungeon finder, so some common functions are in the LFG one, while pure raid once should all be in the LFR.

I think the API you mention only return proper data at certain event, maybe only when they are asked to be shown to the player, after that they go away and the data isn't updated, am I right?

Things Blizzard should add are the ability to track alive/dead bosses in your raid, and the ability to determine when a boss is engaged and is defeated (not all bosses die and fire UNIT_DEAD) so these events would be very useful and make a lot of boss and raiding code easier to make. Maybe they will do this when they make their own boss mod, I think they mentioned that in the past, maybe they already did with their built in raid emotes and warnings. Shame... :3

[Animor]

I totally agree!

It's my second addon, so I'm kind of new with programming. I thought that such trivial information will be easy to get, but that wasn't the case. There are many APIs, each valid at certain time (like before you are saved, when you get LFG popup etc...), each relevant to a different type of instance (for 5men LFG there is none I've found).

But what is more concerning me now is what you wrote about UNIT_DIED, since I'm relying on it to catch boss kill/wipe. For what bosses it doesn't work and why? How else should I know when the boss died?

[Vlad]

Take CoT strath as an example, malganis despawns at 1%. Many other events don't really fie the unit dead event as you would expect.

It's a mess tracking boss deaths and especially if you wipe, since bosses don't usually notify you, it just resets.

[Phanx]

That's why I suggested looking at BigWigs. It has generic "boss engage/boss death/wipe" detection code (in the core), as well as code to handle detecting those events when they don't happen the normal way for specific enounters (in the individual boss mods).

[Animor]

Thanks Phanx. Ofc I looked there, more than once, after you previously suggested it. I also looked at DBM, but completely lost track of the code there.

I've found it a bit hard to understand BigWigs code. There are some target monitoring functions in core.lua, but I'm not sure what exactly they do. And there are some engage/kill/wipe functions in BossPrototype.lua. However, the functions in BossPrototype.lua are never called. Look for example at boss:CheckForEngage() or boss:CheckForWipe(), I couldn't find where these functions are being triggered by events (I grepped them).
There is also a syntax I'm not familiar with there: some of the functions are wrapped with "do ... end". Some are not. What does it mean?

Generally speaking, there are some basics I don't know how to implement. for example, how to detect a wipe if one of the players stays alive (hunter feigning death, or holy priest in angel mode, or rogue hiding).
How to handle a player releasing his corpse and teleporting to GY outside the instance, before actual kill/wipe. This player may be alive or still a ghost at the instance portal until the encounter ends with either wipe or kill.

[Animor]

A humble bump...

Can anyone assist me in understanding the basics behind how Bigwigs (or any other boss mod) identifies Boss fight start and end (either kill or wipe)?
Some things I didn't understand there:
1. In BossPrototype.lua there are some functions like boss:CheckForEngage() or boss:CheckForWipe(), but it looks like they are not being called.
2. What is the meaning of wrapping some functions with do ... end.
3. What is the idea behind detecting a wipe, in case some players disengage out of combat and remain alive when the boss resets, or release the spirit and come back to life at the entrance of the instance.
4. How to handle bosses that disappear without "UNIT_DIED" event. I saw some events triggered by bosses "yell" or emotes. So isn't there a general way of detecting it? The code should be boss-specific?

Thanks for any help

[Rilgamon]

do-end blocks are used to create a new "local" instance.
Variables/functions used in this block are local to the block.
This way you can have one-time code freed after it has done its job.

[Animor]

OK, thanks.
How can you call those functions from outside the "do-end" block, if the functions are local inside this block?

[funkydude]

Those functions aren't local, they are attached to the addon prototype so they can be called from outside the do end block (boss modules). The block restricts certain variables to being accessed by that function.

The Engage and Wipe functions are used for bosses where the ENGAGE event doesn't fire, so very, very rarely since Cataclysm.

The magic all happens in the CheckBossStatus function which fires every time the ENGAGE event fires and decides if a boss has been engaged or wiped on. Bosses are identified by their IDs, and IDs are provided by every boss module.

[Animor]

Thanks

I've looked at boss:CheckBossStatus() function.
Can you direct me to the line where you distinguish between a kill and a wipe?

I'm interested in that since one of my goals is to count kills so I'll know how many bosses were defeated in the current LFR raid/LFG dungeon.

[funkydude]

You'd be better off looking at the engage function of my 'bRez' addon, it's probably easier to understand.

[Animor]

Originally Posted by funkydude You'd be better off looking at the engage function of my 'bRez' addon, it's probably easier to understand.

Thanks

I understand how you set self.isEngaged, according to the BossN units. However, I couldn't see in your code where you decide if a boss fight end is due to a wipe or due to a boss kill.
This is the info I'm looking for, can you elaborate a bit about it?

[funkydude]

That's decided by the unit itself dieing. In the case of Big Wigs the module may "wipe" (reset) because the event fires before the death sometimes, but that doesn't matter if you're disabling the module after death.

[Animor]

But not all bosses have UNIT_DIED event. I think Spine of Deathwing for example, or bosses that just "vanish" once you down them. So I understand how to tell that the boss is no longer engaged (the battle was ended), but it's not clear to me how to identify, in a generic way, that the encountered was won.

[Phanx]

Process of elimination. If the encounter ends, but there wasn't a wipe (all raid members died or left the instance), then it was a success.

[Animor]

Originally Posted by Phanx Process of elimination. If the encounter ends, but there wasn't a wipe (all raid members died or left the instance), then it was a success.

Thanks
I've also thought of this idea. However, in many cases a hunter feigns death (or a rogue vanish, or a mage go invinsible etc) just before a wipe, in order to mass rez the raid. So, when the fight ends due to a wipe, there might be a living player inside the raid. I made a "grep" on Bigwigs and DBM, but couldn't see any code that handles "feign" or "vanish".
So I have no idea how they handle it.

[Animor]

I think I understand roughly how DBM knows if there is a wipe or kill:
1. They run every 3 (seconds?) a function that checks for a wipe.
2. They run a function that checks for boss (or boss related mobs) kill on every UNIT_DIED.
3. They check some msg (I think it's a boss yell or something like that), for boss kill.

If (1) happens before (2) or (3) then it's a wipe, if (2) or (3) happen before, it's a kill.
I think it's an ugly way to know if it is a kill or wipe... not blaming the authors ofc, it's the lack of proper API for boss fights. I just don't like the idea of running same function in a scheduled loop. I wish I could think of a cleaner solution for this problem.

By the way, regarding the suggestion (by Phanx) of taking into account players location (inside or outside the instance) - apparently you can do that only for raid members, using GetRaidRosterInfo(index). But I coudn't find a way to get the location of party members, so I can't use this method in 5men dungeons.

[Phanx]

GetPlayerMapPosition(unit) works for player, partyN, and raidN units.

The current BigWigs code is a lot harder to read than I remember it being... you might try looking at some older (Wrath era) versions of BossPrototype.lua. I don't have a grep tool at work, and I can't even see where the current BigWigs even calls its CheckForWipe function.