WowAce

The following events were in RPHelper 2 and are currently not in Speakinspell: -Falling damage -Drowning -Hurt (ie, you take a huge hit) -Block, dodge, miss, parry (most effective when used for a mob's special attack rather than just auto attack) -Crowd control events: ---Polymorphed ---Silenced ---Possessed ---Fear/Horror -Looting cash -Learning a new ability/recipe -Summoning a mount or pet (as an automatically detected event) -Gaining/losing aggro -Logging out not in an inn And here are just more ideas: -Loot an item -Other mechanics affecting your character, as listed in http://www.wowwiki.com/Mechanic -Monster emotes (particularly "runs in fear" or "becomes enraged" -Monster speeches (ie, Rags yells "TASTE THE FLAMES OF SULFURON" and you yell back "No thanks, spicy foods give me gas")

Forgot some:

Pet events:
-Pet died (You killed Fluffy, you bastard!
-Pet crits (Go for the eyes, Fluffy!)

I love them all! So much potential...

So many new event triggers makes me want both a better GUI and a better data structure format for the EventTable and its keys. What do you think about adding these events under the current paradigm of event key strings (SS 3.3.5.xx) and then figure out how to change it later as it outgrows the current GUI design? It would mean more data to work from when designing the next version of the implementation, but also more work in oldversions.lua if we need to redesign the event keys in the future.

I really don't have a better idea (still!) than EventTable[key] as a quick way of finding whether an event should be announced. Even if keys are changed to spellIds were applicable, that's still using a key string, which still drives the GUI to want to list them (or do something to ensure that specified keys are all valid).

EVENT_MONSTER_SPEECH_TASTE_THE_FLAMES_OF_SULFURON as an event key just makes me shudder. That's how it would have to be done in SS 3.3.5.xx where we are today, but that's a horrible way of doing it. It should just be a monster speech event, and the callbacks should be in a cascading/nested data structure under that somewhere. Add that "No thanks, spicy foods give me gas" should be one of N random callbacks.

Anyway, putting aside my rambling about the backend issues, this is such a long list that the ticket will be hard to close. Each event trigger should get its own ticket if it has any significant issues related to its implementation. Many of these could be added pretty easily within the current framework without changing the event key system or redesigning the GUI at all. For example gaining and losing aggro should be pretty easy. I think it's only worth making a separate ticket if it's going to require extra thought or design work outside the current framework, or neither of us feels like implementing it right away (many tickets I've created exist as reminders) or for anything else that's significant.

From this list, I'll break them into 2 categories.

Category A: the easy ones. These events that should fit well within the current framework without a need to enhance the engine:

• Falling damage
• Drowning
• Hurt (ie, you take a huge hit)
  • if the size of the hit is hard-coded: combat event: I got hurt (>25% max health in a single hit). if the size of the hit is configurable, that would call for a framework, data structure, and/or GUI enhancement
• Block, dodge, miss, parry (most effective when used for a mob's special attack rather than just auto attack)
  • like being hurt, if the caveats of this are hard-coded, it fits in the current framework
• Crowd control events:
  • Polymorphed
  • Silenced
  • Possessed
  • Fear/Horror
• Looting cash
  • generically looting any cash fits the current framework, but configuring this in more detail would not, for example to trigger a speech only when looting more than 10g cash
  • question: is this for looting the corpse, or receiving your share? If someone else loots the boss, and I get my share of the cash, do I announce it off this trigger or not?
• Learning a new ability/recipe
• Summoning a mount or pet (as an automatically detected event)
  • The current framework supports adding new categories, which I'd like to do for this, similar to the current implementation of spell ranks mixed with the current implementation of default speeches for "/ss macro mount <category>"
• Gaining/losing aggro
• Logging out not in an inn
  • Took me a minute to figure out why only where you're not rested: because of the 20 second timer. Logging out where rested happens too fast to see your macro, so there's no point.
• Loot an item
  • see also ticket 117 for looting a fish
• Other mechanics affecting your character, as listed in http://www.wowwiki.com/Mechanic
  • that looks like the best way to implement the various forms of CC and I'd love to change my arena announcements to use those instead of the individual debuff names
• Pet died (You killed Fluffy, you bastard!
• Pet crits (Go for the eyes, Fluffy!)

These events strike me as harder and would require enhancements to the engine.

• Monster emotes (particularly "runs in fear" or "becomes enraged"
• Monster speeches (ie, Rags yells "TASTE THE FLAMES OF SULFURON" and you yell back "No thanks, spicy foods give me gas")

For both of those, I just don't want to see a flat list of every boss speech and boss emote that you want to react to, each defined as it's own event key the way each spell is listed... it calls for a better data structure design in that area.

Just a few notes and responses to a couple questions.

• Falling/Drowning damage - COMBAT_LOG_EVENT_UNFILTERED, eventtype = ENVIRONMENTAL_DAMAGE, 9th parameter = FALLING/DROWNING
  
• Hurt, block, parry, dodge, etc. - I think it should be hard coded for simplicity's sake.
  
• Crowd control events/other mechanics - Now, these are tricky. (Which makes me crazy, because it seems like they should be SO EASY. ARG.) You can search WoWHead and it'll have the "effect" box with "stunned" or "polymorphed" or whatever, but it's internal spell data that apparently can't be found in game. Here's how to get at them:
  
  • Some addons get around this by scanning the tooltip, but that means localizing each string you are looking for, and that is difficult if you don't know exactly which snippet is the right snippet. :(
    
  • You can hard code the spells that produced the effects, which would be most accurate but also uses a ton of memory.
    
  • You can assume that the user is only going to discover that s/he's crowd-controlled because s/he tries to use an ability and it subsequently fails. In this case, you look in the combat log for the SPELL_CAST_FAILED event and the 12th parameter will be the error message, as defined in GlobalVariables.lua (so you only have to reference the variable name). This last option is likely the best, but has the disadvantage that it might not be instantaneous. I think we would have to experiment in an actual combat situation to determine its effectiveness.
    
• Looting cash - Event is CHAT_MSG_MONEY. This will fire anytime you would get a "You loot" message, including when you get your share of the bosses loot, or when you open the Argent Crusade daily quest bag.
  
• Learn ability - CHAT_MSG_SYSTEM, event strings ERR_LEARN_ABILITY_S, ERR_LEARN_RECIPE_S, and ERR_LEARN_SPELL_S
  
• Pets/mounts - COMPANION_UPDATE. The problem to code around is that this not only fires when the player summons/unsummons a mount/companion, but also when anyone walks by with one of those out. The event doesn't seem to return any arguments, either, so you can easily tell who triggered it. The way I got around it was having a couple boolean variables that recorded whether the user was previously mounted/had a companion, checking to see if they did when the event fired, and then proceeding with speeches only if it was different.
  
• Gaining/losing aggro - UNIT_THREAT_SITUATION_UPDATE, then use UnitThreatSituation to find out what the aggro status is
  
• Logging out not in an inn - fires the PLAYER_CAMPING event
  

For mounts and companions, another approach could modify what we do now in templates.lua, and move that function from "/ss import" to always at load time. I got the code from Mountiful, and modified it slightly. It scans the pet/mount spellbook, and scans each tooltip to determine the class of mount (flying, fast, very fast, 310, swimming, etc). I currently use this code to generate a set of templates which you can import to map each mount summoning spell to the correct "/ss macro mount category" macro for that category of mount. Then summoning or dismissing a mount or pet is detected from UNIT_SPELLCAST_SENT.

We could move this code to generate a table of known mounts/pets at load time, and then check that table during UNIT_SPELLCAST_SENT (or succeeded) to determine whether you just cast the spell to summon whichever kind of mount, then fire an event for mounting, and/or a more specific event for mounting on a 310 flying mount, or a swimming mount, or a slow ground mount, etc.

We could cache the list in the SavedVariables and keep it updated based on whatever event fires when you learn a new mount or pet, so we don't have to do a time-consuming scan of a large mount list every time you login.

Building more on what you just said, another approach could be to set some flags to pair UNIT_SPELLCAST_SENT with COMPANION_UPDATE, see if the COMPANION_UPDATE we just got matches the last UNIT_SPELLCAST_SENT, and infer from there that the player just cast a spell that summons a companion.

Good details on the rest of this stuff... I have no further comments on the other issues at this time.

v3.3.5.10 release progress on this ticket
- releasing many new default SPEECHES from RPHelper2.
- adds Gaining/Losing aggro

Lots more on the list here before we can close this one. :)

Unassigning tickets that are not actively being worked on