Simple Addon Manager (SAM)

Simple Addon Manager (SAM)

39.5k Downloads

complete broken in 10.2

Squimbert opened this issue Β· 18 comments

commented

title

commented

Wow, v1.26 is even more better 🀩 The addon is approaching the state of perfection…

Huge extra thanks for saving the Character-vs-All setting in the DB – and globally for all toons! (I was planning on creating a request for this, or for a flat login default to <charname> ;)

commented

I'm seeing this error

27x bad argument #1 to '?' (Usage: C_AddOns.DisableAllAddOns([character]))
[string "=[C]"]: in function `DisableAllAddOns'
[string "@SimpleAddonManager/Core.lua"]:346: in function `DisableAllAddOns'
[string "@SimpleAddonManager/Profile.lua"]:99: in function `LoadAddonsFromProfile'
[string "@SimpleAddonManager/Profile.lua"]:283: in function `OnAccept'
[string "@FrameXML/StaticPopup.lua"]:5317: in function `StaticPopup_OnClick'
[string "*StaticPopup.xml:24_OnClick"]:1: in function <[string "*StaticPopup.xml:24_OnClick"]:1>

Locals:
(*temporary) = "bad argument #1 to '?' (Usage: C_AddOns.DisableAllAddOns([character]))"
commented

This change lets you use the addon until it gets properly fixed (Core.lua, first change at line 331):

diff --git a/SimpleAddonManager/Core.lua b/SimpleAddonManager/Core.lua
--- a/SimpleAddonManager/Core.lua
+++ b/SimpleAddonManager/Core.lua
@@ -322,34 +322,34 @@
 end
 
 function frame:IsAddonInstalled(indexOrName)
 	local _, _, _, _, reason = GetAddOnInfo(indexOrName)
 	return reason ~= "MISSING"
 end
 
 function frame:EnableAddOn(indexOrName)
 	local c = frame:GetCharacter()
-	EnableAddOn(indexOrName, c)
+	EnableAddOn(indexOrName)
 end
 
 function frame:DisableAddOn(indexOrName)
 	local c = frame:GetCharacter()
-	DisableAddOn(indexOrName, c)
+	DisableAddOn(indexOrName)
 end
 
 function frame:EnableAllAddOns()
 	local c = frame:GetCharacter()
-	EnableAllAddOns(c)
+	EnableAllAddOns()
 end
 
 function frame:DisableAllAddOns()
 	local c = frame:GetCharacter()
-	DisableAllAddOns(c)
+	DisableAllAddOns()
 end
 
 local GetAddOnMetadata = C_AddOns and C_AddOns.GetAddOnMetadata or GetAddOnMetadata
 function frame:GetAddOnMetadata(addon, field)
 	return GetAddOnMetadata(addon, field)
 end
 
 -- When entering/leaving lfg, realm returns nil. Cache to avoid errors.
 local nameCache, realmCache, classColor

In short: 4Γ— remove the c argument.

This is a workaround, not a fix!

Beware of side effects, and don't do more than you need to. But at least it will allow you to load/unload your addon sets.


Edit: For another possible workaround, see the post below.

commented

Blizzard moved a bunch of AddOn related APIs to C_AddOn. I'll try to fix it by this weekend.

commented

Blizzard moved a bunch of AddOn related APIs to C_AddOn

I think that's not the issue, because they put aliases in their Deprecated_10_2_0.lua.

But it seems these Disable/EnableAddOn functions now expect a string (not a boolean): https://github.com/Gethe/wow-ui-source/compare/10.1.7..10.2.0#diff-3b13eb1f91030308f796ca6c0b172b9adcc1080a80283e55f953dee04e865783

commented

I'm pretty sure those alias only work in beta. But i'll have to test it anyway. :)

commented

They definitively work in the current live version, because I have also (still) some of the old ones in my addons.

And the modification above works also (without C_AddOns).

commented

Apparently they also inverted the parameters in some functions (character, index become index, character), and a bunch of places that expected true for all characters now expects nil. This will be FUN to fix. πŸ˜…

commented

This will be FUN to fix. πŸ˜…

Yes, that's what I thought too… ;)

commented

Before 10.2, I could simply have addonname: disabled only in the addons.txt for the character […]

Interesting. I noticed some weirdness already before 10.2 (started a few weeks ago): Sometimes the supposedly active addon sets of my logged out toons are messed up, i.e. it's not the same as it was when I logged out on the other toon (and it's not an addon set that corresponds to any of my SAM sets).

I still don't know what's causing this, and I didn't investigate further because I remembered seeing this somewhere in the past, maybe a year or more ago. Back then it just went away with a server restart (so – very likely – it was a Blizz bug). But maybe it's something different right now.

commented

Apparently they also inverted the parameters in some functions (character, index become index, character), and a bunch of places that expected true for all characters now expects nil. This will be FUN to fix. πŸ˜…

Is this the reason why, if I have an addon disabled on one character, I now need to put addonname: enabled into the addons.txt file for any characters I actually want it enabled on? Before 10.2, I could simply have addonname: disabled only in the addons.txt for the character I wanted the addon disabled on, while leaving it enabled for any other characters. However, as of 10.2, it seems that if addonname: enabled is missing for any characters, the addon ends up being disabled anyway if the addon is disabled for my main character.

commented

Here is a (probably) better variant of the workaround posted above. Instead of crudely applying all changes to all toons, it should respect the character dropdown menu ('All' vs '<charname>') again:

diff --git a/SimpleAddonManager/Core.lua b/SimpleAddonManager/Core.lua
--- a/SimpleAddonManager/Core.lua
+++ b/SimpleAddonManager/Core.lua
@@ -329,19 +329,23 @@
 function frame:EnableAddOn(indexOrName)
 	local c = frame:GetCharacter()
+	if type(c) ~= 'string' then c = nil end
 	EnableAddOn(indexOrName, c)
 end
 
 function frame:DisableAddOn(indexOrName)
 	local c = frame:GetCharacter()
+	if type(c) ~= 'string' then c = nil end
 	DisableAddOn(indexOrName, c)
 end
 
 function frame:EnableAllAddOns()
 	local c = frame:GetCharacter()
+	if type(c) ~= 'string' then c = nil end
 	EnableAllAddOns(c)
 end
 
 function frame:DisableAllAddOns()
 	local c = frame:GetCharacter()
+	if type(c) ~= 'string' then c = nil end
 	DisableAllAddOns(c)
 end

This is instead of the first variant posted above, not additionally.


PS:

If you want the character selection (dropdown menu) to default to the current char instead of 'All', you can do this (in addition to the above change):

Char as default (2 diffs)
diff --git a/SimpleAddonManager/Core.lua b/SimpleAddonManager/Core.lua
--- a/SimpleAddonManager/Core.lua
+++ b/SimpleAddonManager/Core.lua
@@ -208,8 +208,8 @@
 	end
 	return GetAddOnEnableState(character, nameOrIndex) > 0
 end
 
-local character = true -- name of the character, or [nil] for current character, or [true] for all characters on the realm
+local character = UnitName('player') -- name of the character, or [nil] for current character, or [true] for all characters on the realm
 function frame:GetCharacter()
 	return character
 end

and…

diff --git a/SimpleAddonManager/MainFrame.lua b/SimpleAddonManager/MainFrame.lua
--- a/SimpleAddonManager/MainFrame.lua
+++ b/SimpleAddonManager/MainFrame.lua
@@ -82,7 +82,7 @@
 
 	frame.CharacterDropDown:SetPoint("TOPLEFT", 0, -30)
 	EDDM.UIDropDownMenu_Initialize(frame.CharacterDropDown, CharacterDropDown_Initialize)
-	EDDM.UIDropDownMenu_SetSelectedValue(frame.CharacterDropDown, true)
+	EDDM.UIDropDownMenu_SetSelectedValue(frame.CharacterDropDown, UnitName('player'))
 
 	frame.CancelButton:SetPoint("BOTTOMRIGHT", -22, 4)
 	frame.CancelButton:SetSize(100, 22)

Your new default to <charname> also applies when you use SAM without having opened the GUI, i.e. via slash command / macro.

commented

means line 329, column 19

The second number in each pair is the count of lines (1st pair is before, 2nd one is after) of the whole displayed chunk of code.

For a better explanation, go here.

commented

Thanks @tflo for the detailed explanation. Point 3 is what I was actually looking for. I assumed that the example @@ -329,19 +329,23 @@ means line 329, column 19 but just wanted to confirm, which you did.

commented

Can someone help out with some guides on how to apply these diff results? Is there some tool that can do this if I save the output (minus the line that starts with diff --git ...) so that the changes can be applied programmatically? I am not used to working with diff outputs or diff/patch files.

commented

how to apply these diff results?

Manually:

  1. First, use a text editor (e.g. Notepad++ on Windows, BBEdit on Mac) to edit files, ideally one that displays the line numbers. Do not use a word processor (like MS Word etc.).

  2. At the top of each diff you see the file name and path, e.g. SimpleAddonManager/Core.lua. That's the file you have to edit (inside the addon folder in your active WoW AddOns directory).

  3. The "@" numbers (e.g. @@ -329,19 +329,23 @@) show you the line where the diff starts (line 329 in the example). Go there. You should now see the code part that is displayed in the diff. (The actual diff code starts after the "@@" line.)

  4. Now simply remove all red lines (also marked with a minus "-" sign) and add the green lines ("+" sign). Of course, do not add the "+" signs themselves to your code.

    • If there aren't red lines (like in the 2nd version of the workaround), just add the green lines.
    • Correct indentation is not crucial, line breaks are crucial.
    • If you clearly see that there is only one little thing changed in the line (e.g. removal of the c argument in the 1st workaround), you can of course just apply these changes granularly, without copying the line.
    • Lines that are neither red nor green must be left unchanged. They are only displayed to give you context, to make it easier to visually locate the code.
  5. Visually compare your code against the diff to check if you have implemented all changes, and save the file with the same extension it had before (for WoW addons usually lua, xml, or toc).

To do it programmatically, you have to use any program that can apply "patch files" to another file. But I think it's not worth it here, as the changes are minuscule (in the time where you copy the diffs, save them as patch file on disk, and open them with the patch program, you have already applied the changes manually). And I'm not sure if the diffs as I have posted them are strictly patch-compatible.

The proper way to post such things would be as a pull request (you could then download it to your local clone of the repo). I didn't do that because the changes are meant to be temporary workarounds until the author has time to fix it. To fix it properly, you would do it differently, and that would be more changes spread over more files.

commented

Should be fixed by 3635d9a. (releases/v1.23)

commented

Thank you!

And with addon icons now 😍