I did something similar, except instead of a patch, it just loads a pre-patched copy of AceDB-3.0 with the minor version set to something huge that will never be exceeded by a "real" copy.
!!!AceDBFix.toc
## Interface: 50001
## Notes: Fixes AceDB to default to the Default profile instead of per-character profiles.
LibStub.lua
AceDB-3.0.lua
Then drop a copy of LibStub.lua and AceDB-3.0.lua in the same folder and change the following lines in AceDB-3.0.lua by adding the green bold underlined parts.
Line 43:
local ACEDB_MAJOR, ACEDB_MINOR = "AceDB-3.0", [COLOR="Green"][B][U]9000000[/U][/B][/COLOR]22
Line 271:
if [COLOR="Green"][B][U]default == nil or[/U][/B][/COLOR] defaultProfile == true then defaultProfile = "Default" end
Edit: Don't forget LibStub. You don't need CallbackHandler in there because AceDB doesn't try to find it or use it until an addon creates a DB, and any addon using AceDB loads its own copy of CallbackHandler before loading AceDB or creating a DB.
Do you simply create a small addon that redefined the method? Does this do a global replace?
Yes and yes.
% cd Interface/AddOns
% cat AceDB3-Default/AceDB3-Default.toc
## Interface: 50001
## Title: AceDB-3.0 All Default
## Notes: Makes Ace3 profiles default to a global "Default" again.
## RequiredDeps: Ace3
## LoadWith: Ace3
main.lua
% cat AceDB3-Default/main.lua
-- Sadly, there is no way of absolutely guaranteeing that this will load before
-- other AceDB-3.0 clients. We can only hope that the users who want to make
-- this change are willing to install the standalone Ace3 lib package.
do
local acedb = LibStub("AceDB-3.0")
local realnew = acedb.New
function acedb.New (self, tbl, defaults, profile)
-- if they pass "false", they're already boned
return realnew (self, tbl, defaults, profile or true)
end
end
%
This only works because of the use of the "disembedded"
Ace3 package, combined with -nolib installs of other addons, and a dose of luck:
1) If other addons properly support -nolib packages, they will have an OptionalDep on Ace3, thus pushing it earlier in the load order.
1a) For the few ace-using addons out there whose authors refuse to support -nolib, or merely went AWOL without ever fixing their pkgmeta/TOC files, I've simply edited my local copy of their TOCs, adding the OptionalDep and commenting out the embedded ace3 libraries.
2) LoadWith is only documented to work with LoD addons. AceDB3-Default is not a LoD addon. (There was a reason for that, but now I don't recall why it is not.) Extensive in-game tracing shows me that, in practice, AceDB3-Defaut is always the 2nd ace-related addon loaded (obviously Ace3 must be first). I do not have proof that it's because of LoadWith; it could very well be simple alphabetical order among the addons along the potential "load this 2nd" dependency DAG. Somebody with access to Blizzard's loading code could know for certain; I am not that person.
A very small percentage of players out there even care about this issue; a smaller fraction of those players are willing to run disembedded libraries; an even smaller fraction of those are willing to handle (1a) when the issue comes up. So there are lots of good reasons for not even trying to, say, publish this addon and adapt it for the general use case. :-)
I keep reading that word as disembodied, conjuring these Dickensian images of ghostly script files swooping about.
I'll add that Phanx's approach is guaranteed to work in all cases. It was the same thing I did until I got tired of maintaining a patched copy by hand. So, there's your tradeoff. :-)
Edited my previous post to note that you also need a copy of LibStub in there. You don't need CallbackHandler in there because AceDB doesn't try to find it or use it until an addon creates a DB, and any addon using AceDB loads its own copy of CallbackHandler before loading AceDB or creating a DB.
Also, AceDB-3.0 has not changed at all in over a year, so there's not really any time or effort involved in "maintaining" the patched copy. :p
Here's my personal "solution" to this problem -- it is by no means flawless nor is it hassle-free, but it works for me, at least.
Rationale: I often find some addons that have weird settings that I don't like or some bugs that the authors haven't yet fixed, so I maintain a personal patch file(s) to fix all these issues. Here is an entry that I use for this particular "bug":
--- Ace3/AceDB-3.0/AceDB-3.0.lua 2012-09-04 17:14:02.000000000 -0400
+++ Ace3/AceDB-3.0/AceDB-3.0.lua 2012-09-16 18:44:09.440742500 -0400
@@ -276,13 +276,13 @@
if not sv.profileKeys then sv.profileKeys = {} end
-- Try to get the profile selected from the char db
- profileKey = sv.profileKeys[charKey] or defaultProfile or charKey
+ profileKey = sv.profileKeys[charKey] or defaultProfile or "Default"
-- save the selected profile for later
sv.profileKeys[charKey] = profileKey
else
-- Use the profile of the parents DB
- profileKey = parent.keys.profile or defaultProfile or charKey
+ profileKey = parent.keys.profile or defaultProfile or "Default"
-- clear the profileKeys in the DB, namespaces don't need to store them
sv.profileKeys = nil
I keep this as a .patch file in the AddOns directory. Then, every time I update addons, I run this short shell script afterwards:
#!/bin/sh
cd "$(dirname "${BASH_SOURCE[0]}")"
patch -N -p0 -r- <*.patch
The downside is that I have to remember to do this every time I update Ace3. :( Beats having to manually edit it myself every time though (and it's still 250% better than fixing this in-game one a brand new character).
Note: in theory, a batch file could also work if you have Patch from GnuWin32.
I still don't think the current behaviour is unreasonable. (note that I almost never use char specific settings) The real problem, imo, is the effort involved in setting the profile for all characters when installing a new addon. If you could set the profile for all your characters at once, that should definitely reduce the need for this change. I believe that there is actually a ticket up for this. Alas, it has been up for quite some time.
I think there were already a lot of reasons given why not to do that, but I just want to be blissfully ignorant
The minor version is bumped for every change to any of the libraries, its of no special meaning.
Changing the major would require every addon to be changed, its still quite unreasonable, just to make a change a few people think is better. Like I said in this thread before, AceDB-2.0 had the default like you would prefer, and instead people asked back then for it to be changed. There is never a consensus, so we're just going to stick with what we have.
I still don't think the current behaviour is unreasonable. (note that I almost never use char specific settings) The real problem, imo, is the effort involved in setting the profile for all characters when installing a new addon. If you could set the profile for all your characters at once, that should definitely reduce the need for this change. I believe that there is actually a ticket up for this. Alas, it has been up for quite some time.
Most of that is a UI issue and not a core AceDB feature (although some of the improvements will probably need new functions in AceDB to expose the information).
...its still quite unreasonable, just to make a change a few people think is better. Like I said in this thread before, AceDB-2.0 had the default like you would prefer, and instead people asked back then for it to be changed. There is never a consensus, so we're just going to stick with what we have.
Many more than a few... If anything, I believe we're more numerous than those who wanted AceDB-2.0's default profile behavior changed.
Unhappy people are always more vocal on the interwebs than those just content with how stuff works. And counting those in this thread still only comes out to a few.
In any case, its not going to change in AceDB-3.0.
The only way it may ever change is if we bump the AceDB major version, but we're not going to bump it just for that, since it requires every add on to be adjusted to use the new major (which would mean that it won't magically solve the issue for you anyway, since addons don't all switch over immediately). We need good reasons to do that, like serious incompatible API improvements, and not just a change to some default that some people prefer.
I doubt the current behavior will be changed. If, like me, you'd rather not edit your local copy of AceDB, just drop this in your addons folder and never worry about it again: https://github.com/Phanx/AceDB-DefaultMod
Well.. what we MIGHT be able to pull off is an option in the default UI (that nearly everyone uses), something along the lines of "Make ALL your characters use this profile!" - which would get unchecked as soon as an individual selection is made.
At least I _think_ it's possible, but Nev knows AceDB better than I do.
You only have 75 posts on this account... seems pretty junior. ;)
Yeah, but I log in as "mikk" on the main wowace/curseforge sites... and then I become "dpsgnome" here.
Funnily/annoyingly, "mikk" is a moderator account so he gets all the reported post spam, but I can't do squat about it since I can't actually be mikk in the forums!
Can you tell me how you did this?
Do you simply create a small addon that redefined the method? Does this do a global replace?
!!!AceDBFix.toc
Then drop a copy of LibStub.lua and AceDB-3.0.lua in the same folder and change the following lines in AceDB-3.0.lua by adding the green bold underlined parts.
Line 43:
Line 271:
Edit: Don't forget LibStub. You don't need CallbackHandler in there because AceDB doesn't try to find it or use it until an addon creates a DB, and any addon using AceDB loads its own copy of CallbackHandler before loading AceDB or creating a DB.
Yes and yes.
This only works because of the use of the "disembedded"
Ace3 package, combined with -nolib installs of other addons, and a dose of luck:
1) If other addons properly support -nolib packages, they will have an OptionalDep on Ace3, thus pushing it earlier in the load order.
1a) For the few ace-using addons out there whose authors refuse to support -nolib, or merely went AWOL without ever fixing their pkgmeta/TOC files, I've simply edited my local copy of their TOCs, adding the OptionalDep and commenting out the embedded ace3 libraries.
2) LoadWith is only documented to work with LoD addons. AceDB3-Default is not a LoD addon. (There was a reason for that, but now I don't recall why it is not.) Extensive in-game tracing shows me that, in practice, AceDB3-Defaut is always the 2nd ace-related addon loaded (obviously Ace3 must be first). I do not have proof that it's because of LoadWith; it could very well be simple alphabetical order among the addons along the potential "load this 2nd" dependency DAG. Somebody with access to Blizzard's loading code could know for certain; I am not that person.
A very small percentage of players out there even care about this issue; a smaller fraction of those players are willing to run disembedded libraries; an even smaller fraction of those are willing to handle (1a) when the issue comes up. So there are lots of good reasons for not even trying to, say, publish this addon and adapt it for the general use case. :-)
I keep reading that word as disembodied, conjuring these Dickensian images of ghostly script files swooping about.
Also, AceDB-3.0 has not changed at all in over a year, so there's not really any time or effort involved in "maintaining" the patched copy. :p
Rationale: I often find some addons that have weird settings that I don't like or some bugs that the authors haven't yet fixed, so I maintain a personal patch file(s) to fix all these issues. Here is an entry that I use for this particular "bug":
I keep this as a .patch file in the AddOns directory. Then, every time I update addons, I run this short shell script afterwards:
The downside is that I have to remember to do this every time I update Ace3. :( Beats having to manually edit it myself every time though (and it's still 250% better than fixing this in-game one a brand new character).
Note: in theory, a batch file could also work if you have Patch from GnuWin32.
See my previous post for similar solution using sed.
What about bumping the AceDB major in WoD? The minor version already is bumped for the WoD alpha/beta
http://www.wowace.com/addons/ace3/files/472-r1111/
I think there were already a lot of reasons given why not to do that, but I just want to be blissfully ignorant
http://www.wowace.com/addons/ace3/tickets/293-ace-db-expanded-profile-control/
The minor version is bumped for every change to any of the libraries, its of no special meaning.
Changing the major would require every addon to be changed, its still quite unreasonable, just to make a change a few people think is better. Like I said in this thread before, AceDB-2.0 had the default like you would prefer, and instead people asked back then for it to be changed. There is never a consensus, so we're just going to stick with what we have.
Most of that is a UI issue and not a core AceDB feature (although some of the improvements will probably need new functions in AceDB to expose the information).
Maybe we can do that.
Many more than a few... If anything, I believe we're more numerous than those who wanted AceDB-2.0's default profile behavior changed.
In any case, its not going to change in AceDB-3.0.
The only way it may ever change is if we bump the AceDB major version, but we're not going to bump it just for that, since it requires every add on to be adjusted to use the new major (which would mean that it won't magically solve the issue for you anyway, since addons don't all switch over immediately). We need good reasons to do that, like serious incompatible API improvements, and not just a change to some default that some people prefer.
https://github.com/Phanx/AceDB-DefaultMod
My apologies for yet again reviving this thread
But it would be nice if something like "Consolidate Profiles" or "Set Profile as Default" could be implemented as suggested in that ticket
At least I _think_ it's possible, but Nev knows AceDB better than I do.
You only have 75 posts on this account... seems pretty junior. ;)
Yeah, but I log in as "mikk" on the main wowace/curseforge sites... and then I become "dpsgnome" here.
Funnily/annoyingly, "mikk" is a moderator account so he gets all the reported post spam, but I can't do squat about it since I can't actually be mikk in the forums!
Mikk: http://forums.wowace.com/member.php?u=62492 - no activity after 2009 since I can't use it.