Best way to determine who killed me
Hi all,
I'd like to improve my ganklist addon to offer the possibility to show a frame with the name of the char that killed you to easily add to the db. So I begin to study a little bit the combat log. The best way I found to determine who killed me is something like this pseudo sample code: Lua Code:
Some questions now: 1) As noted in another thread the UNIT_DIED subevent not contain all the information about the src of the damage so I think I can't use it. So is this the best way ( check the overkill ) ? 2) May I use the CLE not CLEU ? I have not understand so much the differences but if in the first there are only events related to me probably is more efficent than the second and for what I need is the same. 3) I am a little bit scared about the so many conditions to parsing of the die event ... if it is my name related (destName), if I am not in a bg/arena, if the srcName is a Player, if this player is an Enemy (this could be omitted I think), if the there is an overkill so I am died by spell or it was a melee ... etc :-) . But I think I can't summarize them all :-) Thanks all for attention. |
You could use COMBAT_LOG_EVENT instead of COMBAT_LOG_EVENT_UNFILTERED, but only if your combat log is currently set to display the events you need. This means that if you switch to a combat log filter that only shows your actions, for example, your addon would stop working. You also can't guarantee that other people will have their filters set correctly. For these reasons (mainly the second) you should always use CLEU over CLE for addons you plan to release to the public.
Also, there's no need to use string.sub and tonumber on the GUID; just use bit.band on the whole GUID and compare it to the COMBATLOG_OBJECT_CONTROL_PLAYER global (0x00000100). This will save you 2 function calls and one string creation. Here's a drycoded example with a few other minor changes: Code:
-- For general use, I wouldn't recommend obsessively upvaluing every |
Quote:
Probably I also seen these globals during googling/wowiki/wowpedia and the book but I was unable how to use them with proficency. Quote:
A thing which I didn't understand so well in your code is the defining as local of: Lua Code:
1) Defining a lua function (bit.band) as local is better than use it as is ? 2) Defining local to this addon the global constant for the controller type. Is it better and faster than using as is ? Last question: Lua Code:
could be evaluated depending of a condition or a variable name ? Something like (I am writing on the fly so be kind about my errors in the replies :-) : Lua Code:
Thanks again for everything. |
Quote:
local bit_band = bit.band... simply creates a local shortcut named "bit_band" that points to the global "bit.band" function. It doesn't replace or change the function in any way. It just makes it faster to access it. Imagine the global namespace as a book, and yourself as a reader with absolutely no short-term memory. Every time you ask for "bit.band" you have to go through the whole book to find it. Creating a local shortcut -- this is called an "upvalue" -- is like putting a sticky note on the page, so instead of having to look through the thousands of pages in the book (at the moment there are 49,080 objects in my global namespace) you only have to look at the few sticky notes sticking out of the side. Much faster. Plus, "bit.band" is actually two lookups -- one global lookup to find "bit", and then a table lookup inside "bit" to find "band". So creating the "bit_band" upvalue is even faster in this case. Quote:
Now, despite all of this, I wouldn't suggest creating local upvalues for every global thing you access in your addon. Only do it for things you access very frequently, like in an OnUpdate script, or in response to events like CLEU that fire very often. For infrequently accessed globals, the speed doesn't matter, so creating upvalues just adds clutter to your code. Also, upvalues will always point to the original value, so if someone comes along and overwrites the global "bit.band" with a new function, your upvalue will still point to the original function, not the new one. Obviously nobody is (or should be) overwriting "bit.band" but this is another argument against upvaluing everything all the time. Also, there is a limit on the number of locals that can be in scope at once; I don't remember what it is, and you probably won't ever hit it in normal use, but you might if you go wild with upvalues. Quote:
If you want to ignore events that occur inside a battleground or arena, you should register for the event that fires when you change zones, and register/unregister CLEU as needed depending on what kind of zone you're in: Code:
-- Don't register CLEU here! |
Quote:
Hi Phanx, thanks so much for your kind reply. I always don't like to quote everything in a reply but I think your reply is a masterpice and should be sticky somewhere in the LUA forum. Finally I begin to understand how things move inside addons and the game itself. Thanks again. |
There is some more discussion on the topic here:
http://www.wowinterface.com/forums/s...ad.php?t=43658 (More book analogies for you. :)) |
Thanks for the very interesting thread Phanx.
Lua and Lua in WoW is for me a so different approach that I usually spend hours trying to do so simple things that I usually do in other languages in a few minutes. But I like it and so every input is more than welcome !!! :-) Returning on your code above, I check it better and I though a thing. If you log in a zone and NOT change it the CLEU never be triggered because it was not registered. So perhaps is it better if we register it by default and then UNregister it if we enter in a pvp area ? And if you log in a pvp area (like wintergrasp) you are unlucky :-) (probably I should check also ZONE_CHANGED also ???) Thanks again for your time. |
What about this ?
It is not so beautifull but when you login you move and walk a little bit it should trigger :-) Lua Code:
If you login and don't move it doesn't trigger but in this case you want stress the poor programmer :-) P.s I have also add the line: Quote:
|
Instead of ZONE_CHANGED, use PLAYER_ENTERING_WORLD. This will fire both when you first enter the world (no matter what kind of zone you're in) and whenever you pass through a loading screen.
Also (I might have mentioned this in one of your other threads) semicolons at the end of lines are not needed in Lua. They can technically avoid issues with ambiguous syntax, but I've been writing WoW addons in Lua for about 7 years now and have never even seen any code where a semicolon was needed to clarify the syntax, so unless you're dead-set on using them as a carry-over from some other programming language you're used to working with, I'd suggest leaving them out to reduce clutter in your code. :) |
1 Attachment(s)
Hi Phanx,
Thanks so much for your helps again. I used the PLAYER_ENTERING_WORLD event and everything is fine now. I can be killed everytime and everywhere now :-) I removed also every ";" :-) that I put in my code or because I have habits to use them or because when I am doing copy and paste sometime I get them too :-) Now I have add also an input frame, very simple that should be fired when you are killed or you use the hidden cmd switch "debugaddframe" . It will show the "killer" and let you choose to input a custom note for adding in the DB. I have learn that adding frames in lua is a long work... So I'd like to ask what is the better way to add frame ? Simple things, like a scroll lists and some input editbox. Continue to write them in lua or try to use xml ? ACE ? ... and to code them ? I am usually "vi" addicted but this time I think I'd use happily something that automagically generate code of the frame :-) But I think I have to continue to use vi because all the things I have tried are outdated or simply crash on my win7-64 or my mac :-) |
Years ago, there were several programs available for "automatically" generating XML code from a visual GUI, but none of them ever worked very well -- think "HTML code generated by MS Word in 2002 -- and none of them have been updated in a very long time, so they are not up to date with the current WoW API. Long story short, you shouldn't use them.
Anyway, I wrote up a (fairly) simple addon with a scrolling list frame for someone on the WowAce forums a while ago. If you ignore all the code related to looting and item icons and such, the rest should be relatively easy to understand and adapt: http://forums.wowace.com/showthread.php?p=320619 You'd also want to modify the click handler to add an editing function, in addition to the current deleting function. |
Downloaded the sandbox2 addon... I am checking it ...
And I continue with my infinite number of questions :) Lua Code:
if possible that this "if" is true also for raid bosses (the second condition) ? My guild raid mates continued to be prompted by RemGank that want to add bosses name as a possible gankers after a wipe :-) Thanks :-) |
Try changing this:
Code:
bit_band(sourceGUID, COMBATLOG_OBJECT_CONTROL_PLAYER) == COMBATLOG_OBJECT_CONTROL_PLAYER Code:
bit_band(sourceGUID, COMBATLOG_OBJECT_CONTROL_PLAYER) ~= 0 |
It doesn't work either.
I have read here and there and I found something: Quote:
Quote:
Quote:
Thanks very much for attention and patience. |
This will return whether a guid is a player.. tonumber(sourceGUID:sub(5,5), 16) % 8 == 0
You could probably get away with just this: sourceGUID:sub(5,5) == '8' You can use this to test it in-game.. Lua Code:
|
Actually, looking at this again, I realize I'm an idiot, and you should be using sourceFlags instead of sourceGUID in the bit.band with COMBATLOG_OBJECT_CONTROL_PLAYER. >_<
|
Yeah I was kind of wondering about that..
But you can get the unit type from the guid anyway, so that should work. |
You can't get the reaction, though.
|
Yeah, but if they killed you then you can infer that they were hostile (nevermind).
If you want to check if they're mind controlled you'd have to do something else. I guess it could be friendly fire, so you should probably check the flags anyway. I think a mind controlled player would be flagged as a hostile pet. |
Don't forget friendly fire. If you've already got the sourceFlags, though, it's just easier to check those than to try to account for a bunch of special exceptions, since that's exactly what they're there for. Try this:
Code:
local HOSTILE_PLAYER = bit_bor(COMBATLOG_OBJECT_REACTION_HOSTILE, COMBATLOG_OBJECT_CONTROL_PLAYER) http://wow.go-hero.net/framexml/16309/Constants.lua#374 |
All times are GMT -6. The time now is 12:41 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI