M+ Tracker bug #70


Closed
  • MilkshakeMoo created this issue Jul 26, 2018

    When i am swapping to toon that already done M+ to a toon that hasn't done it, for some reason AILO also made that 2nd toon to have the same M+ as the previous one.

     

    Edit : It seems AILO also only update your highest M+ if you opened the Mythic Dungeon UI. 

    Edit 2 : Latest update (3.0.4) kinda fix this issue if the 2nd toon already have done an Mplus, if that 2nd toon haven't done any, the M+ value still change.

     

    Here for example : 

     

    Mystrylxhave not done any M+ this week.

     

     

    Now, i will log-in to Syikalinathat have done +13 this week

     

     

    Now, i will log back in to Mystrylxthat have not done any M+

     

     

    As you can see Mystrylx, M+ value copied the previous toon that i logged in, Syikalinawhich is a +13.

     

    Now, what i noticed is that, on the Mythic Dungeon UI, when i logged back in to Mystrylyx there's a delay on which the chest changed from Golden +13 to the non-completed chest.

     

    So this issue might be caused by Blizzard UI.

  • MilkshakeMoo edited description Jul 26, 2018
  • MilkshakeMoo edited description Jul 27, 2018
  • holzbit posted a comment Jul 28, 2018

    Confirmed.

     

    What if we add C_MythicPlus.RequestRewards(); in front of the C_MythicPlus.GetWeeklyChestRewardLevel(); call?

     

    Edit in Ailo.lua:

     

    --=========================================================================--
    -- Mythic Plus Weekly Best
    --=========================================================================--

    local fChallengeModeMapsAvailable = false

    function Ailo:UpdateMythicPlus(event, ...)
    if event == "CHALLENGE_MODE_MAPS_UPDATE" then
    fChallengeModeMapsAvailable = true
    elseif not fChallengeModeMapsAvailable then
    C_MythicPlus.RequestMapInfo()
    return
    end

    --[==[ leaving old code commented out in case GetWeeklyChestRewardLevel doesn't work out
    local maps = C_ChallengeMode.GetMapTable();
    local levelMax = 0
    for i = 1, #maps do
    local _, _, level = C_ChallengeMode.GetMapPlayerStats(maps[i]);
    if (level) then
    levelMax = (levelMax > level) and levelMax or level
    end
    end
    --]==]
    -- GetWeeklyChestRewardLevel returns level, rewardLevel, nextRewardLevel
    C_MythicPlus.RequestRewards();
    local levelMax = C_MythicPlus.GetWeeklyChestRewardLevel();

    if levelMax > 0 then
    self.db.global.weeklies[strformat(strfDBKey, "MythicPlus")] = { count = levelMax, max = 15 }
    end
    end


    Edited Jul 28, 2018
  • holzbit posted a comment Aug 7, 2018

    Now, what i noticed is that, on the Mythic Dungeon UI, when i logged back in to Mystrylyx there's a delay on which the chest changed from Golden +13 to the non-completed chest.

    C_MythicPlus.RequestRewards(); supposedly fixes this. With this that delay is gone. Else C_MythicPlus.GetWeeklyChestRewardLevel() still holds the values of the previously logged in char instead of reading the values of the current char. But this does not help if the current char has not done any m+ this week yet, in this case Ailo on Login still takes the values of the previous char and writes them to its db. Why?


    Edited Aug 7, 2018
  • Turducken_McNugget posted a comment Aug 8, 2018

    Holzbit I've checked in the change you suggested. But I have to ask, why didn't you try making the code change in the files on your machine to see if it worked? You said confirmed so you must have had M+ lockouts available for test data and you were sophisticated enough to find that call and where to place it. Just seems odd that you didn't give it a go ...

     

  • holzbit posted a comment Aug 9, 2018

    Oh, I indeed tried it out, and it worked for me, but that was because all my toons already did a mythic+ that week. Took another reset to try and find out that it oddly enough does not work for a toon that has not done any mythic+ this week yet.

  • MilkshakeMoo edited description Aug 10, 2018
  • MilkshakeMoo posted a comment Aug 10, 2018

    What if Ailo just "reset" the M+ value whenever you log into that toon and then "ask" for the highest M+ value using C_MythicPlus.RequestRewards() ?

  • holzbit posted a comment Aug 11, 2018

    Ok, did some more testing.

    1. When switching to another character, when Ailo:UpdateMythicPlus is called the first time (event is nil), GetWeeklyChestRewardLevel() still receives the values of the previous character, even when calling RequestRewards() first. I'm not sure where exactly this call is triggered, but as a workaround we could tell it to not update the db when event is nil?

    2. RequestRewards itself triggers CHALLENGE_MODE_MAPS_UPDATE, so we should avoid running into a loop.

    3. There's a new event MythicPlusNewWeeklyRecord (MYTHIC_PLUS_NEW_WEEKLY_RECORD), maybe this could be of some use?

     

     

    possible Workaround, still need to do more testing:

     

    function Ailo:UpdateMythicPlus(event, ...)

    if (event ~= "CHALLENGE_MODE_MAPS_UPDATE") then C_MythicPlus.RequestRewards(); end -- RequestRewards() itself triggers CHALLENGE_MODE_MAPS_UPDATE event, prevent looping

    if (event == nil) then
    self:Print("Not Updating because MythicPlus Update was called with NIL Event.. Values: levelMax = ", levelMax, " , Player = ", currentRealmChar , "Event: ", event)
    else
    local levelMax = C_MythicPlus.GetWeeklyChestRewardLevel();
    if levelMax > 0 then
    self:Print("Updating MythicPlus PlayerData with values: levelMax = ", levelMax, " , Player = ", currentRealmChar , "Event triggered was: ", event)
    self.db.global.weeklies[strformat(strfDBKey, "MythicPlus")] = { count = levelMax, max = 15 }
    end
    end

     

    end

     

     

    @edit: With the aforementioned changes it worked for me mostly last week. There was only one occation where it falsely overwrote the values, but I was not able to reproduce the circumstances.


    Edited Aug 15, 2018
  • Turducken_McNugget closed issue Sep 10, 2018
  • Turducken_McNugget posted a comment Sep 10, 2018

    Should be fixed and working correctly with build 3.0.7


To post a comment, please login or register a new account.