Authors CurseForge

Quote from myrroddin

Yes, I know people might want to block or spoof the versioning of SmartRes2, but seriously, what is the point of that? It isn't like there is mass quantities of data being sent, and it is better to be notified of upgrades.....Sure, most of the people reading these boards will check for updates regularly, but the vast, vast majority of WoW players only update addons when stuff breaks or they are told to update.

Wrong.

Push (non-buggy) full release versions to Curse (or wherever) whenever you upgrade LibResComm and/or otherwise and there will not be any "version problems". It simply isn't as much of an issue as you make it out to be.

Average people update full release versions (as opposed to alphas/betas) of mods from Curse all the time with Curse Client. And they are "notified of upgrades" all the time through that as well.

There is really no need to add mommy-notifications in the mod. If the mod can function in some/all respects as its designed to without annoying dependencies on everyone having identical versions, updating (and updating reminders) should be left to individual users and out-of-game programs like Curse Client.

If the mod doesn't functional optimally when different people have different versions running, well too bad. Redesign it not to be so dependent on what other people have. But as mentioned, push (non-buggy) release versions to Curse and the presumed "version problem" simply won't be a problem.

Speaking of non-buggy: r169 bugs out on load and has other problems. With the since-fixed r62 of LibResComm loading, errors at logon:

["message"] = "SmartRes2-r169\\SmartRes2.lua:174: attempt to call method 'OptionsTable' (a nil value)\n(tail call): ?:\n<in C code>: ?\n<string>:\"safecall Dispatcher[1]\":9: in function <[string \"safecall Dispatcher[1]\"]:5>\n(tail call): ?:\nAceAddon-3.0-10 (Ace3):514: in function `InitializeAddon'\nAceAddon-3.0-10 (Ace3):628: in function <Interface\\AddOns\\Ace3\\AceAddon-3.0\\AceAddon-3.0.lua:621>\n\n  ---",
            ["type"] = "error",
            ["session"] = 391,
            ["counter"] = 1,
        }, -- [998]
        {
            ["message"] = "SmartRes2-r169\\SmartRes2.lua:257: attempt to index field 'res_bars' (a nil value)\n(tail call): ?:\n<in C code>: ?\n<string>:\"safecall Dispatcher[1]\":9: in function <[string \"safecall Dispatcher[1]\"]:5>\n(tail call): ?:\nAceAddon-3.0-10 (Ace3):543: in function `EnableAddon'\nAceAddon-3.0-10 (Ace3):635: in function <Interface\\AddOns\\Ace3\\AceAddon-3.0\\AceAddon-3.0.lua:621>\n<in C code>: in function `LoadAddOn'\nInterface\\FrameXML\\UIParent.lua:242: in function `UIParentLoadAddOn':\nInterface\\FrameXML\\UIParent.lua:265: in function `CombatLog_LoadUI':\nInterface\\FrameXML\\UIParent.lua:519: in function <Interface\\FrameXML\\UIParent.lua:492>:\n\n  ---",
            ["type"] = "error",
            ["session"] = 391,
            ["counter"] = 1,
        }, -- [999]

And you may have embedded LibChatThrottle with your custom LibVersionCheck, but its not going to load for those that don't have it disembedded. There is no reference to it in the TOC, LibVersionCheck's lib.xml files or otherwise.

Speaking of LibChatThrottle, the fact that LibVersionCheck is aware of it and can use it means that It isn't like there is mass quantities of data being sent is not necessarily the case. It all adds up.

Quote from myrroddin

I forgot to mention in the patch notes that SetUserPlaced was changed from true to false on the res bars. That means the bar position is no longer stored in local-cache.txt and you should remove the following lines from that file:

Your numbers may be different, but you get the idea.

Found these lines in the file "layout-local.txt", not "local-cache.txt".

Quote from myrroddin

I forgot to mention in the patch notes that SetUserPlaced was changed from true to false on the res bars. That means the bar position is no longer stored in local-cache.txt and you should remove the following lines from that file:

This change has the potential to cause positioning issues for casual mod users once the latest goes to release status. If in fact the layout-local.txt data conflicts with the new saved variable data doing the same thing.

Two options: revert and keep on using layout-local.txt for bar positioning data.

Or rename the SmartRes2_ResBars positioning name to something else in the saved variables (as well as in the mod on line 235 in r175's SmartRes.lua). So it looks for the new name instead of the old.

But then you are left with unused wasted space in layout-local.txt. What advantages have you found for storing that positioning in saved variables instead of that file?

Unless I'm missing something, it appears that smart-res may be broken as of the 4.2 patch.
Also, I have a macro that looks like this.
#showtooltip Resurrection
/sr cast

I click on it and nothing happens. No target is selected and rez doesn't go off. I select a target and click and still nothing actually happens. Using the regular spell on my quick bar works fine. Am I doing something wrong? Or do you think using the word "cast" may actually interfere with other add-ons etc?