Question about AceDB-3.0

[Fox536]

Hey I was wondering. I have two sets of variables in my addon. The first set I want the user to be able to share among all his characters, via profile. The second set I don't want to be shared, and only want to be accessed from each specific character.

So could I set the variables up like this:

self.db.profile.settingIWantShared = x;
self.db.char.settingIWantPrivate = y;

And the .char table wouldn't be touched when the player chooses profiles, but all variables in the profile table would change?

[Rilgamon]

Yes, you can do this. But there are two different places where your SV can be saved. The gobal-sv folder and the char-sv folder. If your sv is very big and really only usefull for one char then you should place it in your char folder.
If you want to "reuse" it with another char you can only place it in your global folder as charfolder is only accessible from the char.

http://www.wowpedia.org/TOC_format

You can have more than one db at the same time even.
Just make sure to use the right combination in your toc.

## SavedVariablesPerCharacter: somePercharVariable
 
## SavedVariables:  foo, bar

[Phanx]

There are two ways to store per-character data:

1) Use AceDB-3.0 and the "char" namespace. This does not require a separate saved variable, or a separate database, and will store both profile and per-character data in the same file. Only the data stored in the "profile" namepsace will be affected when the user switches profiles, as the name may suggest. You would read the current profile's data through "self.db.profile.something" and the current character's data through "self.db.char.otherthing".

2) Use one saved variable for your profiles, and one per-character saved variable for your per-character data. This requires multiple saved variables, two separate AceDB-3.0 databases (or you could manage the per-character data manually), and will store profile and per-character data in separate files. You would read the current profile's data through "self.db.profile.something" and the current character's data through "self.db2.otherthing".

If you are storing a lot of data for each character, I would recommend the second method, to avoid your saved variable table growing too large. Otherwise, I would recommend the first method, since you are already using the library, and I think "self.db.profile" vs "self.db.char" is more intuitive to work with than "self.db.profile" vs "self.db2".

[Fox536]

ok, I thought that's how it would work I just wanted to make sure.

here is another question, for the per char data I need a table with 7 to 14 tables with 12 tables in each and each of those needs 3 entries. with that in mind would u suggest the first method or the second method?

[Phanx]

Originally Posted by Fox536 for the per char data I need a table with 7 to 14 tables with 12 tables in each and each of those needs 3 entries.

I would suggest reorganizing your data... that sounds pretty bad.

[Fox536]

lol, that's the best way I could find to do it, it's action button data each bar has a table, and each button has a table containing the data needed. if you have a suggestion I'm all ears.

[Phanx]

If each bar has 12 buttons, then you can just skip the per-bar table, since you know if a button's number is 1-12 it's on bar 1, 13-24 it's on bar 2, etc. You could even add a "bar" key to each button's table if you wanted to easily be able to figure that out without doing math:

local data = {
	[1] = {
		bar = 1,
		x = true,
		y = "something",
		z = 4397545,
	},
	[2] = {
		bar = 1,
		x = false,
		y = "anything",
		z = 8423125,
	},
	-- etc.
}

[Fox536]

well that just some of them, later I ll need them to be variable lengths so that wouldn't work unless I had a separate variable holding where a bar starts. it's doable but itd be horribly unreadable. Do tables eat a lot of memory or is it just more of a preferance against serveral sub-tables?

[Torhal]

Tables eat about 40 bytes per (just for an empty table). The larger issue is that the more complex your table structure, the more complex (and harder to maintain) your code will need to be. Needless complexity isn't a good thing.

[Fox536]

