• 0

    posted a message on Daily Quest Viewer - Official Thread
    Sorry if it appears I'm ignoring posts here, I've been extremely busy as of late.

    I'm currently working on refactoring the localization engine to error-proof some things (currently the korean/chinese/taiwanese localizations are done incorrectly and I believe would cause errors if I were to add any more strings to the UI. I'm rewriting the localizations to make it more failproof and have fallbacks for untranslated strings).

    Next up on the plate after that is figuring out the Daily Quest reset and saving quest data between loads. The main issue here is I'd rather not break backwards compatibility in doing so, which complicates things immensely, and it's been a long while since I've been in the mood to think :P.

    To HJT: I haven't gotten a chance to put your code in yet. I received an e-mail earlier today about someone else wanting to do a German localization. I'll point him to this thread so you can argue amongst yourself over whose code to use. I'd rather you get SVN access eventually so you can directly modify the localizations yourselves rather than relying on me to merge them every time something changes, because you see how unresponsive I can be :).

    Posted in: General AddOns
  • 0

    posted a message on Daily Quest Viewer - Official Thread
    Quote from OrionShock »

    long standing bug.

    imo solution is to create a timer in your on enable to wait ~20 seconds or more to join the chat channel..

    I think I'll try this out when I get time to do so. Not sure if it will fix the problem, and can't really test it since I don't know how to reproduce it myself. Do you know if LibRockComm supports a global channel, and if so, if it experiences the same problem?

    Quote from tofagerl »

    This really needs to remember the dailies when you relog.

    This is on the to-do list. The main roadblock currently is that I don't really have a mechanism to detect when the dailies reset. What's currently implemented works because once a new daily is released and someone checks it, everyone else with the addon will be notified and the daily is "reset". So if we add memory between logons, the possibility opens for the new daily to be overwritten by the old one.

    With that said, if anyone has any ideas on when I can detect when the dailies reset, I'd love to hear them. According to WoWWiki, the Dailies reset based on Blizzard's time, and not server time. As far as I know , the only method of getting time through the WoW API will return the server time.

    The best idea I can think of is to hardcode in a list of all servers and their corresponding time zones and referencing that. That would get messy real quick (especially when dealing with DST and all), so I'd love to hear a better and elegant solution if you have one.
    Posted in: General AddOns
  • 0

    posted a message on Daily Quest Viewer - Official Thread
    Quote from Samasnier »

    Very nice!

    Suggestion: Allow DQV to be opened from the quest log. A button, or a slide-out window ala LightHeaded, or...something. Slash commands are so 1984 and should never be the only means of controlling an application (IMHO).

    There's a button on the minimap to open it.
    Posted in: General AddOns
  • 0

    posted a message on Daily Quest Viewer - Official Thread
    I figure now that things have settled down enough and this is reasonably close to stable, I can officially post this thread.

    Daily Quest Viewer (formerly known as DailyQuestTracker, before it was revealed that there was already an addon called DailyQuestTracker) is an addon that utilizes AceComm to allow people with the addon to communicate behind-the-scenes about what today's random dailies are.

    If you have the old DailyQuestTracker addon (the one installed to /DailyQuestTracker, *not* /Dailies), it is advised that you uninstall it before installing this.

    Please post bug reports and feature requests either on this page, or in DailyQuestViewer's Discussion page.

    http://www.wowace.com/wiki/DailyQuestViewer - More thorough description.
    http://files.wowace.com/DailyQuestViewer - Downloads.

    Posted in: General AddOns
  • 0

    posted a message on Renaming SVN direcories
    Quote from StormFX »

    I was just going to ask the same exact thing. >.< Thanks.

    I did the rename last night. You're going to lose alot- the updater support, as predicted, will not catch the rename and they will have to install the mod fresh instead. In addition, you're going to lose your entire zip file history on files.wowace (because the old directory will cease to exist), as well as the changelog on Fisheye.

    So it's best to catch it early and do it as soon as possible.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Renaming SVN direcories
    Quote from Funkydude »

    Only that you're going to need to do it for every file/folder individually. ;p

    I mean in terms of just renaming the addon directory and TOC itself, I just don't want to break anything on the wiki/svn/updater/files.wowace.

    I'm assuming the updater won't be able to catch the name change and work with people who downloaded using the updater before. Is there anything else I should be worried about?
    Posted in: Lua Code Discussion
  • 0

    posted a message on Renaming SVN direcories
    Nothing I should really worry about before pulling the trigger though?
    Posted in: Lua Code Discussion
  • 0

    posted a message on Renaming SVN direcories
    I'm apparently an idiot who doesn't do trivial things like "checking whether or not there's already an addon with the same name as yours". It turns out there is, and I'm working through the steps to fixing it.

    I've already replaced out all references in my code to rename the new mod. Although there's no conflicts with the directory name / TOC file, I'd still like to rename them as well. The problem is my addon is already on the SVN.

    So my question is, what, if any, adverse effects would renaming my folder on the svn from /trunk/DailyQuestTracker to /trunk/MyNewAddonNameHere, in regards to:
    - Version history
    - files.wowace.com support
    - Support for the Wowace updater and the (admittedly few) people who have already downloaded the addon
    - The wowace wiki

    and what steps would I need to take to prevent the issues from occurring or correcting them as needed?
    Posted in: Lua Code Discussion
  • 0

    posted a message on DailyQuestTracker (another one)
    Quote from Zidomo »

    Since April 27, there has been a DailyQuestTracker on the SVN as well as the Wiki.

    Somewhat different than the older, popular "Daily Quest Tracker" also out there, but not on the SVN. That one has its files and folder named as "Dailies", while its TOC title is "Dailies Quest Tracker"...heh.

    Anyway, there is a bug/problem with the DailyQuestTracker on the SVN that has persisted through the past several builds. r72690, updated standalone libraries, USEng client/server, WoW 2.4.1 live. Log on and the following error is thrown up right at logon:

    DailyQuestTracker-0.1\\DailyTracker.lua:45: attempt to index field 'profile' (a nil value)\nDailyQuestTracker-0.1\\Comm.lua:19: in function `SendCategoryRequest'\nDailyQuestTracker-0.1\\DailyTrackerFrame.lua:68: in function `DailyTrackerFrame_OnShow'\n<string>:\"*:OnShow\":1: in function <[string \"*:OnShow\"]:1>

    A single count, happens every time at every logon, regardless of resetting saved variables or anything else. May or may not affect the rest of the mod; have seen the 5 daily quest spots in the box populated properly as well as them being empty after 2 hours online (and clicking "Refresh").

    Yeah. I noticed the name issue myself a few days ago. Damn me and my lack of ability to search for something before I name it! I'll rename it soon enough, once I come up with a better name. I'm probably going to keep the "DailyQuestTracker" wiki and addon directory name for now, since I'm not sure how my renaming of the branch in the SVN will affect the updater and wiki.

    I'll take a look at that error you're getting. It's working fine on my end so it's probably an external I forgot to include.

    Edit: Aaaaaand it's fixed now. Thanks for the report.
    Posted in: General AddOns
  • 0

    posted a message on AceComm2.0 - GLOBAL and ZONE chat types not working?
    This appears to be an error with memoizations, encoding, or both. When I shortened the CommPrefix to "DQT" instead of "DAILYQUESTTRACKER", it worked properly.

    I placed the following traces in the SendMessage function:

    local drunk = distribution == "GLOBAL" or distribution == "ZONE" or distribution == "CUSTOM"
    DailyTracker:Debug("Sendmessage, prefix before encoding (".. distribution .."):", prefix);
    prefix = Encode(prefix, drunk)
    DailyTracker:Debug("Sendmessage, prefix after encoding (".. distribution .."):", prefix, "decodes to:", Decode(prefix,drunk));

    With a GLOBAL distribution type, it yielded something along the lines of:

    Sendmessage, prefix before encoding (GLOBAL): x-?
    Sendmessage, prefix after encoding (GLOBAL): y-? decodes to: ?

    With WHISPER, i got:

    Sendmessage, prefix before encoding (WHISPER): x-?
    Sendmessage, prefix after encoding (WHISPER): x-? decodes to x-?

    And with a short CommPrefix ("DQT"), i get for both global and whisper:

    Sendmessage, prefix before encoding (GLOBAL): DQT
    Sendmessage, prefix after encoding (GLOBAL): DQT decodes to DQT

    So I guess the answer is to keep your CommPrefixes short for now.

    Who (if anyone) should be notified about this for a potential fix?
    Posted in: AddOn HELP!
  • 0

    posted a message on AceComm2.0 - GLOBAL and ZONE chat types not working?
    Note that the WHISPER and GUILD types have been tested and are working properly, so I can't really see it being an issue with the CommPrefix being set improperly. It's the GLOBAL and ZONE types that I've tested that don't work, and I'm assuming CUSTOM won't work either (though I haven't tested it, my current thinking is that somewhere in AceComm the prefix isn't being sent when communicating through a chat channel.

    Modifications I made in the AceComm code for debugging purposed (I only did this after I noticed this behavior, so my modifications should not be the cause of the issue):
    - Removed the player != sender clause in the CHAT_MSG handler that prevents your client from receiving its own request
    - Added a bunch of print statements, to the CHAT_MSG handler and HandleMessage functions, as well as some of the Send functions.

    What I learned from the print statements:
    - Both the GLOBAL/ZONE and WHISPER/GUILD messages are successfully passing through the Send functions.
    - Both the GLOBAL/ZONE and WHISPER/GUILD messages are being received by the CHAT_MSG handler and both are passed into HandleMessage.
    - GLOBAL/ZONE fails at a "if not prefix" check in HandleMessage. No error is thrown, it just exits the function from there. The callback I register for GLOBAL/ZONE does not get called.
    - WHISPER/GUILD messages successfully pass through HandleMessage and my callback is successfully called.
    - When printing out the received message for a WHISPER or GUILD message, I get something like:
    Whereas when printing out a message received by GLOBAL or ZONE, I get:
    From that I can only assume that Bt- is a memoized copy of the CommPrefix, and it's not getting sent.

    Here's a direct copy of the Comm.lua from my mod. Forgive any stupid crap I do or reinventing the wheel, this is my first time with Lua:

    DailyTrackerComm = AceLibrary("AceAddon-2.0"):new("AceConsole-2.0", "AceComm-2.0")
    DailyTrackerComm.CommPrefix = "DAILYQUESTTRACKER";

    DailyTrackerComm.CommPrefix_Null = "DQT_COMMPREFIX_NULL";
    DailyTrackerComm.CommPrefix_Response = "DQT_COMMPREFIX_RESP";
    DailyTrackerComm.CommPrefix_Request = "DQT_COMMPREFIX_REQ";

    DailyTrackerComm.RequestQueue = {};

    function DailyTrackerComm:SendDailyResponse(questCategoryId, questId)
    DailyTracker:Debug( "Sending daily response:", questCategoryId, questId );
    self:SendCommMessage("ZONE", self.CommPrefix_Response, questCategoryId, questId);
    self:SendCommMessage("WHISPER", UnitName("player"), self.CommPrefix_Response, questCategoryId, questId);

    function DailyTrackerComm:SendCategoryRequest(...)
    DailyTracker:Debug( "Sending category request:", ... );
    self:SendCommMessage("ZONE", self.CommPrefix_Request, ...);
    self:SendCommMessage("WHISPER", UnitName("player"), self.CommPrefix_Request, ...);

    function DailyTrackerComm:SendRequestedCategories()
    DailyTracker:Debug( "Sending requested categories..." );
    -- our delay has expired, send any queued requests that havent been answered by someone else
    for i=1,table.getn(self.RequestQueue) do
    local quest = DailyTracker:GetCurrentQuest( self.RequestQueue[ i ] );
    if quest then
    DailyTracker:Debug( "Response found for " .. self.RequestQueue[ i ] .. ":", quest.Id );
    self:SendDailyResponse( self.RequestQueue[ i ], quest.Id );

    -- clear requests queue
    self.RequestQueue = {};

    function DailyTrackerComm:ReceiveCategoryRequest(prefix, sender, distribution, ... )
    DailyTracker:Debug("Category request received for ", ...);
    -- spin through our requests and add them to the request queue
    for i=1,select("#", ...) do
    local dailyName = select(i, ...);
    DailyTracker:Debug("Adding " .. dailyName .. " to queue...");
    table.insert( self.RequestQueue, dailyName );

    -- pull a random amount of time between 0-10 seconds for a response
    DailyTrackerTimer:Set( math.random() * 10, self.SendRequestedCategories, self );

    function DailyTrackerComm:ReceiveDailyResponse(prefix, sender, distribution, questCategoryId, questId)
    DailyTracker:Debug("Received daily response:", questCategoryId, questId );
    -- remove the category from the queue so we dont send redundant info
    local removeIndex = -1;
    for i=1,table.getn(self.RequestQueue) do
    if questCategoryId == newQueue[ i ] then
    removeIndex = i;
    if removeIndex > 0 then
    DailyTracker:Debug("Found it! Removing...");
    table.remove(self.RequestQueue, removeIndex);

    -- update our current dailies collection
    if questCategoryId and questId then
    quest = DailyTracker:GetQuest( questCategoryId, questId );
    if quest then
    DailyTracker:Debug("Associated quest found. Setting it up...", quest.Title, quest.Location);
    DailyTracker:FoundQuest( quest.Title, true );
    DailyTracker:Print( "COULD NOT FIND QUEST: ", questCategoryId, questId );

    function DailyTrackerComm:ReceiveComm(prefix, sender, distribution, localPrefix, ...)
    DailyTracker:Debug("Comm received: ", localPrefix, ...);
    if localPrefix == self.CommPrefix_Response then
    self:ReceiveDailyResponse(prefix, sender, distribution, ...);
    elseif localPrefix == self.CommPrefix_Request then
    self:ReceiveCategoryRequest(prefix, sender, distribution, ...);

    function DailyTrackerComm:OnEnable()
    self:RegisterComm(self.CommPrefix, "ZONE", "ReceiveComm");
    self:RegisterComm(self.CommPrefix, "WHISPER", "ReceiveComm");
    Posted in: AddOn HELP!
  • 0

    posted a message on AceComm2.0 - GLOBAL and ZONE chat types not working?
    Quote from Rabbit »

    MyMod.SetPrefix(self.CommPrefix) is wrong, you need to do MyMod:SetCommPrefix(self.CommPrefix)

    Yeah, the code I wrote isn't a direct copy from my mod's code (though the structure and order everything is called is the same). SetCommPrefix is called in my real code.
    Posted in: AddOn HELP!
  • 0

    posted a message on AceComm2.0 - GLOBAL and ZONE chat types not working?
    I'm working on a mod that requires use of the GLOBAL or ZONE types to send messages, but I'm finding that the receive handler isn't getting called. The WHISPER and GUILD types are working properly for me.

    I stepped through the code with some print statements in the HandleMessage function. When using GLOBAL or ZONE (and I assume custom, but haven't tested that one), the message that's received doesnt have a "XXX?" in front of it, whereas the whisper is. I'm assuming that means that the prefix isn't getting set properly when sending a message through the standard chat channels.

    Is there a fix for this? Or is it just something undocumented I'm doing wrong?

    Code example of what I'm doing (which is pretty much exactly what the tutorial says):

    MyMod.CommPrefix = "MYMOD";

    function MyMod:SendComm(message)
    self:SendCommMessage("GLOBAL", message);
    self:SendCommMessage("WHISPER", UnitName("player"), message);

    function MyMod:ReceiveComm(prefix, sender, distribution, localPrefix)
    -- processing stuff here. this gets called with the whisper distribution type but not ZONE or GLOBAL

    function MyMod:OnEnable()
    self:RegisterComm(self.CommPrefix, "GLOBAL", "ReceiveComm");
    self:RegisterComm(self.CommPrefix, "WHISPER", "ReceiveComm");

    Posted in: AddOn HELP!
  • To post a comment, please or register a new account.