Execution: Custom Alert Mod (GUI now available)

[moduspwnens]

I'm looking for a good algorithm for rule to event comparisons. I thought what I was doing would work, and while it does, I tried it out on Yogg last night for funsies with only one rule (source -> target for fear) and it quickly jumped to 9MB of memory eaten. I know of some changes I'm going to make, but I thought I'd post here to see if anyone has done something similar or can think of a good algorithm. Storing the rule can be inefficient or slow, as that only really happens at load time or when the user enters a new rule. I just need it to be as fast as possible when comparing the event to rules.

[Arees]

I just need it to be as fast as possible when comparing the event to rules.

I don't know much about LUA, or scripting languages in general, so I don't know what kind of data structures you have to work with. A hashmap would be incredibly efficient for looking up rules. It has O(1) search time. Its not as efficient for space, but thats a paradigm I studied in my computer science classes... you trade off speed for memory and vice versa.

If you don't know what a hashmap it, think of it this way. Each 'event' stored in it also has a key that references it. For example, if I were writing a hashmap to store people's medical records, I would have some function add(person, ssn). Where ssn is the identifier for that person object. What happens is that ssn is really a pointer to a memory location. So when I called get(ssn) it goes straight to that memory location and grabs the person.

*edit*
We're really busy at work... we're trying to get a beta version of our software out within the next couple weeks, and I am writing a server/client that handles sending alerts to the clients when something goes wrong (like a database crash). When both the server and client have several threads running, there are many concurrency issues to worry about and its a pain to test.

When I'm done writing this pain in the butt server, I'll probably have some time to spare to help you code (after I learn some LUA). I'm really liking TJH and you're new addon sounds intriguing.

[moduspwnens]

I ended up switching to the following algorithm. When a user inputs a rule, make sure the arguments for the event are in the order the game will be giving. That way, I just have what is essentially a "while" loop that goes from argument to argument and breaks if it sees a parameter that doesn't match (and matching is defined by a function that varies by parameter). I previously had it formatting each event by its expected arguments and whatnot before being processed, but that was just unnecessary overhead.

[moduspwnens]

I feel like I've come to a point where the add-on is ready enough to be uploaded as working and useful. It has been uploaded to WoWInterface, and a download link is available here.

Execution
Combat Alert Mod

ReadMe Updated 10/15/2009

Commands:

• /ex - Open rule creation GUI
• /ex list - List rules
• /ex load 3 - Load rule 3 into GUI
• /ex options - Show options

ADVANCED: Logical Operators. You can now use logical operators for both event parameters and extra filters. This means you can use "and", "or", "not" and parentheses to be even more specific with your rules. Execution supports the following logical operators:

& (and)
| (or)
! (not)
( ) (grouping)

Let's say you want to be helpful and announce when someone is hit by Mimiron's Shock Blast, but you want to be a little sneaky and NOT announce when it's you that gets hit. Rather than specify an individual rule for everyone in the raid but yourself, just change your target flags ("affiliation") for it from "RAID" (announces for anyone in the raid) to "RAID&!MINE" (which reads as "in the raid and not me"). Bam. Sneakiness accomplished. These operators are translated and interpreted by the client itself, so the sky is the limit as far as how complex you want to get with them.

Bugs/Feedback. If you find a bug or have feedback on this, feel free to post here or send me a PM. I'll try and get a fix up as soon as possible.

[Jerey-Darkspear]

I was looking for a case-switch statement in lua for something else earlier and found a page that looks like it might be exactly what you're looking for: http://lua-users.org/wiki/SwitchStatement

Enjoy!

[moduspwnens]

I was looking for a case-switch statement in lua for something else earlier and found a page that looks like it might be exactly what you're looking for: http://lua-users.org/wiki/SwitchStatement

Enjoy!

Nice! It looks like it is exactly what I'm looking for. It'll take a little reworking but that appears to be a great idea. It's definitely on the list.

[trellian]

