That means it can not find a Sacred Shield status to assign to corner-top-right-color. It does not break anything, so you can ignore it. On the other hand it means I need to find out how it happened so I can handle it better in the future.
I have a different question for you though. Is the point of seeing extra stuff (that you can not dispel yourself) so you have an idea of incoming damage? If so I can see a potential indicator plugin that tracks dots similar to how the the current heals-incoming works for hots etc.
It is becoming debatable though. Blizzard has made pets pretty indestructible over time. The only healing I apply to pets these days is accidental aoe via wild growth and jumping t10 rejuves. De-emphasizing them is probably a good thing. Uhm ... not it!
Shields are good because they provide a form of healing beyond the traditional direct or hot healing. I think if you want this kind of detail they need indicators that are specific to shields.
So shields should not be incorporated into health. The underlying health needs to be cured regardless. There are really just two health sizes: tanks & everyone else. Adjusting the max would just make it so you have no idea how to relate a deficit size to the heal size required to fix it for a particular character.
Some kind of bar indicator would be better I think. Or a color coded square based on shield size etc.
Another approach is to have shields show up like heals do at the moment. So if your heals show up as green or lighter colored on top of the health deficit, then perhaps shields can similarly show as an additional layer on top of both the heals and health bars.
As you say this does all depend on Blizzard providing the data needed though.
And yes, Pastamancer & Maia did a brilliant thing conceiving and implementing Grid.
...why are we still using the weird itemID/-spellID format for tradeskill data?...
Dunno. You are "the man" though. As a mod author using those you maintain them. Probably the only thing standing in the way of change would be that it is a breaking change and maybe needs a major rev?
Or if the current system is just broken it can be fixed?
...I wish they could/would bundle it into core Grid; it would save me the stress I experience every time they "break" Grid modules with code changes...
That is what Grid2 is all about. You can create and place as many icon / text / square indicators as you want and they all have the same exact functionality. Right now you can replace your current stress with the stress of setting up Grid2 from scratch when breaking changes are made to it since it is still alpha software. On the other hand, it has strong defaults that set it and its plugins up to be fully functional and icc hard mode ready from scratch.
...- is there a way to hack in icons with no cooldown spiral either into the WTF or addon files?...
Yes. I am planning to add a digital cooldown count with stack to icons similar to what text indicators have. This would add checkboxes for cooldown and stack so you could choose to have either, both or neither of them.
...deleting indictors does not give immidiate user feedback, requires rlui so that changes are seen...
I am not seeing this. I can for example delete icon-center, text-name and side-bottom and the associated icon, text and square goes away immediately. Perhaps if you can give a recipe for this starting with a freshly resetted version.
...
- i noticed that settings are not saved correctly in a lot of cases. Prioritys of statuses (on indicators) switch randomly or so it seems and sometimes a status i click "+" or "-" on will not just switch 1 up/down, but seomwhere completely else. I also had the case of creating an account wide status, but it was only available on the char i created it on. The same is the case with indicators. Account wide indicators would often be available only on the char i created them. I know it is an alpha, but this makes the GUI completely unuseable. Even in an alpha i do not want to revert to only editing WTF files with a text editor...
The +/- is an issue that needs code to ensure statuses on a particular indicator have unique priority numbers. If for instance your status has a priority of 80 along with 2 other statuses then adjusting it may make it skip over the other two depending on how they sorted to begin with.
You would have to tell me exactly what this account wide status is that only shows up on one character. Certainly some make no sense. Anything that is say buff-X-mine cannot ever show up account wide unless some other class has a buff with the exact same name which is unlikely (if not impossible).
If you create buff-X on the account layer it should show up everywhere.
If you choose a status that is only created for particular classes then it would also not show up.
If you post exactly what it is you are having problems with it can be fixed.
...Then i looked into the Grid2.lua and Grid2Options.lua WTF/settings files and began to edit only the Grid2Options.lua directly instead...
Wow, well this cannot end well unless you understand how it all works. I will explain it and later post it to the mod page.
Layers
Layers work by analogy like a shop selling layer cakes. Customers are classes or specs and at the moment get individual cakes made just for them. Everyone gets the same crust (the account settings). Classes get their own filling (the class settings). Particular specs get a particular frosting.
Particular objects can then be thought of as being a slice of this cake. You may see some frosting on top, some of the filling beneath that and some of the crust beneath that. That is, higher layers overwrite lower layers.
For instance icon-center shows raid-debuffs for everyone since that is on the account layer. You could then show dispellable debuffs on top of that particular to each class that can dispel. So all the healers, mages, and possibly hunters / warlocks via their pets. These would be on the class layer. Similarly spec specific statuses could be added on the spec layer.
Defaults
Defaults are versioned.
The first time a particular plugin or Grid2Options is loaded the version is set to zero for the particular layers it cares about.
Upgrades are then made at particular layers depending on the current version.
Upgrades can be targeted to apply only to particular layers and only take effect if objects they depend on exist. So for example if version 1 creates an indicater named "bob" and the user deletes it then when version 2 tries to add another status to "bob" it will fail because the user does not want a bob indicator.
When another character logs in the account layer is already created and will not change. If they are the same class as a previous character then the class is already created and will also not change and same for spec. If they are a class that has not logged in yet then their class and possibly default spec layers will be created. This is detected because the class and or spec layer will be 0 for that user and automatically upgraded to the latest version.
Whenever the saved layer version for a character is less than the current latest version for something an upgrade is performed which loads its options and applies the changes needed. The next time that character logs in the versions will be up to date and thus the options will not load.
Options vs Runtime Settings
Grid2 places a premium on performance.
One of the limiting factors in classic Grid is the mingling of options and runtime. In Grid2 these are strictly separated. This allows for a simple and specific runtime and arbitrarily large options. The runtime has only exactly what it requires to display indicators, statuses, etc. There is no options information in it.
For instance the runtime has localized strings for "talking" which is displayed for the voice status if it is on a text indicator. The options settings on the other hand have the description text "Voice Chat".
Similarly the runtime knows the collapsed account/class/spec settings for an object, whereas the options have these all separated out. (MIA at the moment is defaults which would also only be on the options side. This is handled by just having a lot of redundant info at the moment.)
Grid2 options modify Grid2OptionsDB (...SavedVariables/Grid2Options.lua). In addition the changes made there are collapsed and simplified and copied to Grid2DB (...SavedVariables/Grid2.lua)
This scheme means that the runtime settings are simple and exact. There are no defaults to be applied. There is no need for meta table call chains. There is just a simple lookup based on the selected class/spec setting to get the exact simple table to use for a particular object.
...Indead, i noticed that the settings done by the GUI were messed up in a lot of cases (I saw it directly, the addon was writing stuff into wrong places in the file), it's much better to edit these files directly (except for finetuning locations, colors..).
...
Grid2 reads its WTF files correctly, but edits them incorrectly when saving settings...
First a note per the mod page that this is a first cut at the layers config and "is neither complete, fully fleshed out, nor bug free". That said I am planning on hovering here doing mostly bug fixes till the layer stuff is bullet proof and fleshed out.
Now about your issues. I need reproducible recipes illustrating the issues you have. So something like "I downloaded the very latest versions, did a reset then did x, y, z and got an error / something did not work as expected".
What exactly are the settings that you see being written incorrectly? So for instance, I click on X and it doesn't save properly.
0.948330852647246
Right, no, I meant Pitbull4
0
0
I have a different question for you though. Is the point of seeing extra stuff (that you can not dispel yourself) so you have an idea of incoming damage? If so I can see a potential indicator plugin that tracks dots similar to how the the current heals-incoming works for hots etc.
0
0
Yes. I think he wants to replicate it in grid.
0
0
No, keep it in mind. As soon as Blizzard fixes the log to show shield based heals properly it can be implemented in some form.
0
So shields should not be incorporated into health. The underlying health needs to be cured regardless. There are really just two health sizes: tanks & everyone else. Adjusting the max would just make it so you have no idea how to relate a deficit size to the heal size required to fix it for a particular character.
Some kind of bar indicator would be better I think. Or a color coded square based on shield size etc.
Another approach is to have shields show up like heals do at the moment. So if your heals show up as green or lighter colored on top of the health deficit, then perhaps shields can similarly show as an additional layer on top of both the heals and health bars.
As you say this does all depend on Blizzard providing the data needed though.
And yes, Pastamancer & Maia did a brilliant thing conceiving and implementing Grid.
0
Spec switching is not implemented yet. Also, scaling and layout still use the old options system and need to be upgraded as well.
0
Dunno. You are "the man" though. As a mod author using those you maintain them. Probably the only thing standing in the way of change would be that it is a breaking change and maybe needs a major rev?
Or if the current system is just broken it can be fixed?
0
0
Releases like that are to pick up PeriodicTable changes.
This works for me. Note that pets take a while to show sometimes as it is dependent on blizzard downloading the info.
0
0
That is what Grid2 is all about. You can create and place as many icon / text / square indicators as you want and they all have the same exact functionality. Right now you can replace your current stress with the stress of setting up Grid2 from scratch when breaking changes are made to it since it is still alpha software. On the other hand, it has strong defaults that set it and its plugins up to be fully functional and icc hard mode ready from scratch.
0
Yes. I am planning to add a digital cooldown count with stack to icons similar to what text indicators have. This would add checkboxes for cooldown and stack so you could choose to have either, both or neither of them.
Looks like this got broken since i implemented it. I will take a look at it.
I am not seeing this. I can for example delete icon-center, text-name and side-bottom and the associated icon, text and square goes away immediately. Perhaps if you can give a recipe for this starting with a freshly resetted version.
The +/- is an issue that needs code to ensure statuses on a particular indicator have unique priority numbers. If for instance your status has a priority of 80 along with 2 other statuses then adjusting it may make it skip over the other two depending on how they sorted to begin with.
You would have to tell me exactly what this account wide status is that only shows up on one character. Certainly some make no sense. Anything that is say buff-X-mine cannot ever show up account wide unless some other class has a buff with the exact same name which is unlikely (if not impossible).
If you create buff-X on the account layer it should show up everywhere.
If you choose a status that is only created for particular classes then it would also not show up.
If you post exactly what it is you are having problems with it can be fixed.
Wow, well this cannot end well unless you understand how it all works. I will explain it and later post it to the mod page.
Layers
- Layers work by analogy like a shop selling layer cakes. Customers are classes or specs and at the moment get individual cakes made just for them. Everyone gets the same crust (the account settings). Classes get their own filling (the class settings). Particular specs get a particular frosting.
- Particular objects can then be thought of as being a slice of this cake. You may see some frosting on top, some of the filling beneath that and some of the crust beneath that. That is, higher layers overwrite lower layers.
- For instance icon-center shows raid-debuffs for everyone since that is on the account layer. You could then show dispellable debuffs on top of that particular to each class that can dispel. So all the healers, mages, and possibly hunters / warlocks via their pets. These would be on the class layer. Similarly spec specific statuses could be added on the spec layer.
Defaults- Defaults are versioned.
- The first time a particular plugin or Grid2Options is loaded the version is set to zero for the particular layers it cares about.
- Upgrades are then made at particular layers depending on the current version.
- Upgrades can be targeted to apply only to particular layers and only take effect if objects they depend on exist. So for example if version 1 creates an indicater named "bob" and the user deletes it then when version 2 tries to add another status to "bob" it will fail because the user does not want a bob indicator.
- When another character logs in the account layer is already created and will not change. If they are the same class as a previous character then the class is already created and will also not change and same for spec. If they are a class that has not logged in yet then their class and possibly default spec layers will be created. This is detected because the class and or spec layer will be 0 for that user and automatically upgraded to the latest version.
- Whenever the saved layer version for a character is less than the current latest version for something an upgrade is performed which loads its options and applies the changes needed. The next time that character logs in the versions will be up to date and thus the options will not load.
Options vs Runtime SettingsFirst a note per the mod page that this is a first cut at the layers config and "is neither complete, fully fleshed out, nor bug free". That said I am planning on hovering here doing mostly bug fixes till the layer stuff is bullet proof and fleshed out.
Now about your issues. I need reproducible recipes illustrating the issues you have. So something like "I downloaded the very latest versions, did a reset then did x, y, z and got an error / something did not work as expected".
What exactly are the settings that you see being written incorrectly? So for instance, I click on X and it doesn't save properly.