I see what you're saying, but to me it's not complex to have a table for each bar, and in the future when I add more bars with a more flexable user defined length with this structure, I won't have to change the code any. But thanks for the explanation as to why everyone is frowning upon it. As for doing it will it have a lasting effect on speed (with using loops to handle the multi-table crawl) or a big variable size bloat? I've almost completely finished the ui now (if I could get Wow to stop overriding my bindings, it'd be 99% done for version 1.0 lol). But if it's going to create a problem for people then I will do some code re-writing to make it more efficient.

(Lol, got it I had left some old code double creating buttons lmao, now just a few more things and it'll be done and ready for uploading.)

[Torhal]

It's always faster (and less CPU intensive) to do hash lookups on a dictionary table than to do multiple nested loops, so I would suggest a design that takes that into consideration.

[Fox536]

well hmm, that's gonna make this difficult how big a difference would it be, it only is read during loading and saving (reloadui, and logout). I might have to redo the entire load save functions it there is a big difference.

[Torhal]

You'd have to see if it "feels" slow and go from there.

[Fox536]

ok, so far it hasn't given me any trouble with speed. But I'll keep an eye out for speed issues when loading and saving.

Question do you know why AceEvent doesn't fire "PLAYER_ENTERING_WORLD" when the player enters a instance or changes Zones?

[Torhal]

That's the first I'd heard of it not intercepting that event...are you sure you're registering for it?

[Fox536]

lol ya, Im registering it, and it runs the first time but the second time, it sometimes doesn't run and when it does the :IsEnabled call returns false if you've disabled then re-enabled the addon. I don't understand what's causing it lol. But for the Beta version I just scrapped the Enable Disable Option for now until I can get it working properly, while I was doing that I found another thing I missed so I still gotta fix that before I can upload it. After that I'll upload and let others test it and give me feedback on it.

[Phanx]

1. PLAYER_ENTERING_WORLD does not fire when you change zones. It only fires after you see a login screen, so it fires when you log in, reload the UI, enter an instance, leave an instance, or change continents (eg. take a zeppelin or boat through a loading screen). If you want to detect when the player changes zones, you need to register for ZONE_CHANGED_NEW_AREA, ZONE_CHANGED, and/or ZONE_CHANGED_INDOORS. See the map events page on Wowpedia for a description of each event.

2. If you still believe you're seeing issues with AceEvent-3.0 and PLAYER_ENTERING_WORLD, try using a simple test addon with debug prints to see what's going on:

local addon = LibStub("AceAddon-3.0"):NewAddon("ToggleTestAddon", "AceEvent-3.0")
 
function addon:OnInitialize()
    print("OnInitialize")
    self:RegisterEvent("PLAYER_ENTERING_WORLD")
    -- Normally you would only register events in OnEnable, and then
    -- disable them in OnDisable, but for this test we want the event
    -- to always be registered regardless of the addon's enabled state.
end
 
function addon:OnEnable()
    print("OnEnable")
end
 
function addon:OnDisable()
    print("OnDisable")
end
 
function addon:PLAYER_ENTERING_WORLD()
    print("PLAYER_ENTERING_WORLD", self:IsEnabled() and "enabled" or "disabled")
end
 
function addon:Toggle()
    print("Toggle")
    if self:IsEnabled() then
        print("Disable")
        self:Disable()
    else
        print("Enable")
        self:Enable()
    end
end
 
SLASH_TOGGLETEST1 = "/toggletest"
SlashCmdList.TOGGLETEST = function() return addon:Toggle() end

Type "/toggletest" in-game to toggle the enabled state of the test addon. Watch for debug messages in the chat frame when the addon is loaded, enabled, or disabled; and whenever the PLAYER_ENTERING_WORLD event fires. Try zoning in and out of an instance a few times with the addon enabled, then again a few times with it disabled.

If the test addon works as expected (eg. always receives the event) then there is something wrong in your code, and you will need to post your full code if you want any further help with the problem.

If it does not work as expected, report back with a description of its behavior.

[Fox536]

huh weird, I'll test those events tomorrow after work. I thought it was supposed to be called since thats how normal frames usually work... At least I thought I'd have to go back and test it again, but I was using http://wowprogramming.com/docs/event...ENTERING_WORLD as reference, and http://www.wowwiki.com/Events/P are these both out dated, or does AceEvent not handle events the same way as normal frame?

[edit]Also Checking that site as well I see it has almost the same description about PLAYER_ENTERING_WORLD so I'll have to test some more about the event in a blank project and let you know.

[Phanx]

Originally Posted by Fox536 ... I was using http://wowprogramming.com/docs/event...ENTERING_WORLD as reference, and http://www.wowwiki.com/Events/P are these both out dated, or does AceEvent not handle events the same way as normal frame?

No, those references are not outdated, and no, AceEvent-3.0 does not magically receive different events from the game client than other event handlers. You should probably re-read the descriptions on the pages you linked, as they both say the same thing I already told you: PLAYER_ENTERING_WORLD only fires after you see a loading screen; it does not fire when you move from one zone to another (eg. from Ashenvale to Felwood).

On a side note, all of the main contributors from WoWWiki moved to Wowpedia after WoWWiki made their site horrible, so you should use Wowpedia instead.

[Fox536]

Ya no kidding about wow wiki it's horrible, but if you can sift through the massive about of useless junk it usually has what you need, but Im more fond of WowProgramming.com I'll try out WowPedia.com some more see, it's not too bad I've used it before too.

But on the Entering World thing I was just using it to catch if the loading screen was shown, since Blizzard tries to Reshown all their built-in Frames again at every loading screen for my addon it really doesn't matter if the player goes from one zone to another as long as they don't see a loading screen it didn't jack anything up.

I did see the comments in the code posted earlier about it being better to register events in OnEnable so moved some code around to better fit that.

Sorry I know yal all have a set way yal like addon's to be written with Ace but I didn't find any docs saying much on that. I mean I found http://www.wowace.com/addons/ace3/ but that's really it so I'm flying pretty dark in the whole Ace department. I've been learning what I can but it's a pretty decent size Library so It'll take a while before I know it all.

On a Side note, I'm going to post the Addon later and would love feedback. It favors a paladin player a little but any class can use it. I just don't have any special features for other classes atm, since I really don't play anything but a pally right now. Any feedback would be great once it gets accepted.