That reminds me... I need to think of a replacement for DBM's reply/status whisper backs to people who aren't in the raid ("<DBM> Modus is fighting Yogg-Saron (50%, 25/25 alive). Whisper with "status" for an update."). I think I'll make that a different add-on. I have some good ideas for making one that's a little, well, better. Well, now that I think about it, though, some of its methods and data would be duplicated if you have both my add-on project and a separate reply add-on. That may be better just as an "extra module."

BossWhisperer (Ace addon) allready exist

[moduspwnens]

BossWhisperer (Ace addon) allready exist

/shrug. Might not have to worry about that one then.

If anyone needs help creating any rule for this new add-on, post here and I'll see if I can help you out.

[Arees]

I've been investigating the vehicle thing. I'm probably gonna mess with it some this weekend. I'm going to make a small addon with a / command to run it so that whatever your targeting it will either say "X is a person" or "X is a vehicle and Z is driving it."

This code should decide if a unit is a vehicle or not, but I haven't tested it yet, and I'm not sure if I have the correct syntax either.

Code: Select all

function yourmod.UnitIsVehicle( unit )

   local g = UnitGUID( unit )

   if not g then return end

   local t = tonumber( g:sub( 5, 5 ), 16 ) % 8

   if t == 5 then return true end

end

I'm still trying to work out how to tell who is driving it.

[moduspwnens]

I'm still trying to work out how to tell who is driving it.

Yeah, that was my problem. The only way I can think of is, well:

Code: Select all

for i=1,40 do
    local petGUID = UnitGUID("raidpet"..i) or 0
    if petGUID == targetVehicleGUID then -- Presumably whatever the GUID of the vehicle you've found is
        return UnitName("raid"..i)
    end
end

It would work, but be pretty inefficient unless you mapped it for future events, which is when I decided it was outside the scope of TJH.

[Arees]

http://wowprogramming.com/docs/api/UnitVehicleSeatInfo

Code: Select all

controlType, occupantName, occupantRealm, canEject, canSwitchSeats = UnitVehicleSeatInfo("unit", seat)


hopefully the drivers seat is index 0... or does lua start at 1? I've seen several for loops that start at 1 instead of 0.

[moduspwnens]

http://wowprogramming.com/docs/api/UnitVehicleSeatInfo

Code: Select all

controlType, occupantName, occupantRealm, canEject, canSwitchSeats = UnitVehicleSeatInfo("unit", seat)


hopefully the drivers seat is index 0... or does lua start at 1? I've seen several for loops that start at 1 instead of 0.

Well, the problem is that you'll need a unitID to use that function.

[Arees]

Well, the problem is that you'll need a unitID to use that function.

Can you not pass it the guid of the vehicle?

I know it can be done... the game knows which one of the pyrite debuffs is mine because its big and farther left than everyone elses. I just have to figure out how...

[moduspwnens]

Well, the problem is that you'll need a unitID to use that function.

Can you not pass it the guid of the vehicle?

I know it can be done... the game knows which one of the pyrite debuffs is mine because its big and farther left than everyone elses. I just have to figure out how...

The GUID isn't the same as the UnitID.

http://www.wowwiki.com/UnitId
http://www.wowwiki.com/API_UnitGUID

The way you'd figure out which one is yours is just how I showed above, except rather than cycling through the raid, you'd just see if the GUID in the combat log event matches UnitGUID("vehicle"), which is the vehicle the player is currently in.

[fafhrd]

Hm. Is it possible at all to have a rule span multiple events? Like say you get a UNIT_DIED for a tank, which I think includes the ID of the UNIT that killed him. You then want to see the last buff that unit gained (not the tank, the mob that killed him).

I suppose that's actually jumping ahead a bit by needing to remember past events, a simpler start would be to see something related to the mob after it kills the tank, like the next buff it gets, or the next person it attacks. A rule to catch a mob killing the tank is easy, and a rule to catch a mob hitting a player is easy, but how about a mechanism to pass attributes of an event caught by the first rule (viz. "this is the guid of the mob that killed a player") as input to the second rule (viz. "filter SPELL_DAMAGE for unit with GUID"). And then add something so that the 2nd rule only matches one event and is then disabled (until the first rule triggers again).