So I have a big set of changes I am going to check in later today. Why later today? Because I want one last chance to run through it to see if I really fixed everything I think I did.
So what has Ludovicus been up to?
- I have consolidated the guide parsers. Now every addon supports every tag!
- I have consolidated the event handlers. Now every addon behaves the same way in response to major game EVENT notifications.
- I have consolidated the step selection logic. Now every guide makes uniform decisions for determining the next step.
- I have consolidated the guide loading process. Now when a guide is loaded, it is setup the same and daily/weekly/monthly quests handled uniformly.
So those are the big structural changes. In theory they fix nothing except making it easier maintenance for us addon writing types. But it does mean that if a bug appears in the logic, there is only one place to fix it! As a result, a few bugs were accidentally fixed by making the logic uniform:
- The guides are now hidden uniformly when entering instances or pet battles.
- Dalies guides now reset automatically at load time.
- Loots are now counted accurately
- Automatic flight point autocomplete works (fingers crossed) uniformly
- Interfaces to secondary addons like TomTom and Grail now work across the board
But the single biggest change is I changed the the way the event processing logic and the guide update logic interacted. It used to be that events that changed quest status directly triggered guide next step selection. But Blizzard, for their own mysterious reasons, has decided to muck with it. I suspect that the game client is taking better advantage of multicore processors. Or maybe they are just being perverse. But I can no longer depend on the precise order of quest log updates, quest completion flagging, and quest NPC interactions. Worse yet, if I accept or turn in many quests in quick order, the events for the quests can be interleaved.
What to do? It turns out the solution was right under my nose. It is really the same problem as the quest loot counting problem. When you loot an item, you get multiple messages updating the status of your bags and scanning all your bags on every message is too expensive. So what you do is set a timer (for say 1/3 of a second) when you get one of these messages and reset the timer if you get another one while the timer is still active. Once the timer goes off (i.e. it has been over a 1/3 of a second since ant bag update messages came by) then count your loots.
Similarly, we need to aggregate all of the quest status modification events and punt on doing an update until things have settled down. Simple, n’est-ce pas?
Anyways, once I am satisfied this is not obviously broken, it will be available directly from GitHub at:
Oh yeah, and I started implementing a new feature. I call it “Why?”. If you open up the “Current Guide Listing” and mouse over the step texture, it will tell you “Why” that step is in that state. I added this because adding all the debug log prints to cover every eventuality resulted in huge logs that were difficult to understand. This gives you a nice concise answer for a given step.
re: Horde Kun-lai Summit ErrorI thought I fixed this in 2.6.0 alpha2 . What version were you running?
Re: Thats good newsI was thinking of two forms:|REP|Operation: Shieldwall;1376;revered;bonus||REP|Operation: Shieldwall;1376;revered;nobonus|So the second form would be the magic to throw on the “Buy the commendation” logic. NB: The syntax guide has been updated and the code checked into alpha as of 5/14.
Thats good newsso…as a practical matter, whats the tag to use?something like an additional argument for the REP tag?to quote from WoW-Pro Addon Syntax
|REP| – ReputationTakes a set of two required arguments and up to two optional ones. Lets take an example: |REP|Operation: Shieldwall;1376|
would become “takes a set of two required arguments and up to three optional ones
|REP|Operation: Shieldwall;1376;honored;yes|
yes could be true/false, yes/no, etc. I’m thinking not 1/0 since that might be more confusing with the +xxx part of the argument.
PS. thanks for adding the REP tag to the documentation 🙂
GetFactionInfo() and hasBonusRepGainThe API for this function changed for 5.2:name, description, standingID, barMin, barMax, barValue, atWarWith, canToggleAtWar, isHeader, isCollapsed, hasRep, isWatched, isChild, factionID, hasBonusRepGain, canBeLFGBonus = GetFactionInfo(factionIndex) So now we can detect if hasBonusRepGain is set and stop prompting people to buy stuff they don’t need!!