Thank you for the fix, it seems to be working fine now.
However I still cannot figure out the bug I am having with Lifebloom. Default, Lifebloom is set to be a simple square at the bottom left that changes color depending on stack size, which is fine and works.
However I want Lifebloom to be a countdown (like Rejuv and Regrowth) that also changes color on stack size while retaining the count down timer.
I have this set up and it works perfectly, except every time I reload my UI or relog, the box "Show Duration" is unchecked under my Lifebloom indicator. Once I open the options and re-check this, it works perfectly again.
But for whatever reason, Grid2 will not remember that setting no matter what I do, I've tried clearing my saved variables and have even tried various versions of Grid2 but they all do the same thing.
Its just a small annoyance that every time I log into the game I have to open the Grid2 config and check that box, or I don't see my Lifebloom durations when I start raiding.
What if we change it to dump db.profile etc. and for a particular character there is just a pointer to a setup to use (or multiple pointers to particular subsets so common things possibly get shared). The setup contains 1 table per object and the table is the actual data used by the object at runtime. So initializing is just passing the table in and saving a reference to it and doing whatever based on it.
One thing that bugs me in your proposal is that the SavedVariables do not support "pointers" at all, so you'd end up doing a lot of thing like:
local value = Grid2.db.global.moduleDefaults["LowMana"][Grid2.db.profile.moduleSetup["LowMana"]].color1
Which looks really complex for little benefit. It also has a lot of implications on how to handle per char specific change for par of a module's db. (i.e. I want my warlock's LowMana color to be different than the LowMana color of other classes I play).
In my opinion, a setup, once created, should not be automatically modified. There are several reasons for this, the major one being that changes made by the user may get overwritten, which is confusing. We may offer an easy way to reset a setup to the default, in a way similar to how the "Reset" button function now, but limited to the setup.
By keeping a simple structure, with parts deeply copied from "defaults", we allow the user to have complete control over the structure, for each copy of this structure, and with an explicit moment where this structure is modified.
We still may notify the user that his setup may need to be reset.
Attached to this message is a patch that I want to commit at some point. This patch removes the "setup" creation from Grid2 core and put it in Grid2Options.
Just to be clear on one point. Currently if you add a new plugin, then the plugin creates reasonable defaults for itself on first startup. With other words, if I get Grid2StatusAuraGroup, then the first time I use it, it sets up all the relevant default indicators and statuses that it provides.
With other words, unlike Grid where you get a plugin and nothing at all happens, in Grid2 you get a plugin and it just works. You may need to alter it to taste if you don't like the defaults, but it does work.
You are ok with this automatic setup right?
If you are, then the next question becomes: if a plugin changes something such as adding a new status, should it similarly create a default use for it?
I think it should because that way someone using the default Grid2 setup will always have an up to date Grid2 and not have to monkey around with it. they can rely on Grid2 to provide them with what they need without manual intervention. For instance, if Blizz adds a new heal spell that needs a tracking status, updating Grid2 and its plugins should just automatically add it.
Notifying the user that their setup may need a reset is lame in comparison. Additionally Reset changes everything they did vs simply moving this one new change to where they want it.
Edit: As a rule, any "not Grid2/Grid2OPtions" addon may do whatever it wants with the setup or Grid2. Being an optional addition to Grid2, it can provide anything it wants, including automatic update, enforcing some settings, or whatever. I only care about the core part of Grid2.
If you are, then the next question becomes: if a plugin changes something such as adding a new status, should it similarly create a default use for it?
Probably, yes. Care should be taken that the indicator you'll want to attach to exists.
For instance, if Blizz adds a new heal spell that needs a tracking status, updating Grid2 and its plugins should just automatically add it.
Notifying the user that their setup may need a reset is lame in comparison. Additionally Reset changes everything they did vs simply moving this one new change to where they want it.
I'm more partial here. You should distinguish between the moment the new update has been made and the fact that the user chose to remove the specific feature. That's why I'd prefer a notification of new features that might require a reset than updating automatically.
I understand the idea of automatically pushing new features to the user, which, in the case of Grid2, most probably means changing their setup, but it should be done carefully so as not to force changes on users.
You say "vs simply moving this one new change to where they want it", and I agree that it sounds like a good idea, but there are problems with this approach. First is where they want it. How can you tell exactly ? Why offer them configuration if you decide for them where they want it ? How do you handle the next update after someone has chosen not to show your feature or to show it somewhere else ? As long as the "automatic update" process is not able to correctly handle all this, I'm confident that we are better off not automatically updating setup at all, and offer a lame, yes, but consistent, manual reset that does what the user expects.
One thing that bugs me in your proposal is that the SavedVariables do not support "pointers" at all, so you'd end up doing a lot of thing like:...
Yeah I was not being clear. What I had in mind was more like having each object have table with its config. All these tables are tossed together inside the config with matching keys. On startup, one simply loads a table containing a characters indexes into that table and pass the table in to the object for config.
The setup code to use this is almost identical with the exception that the actual config the object uses is passed in. So for the lowmana example:
function LowMana:Init(db)
self.db = db
end
function LowMana:IsActive(unit)
return (UnitPowerType(unit) == 0) and (Mana:GetPercent(unit) < self.db.threshold)
end
So on startup, you look at the current config to use. (The available ones are listed so UI can be provided to switch between them).
In this case it is "druid-resto" so we initialize based on that. LowMana gets initialized with the table containing threshold and color1. Similarly indicator inits would change to something like:
function Grid2:CreateIconIndicator(indicatorKey, db)
The actual config would have one more level of nesting to separate out the various types as we do now, or we can add a type field and dispatch off that.
...I understand the idea of automatically pushing new features to the user, which, in the case of Grid2, most probably means changing their setup, but it should be done carefully so as not to force changes on users...
Ok good, I think we are on the same page. I am thinking of only automatically adding limited types of changes. So for instance in the case of a new hot for druids it would work something like the following pseudo code:
1) Grid2 or plugin config version changed.
2) So load up the config and call the upgrade function with (config, oldVersion)
3) The upgrade function adds the various things that need adding between oldVersion and currentVersion and then updates the config so this doesnt happen next login.
4) Care is taken to check for the existence of default anciliary objects. So for instance lets say that the old defaults created a default indicator with a specific name and location and then added some statuses to it, lets say "side-left". During this upgrade the status "buff-StormCrow" is added to "side-left" as well. However, it is only added if that indicator still exists (ie was not deleted or renamed by the user).
This means that whatever was done with the existing statuses / indicators at the time of the upgrade is not affected. Also, if the user changed anything drastic with the defaults this is built on nothing bad happens. User deleted stuff is never "resurrected" in this way.
One final note: I view defaults as being the most basic config. Done right, it should let the mod "just work" right out of the box with no or minimal adjustment from most users (or at least some users).
...I still cannot figure out the bug I am having with Lifebloom...
The fix for the bug is the conversation Jerry and I are having right now on transitioning the config. It is a bit of work and needs some design decisions before we do it.
A possible workaround for your problem would be to make your own text indicator to replace the dafault one? It would not have a default config which overwrites the duration part each time you log. Just name it something different.
A possible workaround for your problem would be to make your own text indicator to replace the dafault one? It would not have a default config which overwrites the duration part each time you log. Just name it something different.
I tried this but still anything to do with Lifebloom the "Show Duration" box will always be unchecked on a reloadui.
I created a new status named "Bloom" and even tried "Lifebloom2" but they both do the same thing, the show duration box won't stay checked..even when I disable the default indicator for Lifebloom.
I can live with Lifebloom just showing a square though that changes color per stack size. I would prefer it be a countdown like the other HoTs, but I'm in no hurry for a fix.
...I would prefer it be a countdown like the other HoTs, but I'm in no hurry for a fix.
You can get a countdown for it by just using the default setup... LifeBloom is in the to left corner by default and all 3 hots have digital counters. Not sure, but you could probably install OmniCC and use an icon indicator. That should give you the same result.
You can get a countdown for it by just using the default setup... LifeBloom is in the to left corner by default and all 3 hots have digital counters.
Right, and this works fine, except for some reason I have to manually open the config every time I reloadui and toggle "show duration" under the default Lifebloom indicator. Thats the bug I have, it won't remember that one and only setting, but once I check "show duration" it does work fine, its just a small annoyance that every time I log into the game I have to open the config and check that box :p
I can't seem to get a seperate profile created per character. This I could fix by or
1. Editting the toc to save per char.
2. Editting the SV to reflect various profiles.
So what am I missing?
I can solve it manually here though.
1. Create profile for char1.
2. Log out and exit wow.
3. Go into the SV, name the profile char1 (every instance of course).
4. Fire up wow and log into char2.
5. Set up + log out + exit + rename game.
6. Repeat for other chars.
Then it does work fine. In short : For every char, the profile "profile" is used, not a custom name.
...for some reason I have to manually open the config every time I reloadui and toggle "show duration" under the default Lifebloom indicator...
Stop toggling stuff and use the options/Debugging/Reset button. After your ui reloads, the default indicator for lifebloom (corner-top-left) already has show duration enabled. That is it period.
Ok, so the patch is in. The only drawback so far seems to be the weirdness with the range status.
I have a partial implementation on the front end of this using locations. I need to work through the options editing side. The following is roughly what Grid2DB will look like:
Grid2DB = {
["profile-current"] = {
["Toadkiller - Proudmoore"] = "druid-restoration",
},
["profile-available"] = {
["Toadkiller - Proudmoore"] = {"druid-restoration" = "druidin-wiederherstellung", "druid-feral" = "druidin-wilder"},
},
["profile-setup"] = {
["druid-restoration"] = {
-- statuses to instantiate
["statuses"] = {
"lowmana/account",
"buff-WildGrowth-mine/druid",
},
-- indicators to instantiate
["indicators"] = {
"corner-top-right/account",
},
-- map statuses to their indicator with priorities
["status-map"] = {
["corner-top-right/account"] = {"lowmana/account" = 99, "buff-WildGrowth-mine/druid" = 89, ...},
...
},
},
},
-- allows new plugin versions to load their options for upgrades (if required)
["versions"] = {
"Grid2StatusRes" = 1,
"Grid2StatusGroup" = 3,
"Grid2StatusTargetIcon" = 1,
},
["objects"] = {
["center-bottom/account"] = {
["relIndicator"] = "center",
["relPoint"] = "CENTER",
["point"] = "TOP",
["x"] = 0,
["y"] = -4,
["name"] = "center-bottom",
},
["lowmana/account"] = {
type = "lowmana",
threshold = 0.25,
color1 = { r = 0, g = 0, b = 1, a = 1 },
},
["lowmana/druid"] = {
type = "lowmana",
threshold = 0.25,
color1 = { r = 0, g = 0, b = 1, a = 1 },
},
["group-GiftOfTheWild/druid"] = {
type = "group",
threshold = 0.25,
color1 = { r = 0, g = 0, b = 1, a = 1 },
},
["buff-WildGrowth-mine/druid-restoration"] = {
type = "buff",
threshold = 0.25,
color1 = { r = 0, g = 0, b = 1, a = 1 },
},
["corner-top-right/account"] = {
type = "square",
location = "corner-top-right",
level = 7,
cornerSize = 5,
},
["layout/large"] = {
type = "layout",
horizontal = true,
clamp = true,
FrameLock = false,
ClickThrough = false,
...
},
},
}
The keys in ["objects"] are scopeKeys: <objectKey/<scope>.
Grid2OptionsDB is identical except for:
1) versioning:
*Grid2DB versions answers the question "Did a plugin change in such a way that its config needs loading to update the defaults?".
*Grid2OptionsDB versions answer the question: "Has a particular object been defaulted before?". If not then set it up to its default state (if possible). If yes, then do nothing. This preserves whatever the user did with the default (accepted default, deleted or moved / changed in whatever way).
2) objects:
Grid2DB objects are the flattened version of their hierarchy / parents.
Grid2OptionsDB objects only contain the settings for their scope.
So the Grid2DB object is created by combining its Grid2OptionsDB components.
The type field allows for dispatching or matching with particular types. So "corner-top-right/account" gets dispatched to Grid2:CreateSquareIndicator("corner-top-right", db).
Two last things I am thinking about is how to handle non-hierarchic options and global settings. So for instance, lets say "raid-leader" settings. These would add for instance "master-looter", "raid-leader", "raid-assistant" statuses as well as mana level checking and busy eating/drinking statuses and the ready checks.
One option is to extend the scope key with say an "&" to denote multiple inheritance of this kind. So "text-down/druid&raid-leader". So the collapsed version of that would be the collapsed druid level settings with the collapsed raid-leader settings layered on top of that.
Some objects like layout could perhaps not have hierarchies, but simply choices: so "large", "small".
For global settings, I am thinking there could be a list of particular attributes like "cornerSize" from the square indicator that live in an object simply called "globals". There would need to be code that during the flattening process notices that a square indicator does not have a "cornerSize" and thus uses the one in globals. Perhaps a type specific function ApplyGlobals() that is implemented for object types that need it. Not sure the config ease of this is worth the extra code.
The first goal though would be simply to get to the point where there is a simple account, class and spec hierarchy. That would make Grid2 a releasable mod I think.
Thanks for taking the time to check the patch and apply it.
There are a few things I don't quite understand in your proposal:
What is the purpose of the "scope" part in the context of Grid2 (as opposed to Grid2Options) ? Do you plan to perform string splits and comparison in Grid2 initialisation ? (Note that you put "corner-top-right" and not "corner-top-right/account" as a key to status-map).
What is the purpose of "profile-available" ? Why does it needs to be in Grid2DB as opposed to Grid2OptionsDB ? Isn't this list just the keys to "profile-setup" ?
Why are the version numbers of modules saved in each profile instead of globally ?
...What is the purpose of the "scope" part in the context of Grid2...string splits and comparison in Grid2 initialisation...
In Grid2DB my first thought was to have a separate setup for each character and or spec. That leads to massive duplication though as many things are likely to be similar. So it is really just a way of reducing that at the cost of one table lookup per object.
I did at first think about string splits etc, but really the keys are not shown at all on the Grid2 side so there is no need for that. (Updating the previous post)
...What is the purpose of "profile-available" ? Why does it needs to be in Grid2DB as opposed to Grid2OptionsDB ? Isn't this list just the keys to "profile-setup" ?...
The idea is to allow spec switching between different setups without having to load options. For instance my druid switches between feral and resto a lot. Usually multiple times per login. So in Grid2DB there would potentially be 2 sets of options per character to support this. I think this means the "profile-available" keys + their UI strings need to be in Grid2DB so they can be displayed in a menu or made available to third party mods like Set Theory etc.
This raises two questions:
1) Is it useful and do people want different layouts for different specs. I think the answer is yes. In Bear or Cat form, Grid2 is taking up too much space to show me stuff I do not even have the mana for.
2) Can the indicators be redone to support this on the Grid2 side without a reload? I think in theory yes.
The tricky part would be an indicator that is a square in one layout that has to morph to text or icon in another. The scopeKey would be different which means one basically gets disabled. So it could work by removing all statuses from such a "disabled" indicator. Switching back to the spec reverses the process. For unique things like "lowmana", if there is a different scopeKey, the type field still dispatches to it and it simply updates based on its new ["objects"].<db>
On second thought, moved versions out to top level. They can always add scope if they are more specific than that and upgrades get done only per character.
In my opinion, lifebloom would be a special case in that it needs two indicators - one for how many stacks are up, and another for its duration. I don't know if that should be a default setting for the sake of cleanliness or not, but as a druid myself I definitely have one indicator setup for each as managing both of these aspects of lifebloom is critical.
Perhaps it wouldn't hurt to have one lifebloom duration and one lifebloom stack as default, but only setup an indicator for one as default.
In my opinion, lifebloom ... needs two indicators...
I am not sure what you are replying to here. Go ahead and try Grid2. The default is a duration timer for time left with color coding for the stacks. This is just one of many ways to do it.
If you absolutely want to have two different indicators you can certainly add another one for the number of stacks. Both with or without color. You can even have an indicator start blinking when its duration is about to expire.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
However I still cannot figure out the bug I am having with Lifebloom. Default, Lifebloom is set to be a simple square at the bottom left that changes color depending on stack size, which is fine and works.
However I want Lifebloom to be a countdown (like Rejuv and Regrowth) that also changes color on stack size while retaining the count down timer.
I have this set up and it works perfectly, except every time I reload my UI or relog, the box "Show Duration" is unchecked under my Lifebloom indicator. Once I open the options and re-check this, it works perfectly again.
But for whatever reason, Grid2 will not remember that setting no matter what I do, I've tried clearing my saved variables and have even tried various versions of Grid2 but they all do the same thing.
Its just a small annoyance that every time I log into the game I have to open the Grid2 config and check that box, or I don't see my Lifebloom durations when I start raiding.
One thing that bugs me in your proposal is that the SavedVariables do not support "pointers" at all, so you'd end up doing a lot of thing like:
Which looks really complex for little benefit. It also has a lot of implications on how to handle per char specific change for par of a module's db. (i.e. I want my warlock's LowMana color to be different than the LowMana color of other classes I play).
In my opinion, a setup, once created, should not be automatically modified. There are several reasons for this, the major one being that changes made by the user may get overwritten, which is confusing. We may offer an easy way to reset a setup to the default, in a way similar to how the "Reset" button function now, but limited to the setup.
By keeping a simple structure, with parts deeply copied from "defaults", we allow the user to have complete control over the structure, for each copy of this structure, and with an explicit moment where this structure is modified.
We still may notify the user that his setup may need to be reset.
Attached to this message is a patch that I want to commit at some point. This patch removes the "setup" creation from Grid2 core and put it in Grid2Options.
With other words, unlike Grid where you get a plugin and nothing at all happens, in Grid2 you get a plugin and it just works. You may need to alter it to taste if you don't like the defaults, but it does work.
You are ok with this automatic setup right?
If you are, then the next question becomes: if a plugin changes something such as adding a new status, should it similarly create a default use for it?
I think it should because that way someone using the default Grid2 setup will always have an up to date Grid2 and not have to monkey around with it. they can rely on Grid2 to provide them with what they need without manual intervention. For instance, if Blizz adds a new heal spell that needs a tracking status, updating Grid2 and its plugins should just automatically add it.
Notifying the user that their setup may need a reset is lame in comparison. Additionally Reset changes everything they did vs simply moving this one new change to where they want it.
Yes.
Edit: As a rule, any "not Grid2/Grid2OPtions" addon may do whatever it wants with the setup or Grid2. Being an optional addition to Grid2, it can provide anything it wants, including automatic update, enforcing some settings, or whatever. I only care about the core part of Grid2.
Probably, yes. Care should be taken that the indicator you'll want to attach to exists.
I'm more partial here. You should distinguish between the moment the new update has been made and the fact that the user chose to remove the specific feature. That's why I'd prefer a notification of new features that might require a reset than updating automatically.
I understand the idea of automatically pushing new features to the user, which, in the case of Grid2, most probably means changing their setup, but it should be done carefully so as not to force changes on users.
You say "vs simply moving this one new change to where they want it", and I agree that it sounds like a good idea, but there are problems with this approach. First is where they want it. How can you tell exactly ? Why offer them configuration if you decide for them where they want it ? How do you handle the next update after someone has chosen not to show your feature or to show it somewhere else ? As long as the "automatic update" process is not able to correctly handle all this, I'm confident that we are better off not automatically updating setup at all, and offer a lame, yes, but consistent, manual reset that does what the user expects.
Yeah I was not being clear. What I had in mind was more like having each object have table with its config. All these tables are tossed together inside the config with matching keys. On startup, one simply loads a table containing a characters indexes into that table and pass the table in to the object for config.
So Grid2DB would look something like:
Grid2DB = { ["profiles-current"] = { ["Toadkiller - Proudmoore"] = "druid-resto", }, ["profiles-available"] = { ["Toadkiller - Proudmoore"] = "druid-resto", ["Toadkiller - Proudmoore"] = "druid-bear", ["Toadkiller - Proudmoore"] = "druid-cat", }, ["configs"] = { ["druid-resto"] = { ["statuses"] = { ["status-lowmana"] = { threshold = 0.25, color1 = { r = 0, g = 0, b = 1, a = 1 }, },... }, ["indicators"] = { ["indicator-corner-top-right"] = ... }, ["status-map"] = { ["indicator-corner-top-right"] = {"status-lowmana", "status-hots", ...}, ... }, }, },The setup code to use this is almost identical with the exception that the actual config the object uses is passed in. So for the lowmana example:
So on startup, you look at the current config to use. (The available ones are listed so UI can be provided to switch between them).
In this case it is "druid-resto" so we initialize based on that. LowMana gets initialized with the table containing threshold and color1. Similarly indicator inits would change to something like:
The actual config would have one more level of nesting to separate out the various types as we do now, or we can add a type field and dispatch off that.
Ok good, I think we are on the same page. I am thinking of only automatically adding limited types of changes. So for instance in the case of a new hot for druids it would work something like the following pseudo code:
1) Grid2 or plugin config version changed.
2) So load up the config and call the upgrade function with (config, oldVersion)
3) The upgrade function adds the various things that need adding between oldVersion and currentVersion and then updates the config so this doesnt happen next login.
4) Care is taken to check for the existence of default anciliary objects. So for instance lets say that the old defaults created a default indicator with a specific name and location and then added some statuses to it, lets say "side-left". During this upgrade the status "buff-StormCrow" is added to "side-left" as well. However, it is only added if that indicator still exists (ie was not deleted or renamed by the user).
This means that whatever was done with the existing statuses / indicators at the time of the upgrade is not affected. Also, if the user changed anything drastic with the defaults this is built on nothing bad happens. User deleted stuff is never "resurrected" in this way.
One final note: I view defaults as being the most basic config. Done right, it should let the mod "just work" right out of the box with no or minimal adjustment from most users (or at least some users).
The fix for the bug is the conversation Jerry and I are having right now on transitioning the config. It is a bit of work and needs some design decisions before we do it.
A possible workaround for your problem would be to make your own text indicator to replace the dafault one? It would not have a default config which overwrites the duration part each time you log. Just name it something different.
I tried this but still anything to do with Lifebloom the "Show Duration" box will always be unchecked on a reloadui.
I created a new status named "Bloom" and even tried "Lifebloom2" but they both do the same thing, the show duration box won't stay checked..even when I disable the default indicator for Lifebloom.
I can live with Lifebloom just showing a square though that changes color per stack size. I would prefer it be a countdown like the other HoTs, but I'm in no hurry for a fix.
You can get a countdown for it by just using the default setup... LifeBloom is in the to left corner by default and all 3 hots have digital counters. Not sure, but you could probably install OmniCC and use an icon indicator. That should give you the same result.
Right, and this works fine, except for some reason I have to manually open the config every time I reloadui and toggle "show duration" under the default Lifebloom indicator. Thats the bug I have, it won't remember that one and only setting, but once I check "show duration" it does work fine, its just a small annoyance that every time I log into the game I have to open the config and check that box :p
I've created a ticket for this as well, but decided to toss it out here.
Currently, my SV's look like this
Grid2DB = { ["namespaces"] = { ["Grid2_StatusAuraGroup"] = { ["profileKeys"] = { ["Sankha - Earthen Ring"] = "profile", ["Ynarah - Earthen Ring"] = "profile", }, ["profiles"] = { ["profile"] = { }, }, },I can't seem to get a seperate profile created per character. This I could fix by or
1. Editting the toc to save per char.
2. Editting the SV to reflect various profiles.
So what am I missing?
I can solve it manually here though.
1. Create profile for char1.
2. Log out and exit wow.
3. Go into the SV, name the profile char1 (every instance of course).
4. Fire up wow and log into char2.
5. Set up + log out + exit + rename game.
6. Repeat for other chars.
Then it does work fine. In short : For every char, the profile "profile" is used, not a custom name.
Stop toggling stuff and use the options/Debugging/Reset button. After your ui reloads, the default indicator for lifebloom (corner-top-left) already has show duration enabled. That is it period.
This is broken atm. The current discussion in this thread leads to a fix.
Ok, so the patch is in. The only drawback so far seems to be the weirdness with the range status.
I have a partial implementation on the front end of this using locations. I need to work through the options editing side. The following is roughly what Grid2DB will look like:
Grid2DB = { ["profile-current"] = { ["Toadkiller - Proudmoore"] = "druid-restoration", }, ["profile-available"] = { ["Toadkiller - Proudmoore"] = {"druid-restoration" = "druidin-wiederherstellung", "druid-feral" = "druidin-wilder"}, }, ["profile-setup"] = { ["druid-restoration"] = { -- statuses to instantiate ["statuses"] = { "lowmana/account", "buff-WildGrowth-mine/druid", }, -- indicators to instantiate ["indicators"] = { "corner-top-right/account", }, -- map statuses to their indicator with priorities ["status-map"] = { ["corner-top-right/account"] = {"lowmana/account" = 99, "buff-WildGrowth-mine/druid" = 89, ...}, ... }, }, }, -- allows new plugin versions to load their options for upgrades (if required) ["versions"] = { "Grid2StatusRes" = 1, "Grid2StatusGroup" = 3, "Grid2StatusTargetIcon" = 1, }, ["objects"] = { ["center-bottom/account"] = { ["relIndicator"] = "center", ["relPoint"] = "CENTER", ["point"] = "TOP", ["x"] = 0, ["y"] = -4, ["name"] = "center-bottom", }, ["lowmana/account"] = { type = "lowmana", threshold = 0.25, color1 = { r = 0, g = 0, b = 1, a = 1 }, }, ["lowmana/druid"] = { type = "lowmana", threshold = 0.25, color1 = { r = 0, g = 0, b = 1, a = 1 }, }, ["group-GiftOfTheWild/druid"] = { type = "group", threshold = 0.25, color1 = { r = 0, g = 0, b = 1, a = 1 }, }, ["buff-WildGrowth-mine/druid-restoration"] = { type = "buff", threshold = 0.25, color1 = { r = 0, g = 0, b = 1, a = 1 }, }, ["corner-top-right/account"] = { type = "square", location = "corner-top-right", level = 7, cornerSize = 5, }, ["layout/large"] = { type = "layout", horizontal = true, clamp = true, FrameLock = false, ClickThrough = false, ... }, }, }The keys in ["objects"] are scopeKeys: <objectKey/<scope>.
Grid2OptionsDB is identical except for:
1) versioning:
*Grid2DB versions answers the question "Did a plugin change in such a way that its config needs loading to update the defaults?".
*Grid2OptionsDB versions answer the question: "Has a particular object been defaulted before?". If not then set it up to its default state (if possible). If yes, then do nothing. This preserves whatever the user did with the default (accepted default, deleted or moved / changed in whatever way).
2) objects:
Grid2DB objects are the flattened version of their hierarchy / parents.
Grid2OptionsDB objects only contain the settings for their scope.
So the Grid2DB object is created by combining its Grid2OptionsDB components.
The type field allows for dispatching or matching with particular types. So "corner-top-right/account" gets dispatched to Grid2:CreateSquareIndicator("corner-top-right", db).
Two last things I am thinking about is how to handle non-hierarchic options and global settings. So for instance, lets say "raid-leader" settings. These would add for instance "master-looter", "raid-leader", "raid-assistant" statuses as well as mana level checking and busy eating/drinking statuses and the ready checks.
One option is to extend the scope key with say an "&" to denote multiple inheritance of this kind. So "text-down/druid&raid-leader". So the collapsed version of that would be the collapsed druid level settings with the collapsed raid-leader settings layered on top of that.
Some objects like layout could perhaps not have hierarchies, but simply choices: so "large", "small".
For global settings, I am thinking there could be a list of particular attributes like "cornerSize" from the square indicator that live in an object simply called "globals". There would need to be code that during the flattening process notices that a square indicator does not have a "cornerSize" and thus uses the one in globals. Perhaps a type specific function ApplyGlobals() that is implemented for object types that need it. Not sure the config ease of this is worth the extra code.
The first goal though would be simply to get to the point where there is a simple account, class and spec hierarchy. That would make Grid2 a releasable mod I think.
There are a few things I don't quite understand in your proposal:
What is the purpose of the "scope" part in the context of Grid2 (as opposed to Grid2Options) ? Do you plan to perform string splits and comparison in Grid2 initialisation ? (Note that you put "corner-top-right" and not "corner-top-right/account" as a key to status-map).
What is the purpose of "profile-available" ? Why does it needs to be in Grid2DB as opposed to Grid2OptionsDB ? Isn't this list just the keys to "profile-setup" ?
Why are the version numbers of modules saved in each profile instead of globally ?
In Grid2DB my first thought was to have a separate setup for each character and or spec. That leads to massive duplication though as many things are likely to be similar. So it is really just a way of reducing that at the cost of one table lookup per object.
I did at first think about string splits etc, but really the keys are not shown at all on the Grid2 side so there is no need for that. (Updating the previous post)
The idea is to allow spec switching between different setups without having to load options. For instance my druid switches between feral and resto a lot. Usually multiple times per login. So in Grid2DB there would potentially be 2 sets of options per character to support this. I think this means the "profile-available" keys + their UI strings need to be in Grid2DB so they can be displayed in a menu or made available to third party mods like Set Theory etc.
This raises two questions:
1) Is it useful and do people want different layouts for different specs. I think the answer is yes. In Bear or Cat form, Grid2 is taking up too much space to show me stuff I do not even have the mana for.
2) Can the indicators be redone to support this on the Grid2 side without a reload? I think in theory yes.
The tricky part would be an indicator that is a square in one layout that has to morph to text or icon in another. The scopeKey would be different which means one basically gets disabled. So it could work by removing all statuses from such a "disabled" indicator. Switching back to the spec reverses the process. For unique things like "lowmana", if there is a different scopeKey, the type field still dispatches to it and it simply updates based on its new ["objects"].<db>
(updated previous post with sample deDE strings.)
So the choice is between:
1) run though all characters/specs and update them
2) update just that individual.
My first thought is to save time in that case and just update the current spec. I am open to doing it either way though.
Doing it on an individual basis probably means using scope based version keys so there are no collisions higher up the hierarchy.
Doing it all at once leaves the whole db in an upgraded state which may be nicer.
Perhaps it wouldn't hurt to have one lifebloom duration and one lifebloom stack as default, but only setup an indicator for one as default.
I am not sure what you are replying to here. Go ahead and try Grid2. The default is a duration timer for time left with color coding for the stacks. This is just one of many ways to do it.
If you absolutely want to have two different indicators you can certainly add another one for the number of stacks. Both with or without color. You can even have an indicator start blinking when its duration is about to expire.