i think acedb3 is already to much .. e.g my chatter saved variables file contains 185 tables. The possibility to save settings by character has been dropt so all three profiles are loaded with all of my 3 characters I currently play. Authors should think about how to save their data and not just use an api and don't know how the result looks like.
i think acedb3 is already to much .. e.g my chatter saved variables file contains 185 tables. The possibility to save settings by character has been dropt so all three profiles are loaded with all of my 3 characters I currently play. Authors should think about how to save their data and not just use an api and don't know how the result looks like.
That's because of Chatter's modularized system, if an addon like Chatter has 18 submodules, then each submodule gets a subtable.
There's always good and bad points to any system used. If Chatter was just one all-in-one-file-and-in-one-big-module addon instead of 18 small module files, then you will have much much less tables in the savedvariables.
That's because of Chatter's modularized system, if an addon like Chatter has 18 submodules, then each submodule gets a subtable.
There's always good and bad points to any system used. If Chatter was just one all-in-one-file-and-in-one-big-module addon instead of 18 small module files, then you will have much much less tables in the savedvariables.
what makes it worse is that every submodule has the player - server profile mappings .. is it even possible to set different profiles to different submodules ?
I mean one table per profile and per module would be fine to store settings... 185 tables.. come on...
what makes it worse is that every submodule has the player - server profile mappings .. is it even possible to set different profiles to different submodules ?
The mapping can not be changed on submodules, however its alot easier in AceDB code to just treat every submodule DB as a "normal" DB in another table. No special treatment required
Personally, i probably wouldn't have used the AceDB namespaces for the submodules, but placed it in the chatter DB directly.
Seconding Nev's opinion here. Just because something is a module, you don't have to use the AceDB namespace APIs - not when you're the one in control of all the code!
Seconding Nev's opinion here. Just because something is a module, you don't have to use the AceDB namespace APIs - not when you're the one in control of all the code!
Seems to me that the simple act of signing in on a char creates the majority of the fluff table entries (charname = default). Maybe AceDB shouldn't create them instead.
Do you really need to put the charname=default in every modules' namespace? Cant default, be um, the default?
Yes, you really do need to remember which profile is in use by a character, even when it corresponds to the current default.
The reason is that addons can change the default mapping (Fortress just did, for instance), and we don't want people to lose their settings because of that.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
That's because of Chatter's modularized system, if an addon like Chatter has 18 submodules, then each submodule gets a subtable.
There's always good and bad points to any system used. If Chatter was just one all-in-one-file-and-in-one-big-module addon instead of 18 small module files, then you will have much much less tables in the savedvariables.
what makes it worse is that every submodule has the player - server profile mappings .. is it even possible to set different profiles to different submodules ?
I mean one table per profile and per module would be fine to store settings... 185 tables.. come on...
The mapping can not be changed on submodules, however its alot easier in AceDB code to just treat every submodule DB as a "normal" DB in another table. No special treatment required
Personally, i probably wouldn't have used the AceDB namespaces for the submodules, but placed it in the chatter DB directly.
Seems to me that the simple act of signing in on a char creates the majority of the fluff table entries (charname = default). Maybe AceDB shouldn't create them instead.
Do you really need to put the charname=default in every modules' namespace? Cant default, be um, the default?
The reason is that addons can change the default mapping (Fortress just did, for instance), and we don't want people to lose their settings because of that.