Go to Page... |
Thread Tools | Display Modes |
07-24-13, 01:49 AM | #21 |
Ok I am up waaaayyyy too late. Here's what I have so far.
Lua Code:
I know one thing I still am uncertain of how to approach is sharing variables between events... such as passing the original method and threshold to my LOOT_OPENED to set it back. Also being able to trigger the correct things to happen on PARTY_LOOT_METHOD_CHANGED. What I was doing before for setting loot master and epic threshold if neither were already set is setting up a global variable or a local variable defined outside of the events as a trigger variable so that on this event if that is true then set threshold to epic (that goes along with the above, trying to figure out a more efficient way). Also, this event needs to do something when the loot method is changed before the mob is killed (but also not do it on the original change). So basically... Pull the boss. Set master looter if boss matches. Set epic threshold (which I'm doing by the PARTY_LOOT_METHOD_CHANGED because I can't call SetLootThreshold() right after SetLootMethod()... not sure if there's another way I can set the treshold with the method since doing it together will revert the method back to what it was prior to the change). If the boss isn't killed (wipe/reset) and the player changes the loot method for whatever reason, I need to execute a block of code. Will also need the same kind of thing when I get to the looting too since I don't want any looting happening during the boss or in between boss kills to revert the settings until the boss actually dies. What I was doing for this all before was just overall... terrible (defining local variables as nil, setting values of them in events and using them in other events... just a lot of random "trigger" variables for different scenarios). Anyway I really need to get to bed... it's late... and I'm rambling. Man this stuff is addicting. lol Just now seeing your latest message, I'll look it over and revise more tomorrow. Last edited by Niketa : 07-24-13 at 02:06 AM. Reason: One of my comments was messed up. |
|
07-24-13, 07:15 AM | #22 | |
Lua Code:
|
||
07-25-13, 06:07 PM | #23 |
Ok as far as functionality I think I'm done... I just need to test to make sure it works on all the stored bosses (which I run most of the raids this weekend, a couple I will have to check aside from my raids).
Is there anything that I've done that I should have done differently? Lua Code:
Last edited by Niketa : 07-25-13 at 06:14 PM. |
|
07-25-13, 09:18 PM | #24 |
Just from a quick glance, a few suggestions:
Code:
function events:COMBAT_LOG_EVENT_UNFILTERED(event, ...) local _, eventType, _, sourceGUID, sourceName, _, _, destGUID, destName, _, _ = ... Code:
function events:COMBAT_LOG_EVENT_UNFILTERED(event, _, eventType, _, sourceGUID, sourceName, _, _, destGUID, destName) [code] function events:COMBAT_LOG_EVENT_UNFILTERED(event, _, eventType, _, sourceGUID, sourceName, _, _, destGUID, destName) local mobIDa, mobIDb = mobIDfromGUID[sourceGUID], mobIDfromGUID[destGUID] local bossIDa, bossIDb = bossNPCID[mobIDa], bossNPCID[mobIDb] -- Quit if nokill is set, or the NPC isn't a listed boss: if nokill or (not bossIDa and not bossIDb) then return -- ...or if the boss died: elseif eventType == "UNIT_DIED" and bossIDb then nokill, mobName = nil, nil loottrigger = true return self:RegisterEvent("LOOT_OPENED") end -- Get mobName from either sourceName or destName. -- Since the NPC is definitely a boss at this point, it must be one -- or the other, so no need to explicitly check bossIDb too. mobName = bossIDa and sourceName or destName -- insert other code here, starting with the RegisterEvent line end Finally, the loot-related block in your CLEU handler looks a bit off. As written, you will never change the loot method unless it's set to something other than "master" on the very first time that code runs. After the first time, the "method" and "threshold" variables are already set, so you'll just return out. If that's not intentional, you should fix it. I can't really think of a reason to check and set the method/threshold variables inside CLEU anyway -- any changes to the loot method or threshold will trigger PARTY_LOOT_METHOD_CHANGED, which you're already handling separately, so that should be the only place you need to set those variables. If you're seeing issues while logging in in a group (eg. PLMC doesn't fire at login so you don't know anything about the loot method when CLEU starts firing), add a PLAYER_LOGIN handler that calls your PARTY_LOOT_METHOD_CHANGED method (just like your PARTY_LEADER_CHANGED handler calls your PLAYER_ENTERING_WORLD method). Also: Code:
self:UnregisterEvent(self) Code:
self:UnregisterEvent(event)
__________________
Retired author of too many addons. Message me if you're interested in taking over one of my addons. Don’t message me about addon bugs or programming questions. |
|
07-26-13, 04:33 PM | #25 | ||
As far as the defining method and threshold in the CLEU I've done that because I need to know the settings before changing to master looter and epic threshold because once the boss is killed and looted, those settings need to be restored. So if I pull the boss and it changes to master and epic, then the PLMC fires and gets current loot settings, it'll record them as master and epic, not whatever the settings were before the change. Lua Code:
Say I'm in a raid and I have my loot settings at group loot and uncommon. Once I pull the boss and it registers that it's found in the table, I start looking at the PLMC, get my current settings for later and then change to master looter and epic threshold. If my loot is not master yet (which it's not), it checks what my threshold is and since it's not epic, it sets master looter then sends a trigger to PLMC to set to epic (so we know it only does this PLMC code on the pull). If my settings were group and epic, it would see that I'm not master, but I'm already epic, so it just sets it to master. If my method is already master though it'll check my threshold and if it's not already epic, set it to epic and if it is, then it obviously doesn't need to do anything. Once the boss is killed, LOOT_OPENED is registered which sets the method back to the previous method (if the method was not originally master since that will cause an error for not specifying the loot master) and then send a new trigger to PLMC (to make sure it only registers on this when looting) to set the threshold back to the original threshold. The other part of the PLMC are if the player manually changes any loot settings before killing the boss. So say mid fight someone realizes they don't actually want to master loot it, so if they set either the threshold or method back to what it was before the pull, it automatically changes the other one to match their previous but doesn't reset the code... that way it doesn't just change it back. The extra bit of LOOT_OPENED handles resetting all of the variables and unregistering events in the event that the player did this. If the player changes the loot settings mid fight or after a wipe before another pull (etc) to something that wasn't what they had it previous, then it sets the other one back to their previous and resets the block of code so that next time they pull, it'll record their new settings and revert to those when the boss is killed. At this point, the code is reset they can freely change the other setting as well if they please and it shouldn't do anything. I've tested this on Onyxia and reg Alysrazor and Ragnaros so far. Onyxia and Alys worked as should and Rag switched but did not revert the settings (and that... I'm not sure why. I didn't think to look at my combat log to check if it registered as Rag dying... which actually it probably didn't since he doesn't actually... die on reg. If that's the case, couldn't I just add to the CLEU to check if fighting Rag on normal then register my UNIT_DIED code when UnitHealth is... whatever 10% is?) And I fixed the other two issues (yeah I derped on the unregistering). Last edited by Niketa : 07-26-13 at 04:37 PM. |
|||
07-26-13, 04:59 PM | #26 | |
For example, if the event is something like... Niketa melees Onyxia (even though Niketa is a priest, we'll pretend XD). In this case Onyxia would be bossIDb and should look for the destName to get "Onyxia". But bossIDa would return my ID which would be 0 and then my name. |
||
07-26-13, 05:51 PM | #27 | |
Lua Code:
That being said, you might want to write this more explicitly for the sake of the person reading it. |
||
07-26-13, 09:51 PM | #28 |
Code:
mobName = bossIDa and sourceName or destName Code:
if bossIDa then mobName = sourceName else mobName = destName end
__________________
Retired author of too many addons. Message me if you're interested in taking over one of my addons. Don’t message me about addon bugs or programming questions. |
|
WoWInterface » Developer Discussions » Lua/XML Help » Checking if raid group is in combat with a specific boss... |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
Linear Mode |
Switch to Hybrid Mode |
Switch to Threaded Mode |
|
|