Okay, here's a sneak peak of the future of this addon (attached). You'll need to have Ace3 installed separately or embedded in another addon for this to work (forum attachment size restrictions, bah). LDB/FuBar support included.
I'd love to get some feedback on it.
I was using LibQTipClick for a while, but chickened out and reverted to LibQTip. If I can figure out how to use LQTC properly, then you'll get a secondary tooltip for each "Normal/Heroic" indicator showing the instance ID and expiry. If I can't, then I'll sort out some configurable way to squeeze that information into the main tooltip.
Also, I'll be renaming the project shortly (name still not chosen yet, /sigh). Does anyone know if there is anything more to this than:
1 - using the WowAce project settings to rename it
2 - fixing up the repository
3 - refactoring any references in the addon itself?
I'm also thinking of switching the repository over to Mercurial when I do this. Anything I should look out for? Both Mercurial and Git seem to be more fashionable than SVN now. As far as I can tell, Mercurial is basically a Python version of Git.
self.db.Class[player] = self.db.Class[player] or UnitClass("player")
self.db.Class[player] = self.db.Class[player] or select(2,UnitClass("player"))
Why is the first one bad ? Well, because it returns the localized version of the class and as a result the classcolorise function will error in non English clients because RAID_CLASS_COLORS[class] cannot be indexed properly.
In addition, you realize of course that the RaidDB.lua will also require localization since instance names differ between clients ;)
Last but not least, the Refresh method can, under certain circumstances (eg switching between locales) create duplicate table entries for instances because (yes you guessed it !) the instance name is localized :p While this isn't really an issue, just thought I should mention it.
Don't get me wrong here, I can see the potential in new implementation but in my own very very humble opinion, you are complicating things (=extra work) for very little benefit. Still I believe that no matter what, your work will be quality :D
where difficulty > 1 indicates a heroic version of said instance.
Should be fairly easy to implement a check and maybe add a "Heroic"
string next to the instance name perhaps optionally and maybe
hmm a "Normal" string for non-heroics ? I will play around with
it a bit.
You are obviously most welcome to create an implementation that supports both displays, if that's what you want, after all its your idea/addon. Feel free to use whatever code in the LDB equivalent you see fit and I will discontinue my version, if you want to go with a "unified" one.
Well, your events are fine too, you don't really have much of a choice when using LibRockEvent (or any event lib handler anyway). I try to avoid it, if possible and while I also like how easy DB libs make things, profiling wise, I don't see much of a benefit when you are writing something relatively small that will require what ? 6-7 vars tops ? I'd rather put them in a table and be done with it. Generally, I prefer simple solutions where applicable. Now, when you have a bigger and more ambitious addon then its obviously fine. But that's just me.
The DK thingie isn't a big deal, you can either replace spaces with nothing ("") in the class string or correct it with an if statement, it was just an annoyance.
And yeah I'm also looking forward to an easy and relatively bloat free lib to make the tooltip look a bit more "cool" alignment wise. I'm also anxious to see any of your new features.
As for Broker displays, I mainly use Titan (since I'm maintaining/coding the damn thing) but I also often run with Fortress or SBC, using an mcp mod to store profiles for the addons I want loaded for a specific occasion (easy switching really).
Oh and jokey I noticed some "dead" functions in the code, near the end, setting profile vars that I guess you got planned. Am I right in this assumption ? Hope I included all the necessary stuff at least :s
So, I finally got some time off today (thank God) and threw this baby together rather quickly. As promised, it's an LDB "port" that uses AceGUI3 for configuration (right-clicking on the button/block should open the config either on live or WotLK) and the regular GameTooltip (actually whatever tooltip the display addon is using since I opted for OnTooltipShow). Tested it with a "dummy" saved vars file (hope I got the proper format) and it seemed to work. Proper testing pending.
That being said, some things to note :
1. _My_ code only handles the "conversion", calculations are performed by jokey's functions.
2. The tooltip code has been heavily stripped/simplified to accomodate regular tips (non-tablet ones). We'll see how the discussion goes on the "new" tablet and what will happen eventually.
3. A bug was fixed with the Death Knight in WoW 3.0. What is the bug :
strupper(UnitClass("player")) will properly return "DEATH KNIGHT", however the table entry for the DK in RAID_CLASS_COLORS[class] shows as "DEATHKNIGHT" so we need to trim whatever unitclass returns (or otherwise implement a simple string check, I guess) to ensure proper color matching in the ClassColorise method (or else get an error most likely).
4. The "You are now saved" etc message should be properly "caught" in the LDB implementation, however I could not test this in an instance but I'm fairly positive that it works (since it works for example when using the CHAT_MSG_SAY event - a cool way to test string matching when solo :p)
5. I'll probably comment out the debug option in the lua, since it gives away a lot of spam and isn't really needed, devs can enable it at will by simply editing the file.
6. What else ? Oh yeah, I need to implement localization via AceLocale-3.0 (when I'm not lazy).
Jokey if you want to have a look, be my guest, would appreciate the feedback. Btw this is not released anywhere yet, until I can properly test it (and if you still ok with the idea since it's your original addon).
Sorry for the late reply. Thanks Tris for the suggestion. I did end up trying that and it still does nothing when that chat message appears. It's a puzzler, but it's easy to force an update (open the raid window) and it otherwise checks properly when you zone.
So yeah, my wishlist which I'll get around to at some point:
- make showing the reset time and date optional
- introduce optionally showing the time until reset (as shown in Raid Information)
- correct the reset time accuracy
- fix the "You are now saved to this instance." detection
- improve the save file, possibly ditching RockDB
It is certainly weird that the message isn't being picked up from the CHAT_MSG_SYSTEM event. It may be even worth to localize it, internally if it presents an issue. I will run my own tests when I can, I've been very busy the past couple of weeks but I still plan to have a look at this at some point. As for supporting different chars, I guess it should be doing that if it's using regular savedvars (and not per character savedvars).
In particular, I'm having trouble with the "You are now saved to this instance" detection. I've registered for the CHAT_MSG_SYSTEM event, and I'm checking it's arg to see if it is INSTANCE_SAVED (as per the GlobalStrings) but last night in Hyjal I still had to open up the raid window to force it to update. This is the one part of it's core behaviour that is missing, and I'd love to fix it but I'm not sure what else I can try. Any ideas?
Well opening the raid window forces a RequestRaidInfo OnShow, that in turn triggers an UPDATE_INSTANCE_INFO event, so that works fine (but I guess you already knew that :p). I think the problem lies with the detection method:
if tostring(arg) == "INSTANCE_SAVED" then...
Isn't this really checking for a string named "INSTANCE_SAVED", instead of the value stored in the global INSTANCE_SAVED (which should be "You are now saved to this instance" for EnUS). Try it out with a different system message, one that you can easily replicate (let's say an afk message :p). As for when I'll get around to converting this, I'm not sure yet, I'll probably keep most of the code that handles storing the instances and players in tables (since it works fine, there is no point re-inventing the wheel), I do not intend to use a DB lib though for just 4-5 saved vars :p We'll see how it goes, if and when I have a semi-decent version that I can actually test.