I wasn't sure if I misunderstood or not, but regardless of whatever defaults you decide on, please continue to support custom extra bars. I'm one of "those people" who much prefer multiple bars :) Ideally in my mind, any button, custom or default, should be able to be assigned to any/all of the bars that exist in autobar. Thanks!
Extras would not go away. But there would be either a default of having their buttons on the main bar or some easy way to move its buttons around. Perhaps easy mass movement of buttons between bars is a better way to go. There is a ton of other stuff to write though so this is not high priority. Until I hear or come up with a compelling idea the current state is likely to be preserved.
...After I unchecked "Move the Bars" after the move...they disappeared and now only appear with that box or the "Move the Buttons" box checked.
...
All right, this sounds like while you were in Move the Bars mode you clicked on the bar, turning it red and hidden? Go back into move the bars mode and make sure it is green. I also checked in settings for hide in the Bar options in the latest version. You need to make sure it does not say hide.
... Ideally I want one button - replenish mana. It should use Mana Stones where available (cheapest!), then any location specific potions (TK ones if I'm in there, etc), then default to Super/Combat/etc, depending on what's avaiable. The button (and thus action on a single keybinding) should switch, even in combat, based on cooldowns and location... Can I do this with AutoBar?
Not at the moment. I will however be adding a "shuffle" option to buttons. Buttons with shuffle set to true will have the top button specifically use a particular bag and slot. As items get depleted the next "cheapest" / best item gets swapped into that spot. Shuffle buttons also will specifically never allow macros or spells to be set as the best item (on the base button).
Since this sounds less boring than bar movement im going to work on it today. I have almost implemented it for a couple of weeks now so today is the day!
It was red. I don't know why I didn't notice the Hide box being checked...sorry for the trouble and thanks for the help! :)
Not your fault, doing hiding like that is not an obvious UI move. I think I am going to add "Hide" to the Bar name just so there is another chance of noticing.
Not at the moment. I will however be adding a "shuffle" option to buttons. Buttons with shuffle set to true will have the top button specifically use a particular bag and slot. As items get depleted the next "cheapest" / best item gets swapped into that spot. Shuffle buttons also will specifically never allow macros or spells to be set as the best item (on the base button).
Since this sounds less boring than bar movement im going to work on it today. I have almost implemented it for a couple of weeks now so today is the day!
Sounds perfect, Toadkiller - particularly if we have some way of governing the priority...:-) Thanks!
Sounds perfect, Toadkiller - particularly if we have some way of governing the priority...:-) Thanks!
I was thinking of enabling <Ctrl|Alt|Shift>-MouseWheel for that perhaps. However that potentially implies saving off a lot of data if the category is large. Better to just have the Categories order determine it. The only real issue is if u specifically want the worst ones to be used up first. But that can be handled via a checkbox to invert the sort.
Anyone else getting a square border on pop-up buttons after they have been used? I'm using the serenity skin. I also seem to get more popped up bars staying popped up until I mouseover the main button than pre-buttonfacade.
Reading though the LibPeriodicTable-3.1-AutoBar stuff, I worry about how it will be updated. From what I understand. compresssplit.lua is used to update the split offs. (Currently the AutoBar stuff is not listed there.) If it is moved to it's AutoBar it would seem to be more likely to end up out of data with respect to LibPeriodicTable-3.1. Also the whole prefix LOD stuff might have some strange interactions with this, especially in the case that AutoBar's copy is out of date. Note that LibPeriodicTable-3.1-AutoBar calls AddData with "Consumable" even though it contains a mixature of "Tradeskill.", "Misc." and "Gear" stuff as well, hence it only checks the revision of the consumable data.
Degenerate case one. For example consider what would happen if addon A had an older version of LibPeriodicTable-3.1-Consumable embedded, addon B has a newer version of LibPeriodicTable-3.1-Gear embedded. addon C (AutoBar) has it's own LibPeriodicTable-3.1-AutoBar which is newer than A, but older then B. The gear information in addon B would be replaced by the older stuff embedded in AutoBar.
Degenerate case two. Addon A has a newer version of Consumable, AutoBar has an older version of LibPeriodicTable-3.1-AutoBar. The data table in LibPeriodicTable-3.1-AutoBar would not load because it would be checked against Consumable and found to be older. This means there wouldn't be data for any of the other sets besides Consumable.
(Edit: Removed an aside that I had here since it wasn't 100% true.)
I am totally confused Rabbit. If I do that then how does it get generated and maintained via compresssplit and changes to data.lua and runs of the miner? I have however removed it from the modules.xml file since it should not get loaded for standalone as it is only a subset of the other files.
Unfortunately the way AutoBar is right now it breaks Consumables for other addons when loaded. Since AutoBar is alphabetically before most modules AddData will see revision 73234, while the revision of LibPeriodicTable-3.1-Consumable is 72571. Given this code chunk inside of AddData
assert(type(arg2) == "string", "Invalid arg2: must be revision string")
local version = tonumber(arg2:match("(%d+)"))
if embedversions[arg1] and embedversions[arg1] >= version then
-- The loaded version is newer than this one.
return
end
LibPeriodicTable-3.1-Consumable will not be loaded it's data when embedded in other addons.
...Note that LibPeriodicTable-3.1-AutoBar calls AddData with "Consumable" even though it contains a mixature of "Tradeskill.", "Misc." and "Gear" stuff as well, hence it only checks the revision of the consumable data.
I think this part is ok. The AutoBar sets are all of consumable + some extra bits.
Quote from Nayala »
...Degenerate case one. For example consider what would happen if addon A had an older version of LibPeriodicTable-3.1-Consumable embedded, addon B has a newer version of LibPeriodicTable-3.1-Gear embedded. addon C (AutoBar) has it's own LibPeriodicTable-3.1-AutoBar which is newer than A, but older then B. The gear information in addon B would be replaced by the older stuff embedded in AutoBar.
Well there are 2 subcases.
1) AutoBar loads first and its extra sets get replaced. Absolutely no problem.
2) By some miracle another mod loads PT3 before AutoBar. This is the case described. Now this part does suck because of the replacement with old stuff.
Still, it does not seem too terrible. Update your mods and all is fine.
Quote from Nayala »
Degenerate case two. Addon A has a newer version of Consumable, AutoBar has an older version of LibPeriodicTable-3.1-AutoBar. The data table in LibPeriodicTable-3.1-AutoBar would not load because it would be checked against Consumable and found to be older. This means there wouldn't be data for any of the other sets besides Consumable.
This is totally fine. The AutoBar user will get spammed on startup with a list of missing sets and will have to make sure their mods are up to date.
So can this be made bulletproof? I think so. The adddata for consumable stays the same. The non consumable items get broken out into their regular AddData calls but with a rev # that is the first PT3.1 rev. This means they stay if there is no competition, but absolutely get replaced if there is any, no matter how old or out of date. This would only impact AutoBar users who would be required to update ALL their PT3 using mods in order to get non Consumable updates.
I am totally happy to deal with that and tell people to update their stuff. The debugging FAQ on the AutoBar site would already let them identify which mod is screwing up.
Unfortunately the way AutoBar is right now it breaks Consumables for other addons when loaded. Since AutoBar is alphabetically before most modules AddData will see revision 73234, while the revision of LibPeriodicTable-3.1-Consumable is 72571. Given this code chunk inside of AddData
...
LibPeriodicTable-3.1-Consumable will not be loaded it's data when embedded in other addons.
Ok I think I have bulletproofed this. AutoBar consumable section only is added to Consumable and is totally equivalent.
The other 3 set groups are now added to their respective file, but with an unchangeable rev number from the dawn of PT3.1. Any loading of Misc, Gear or Tradeskill will thus replace them
Autobar is currently (last svn revision) completly broken for me. It shows me only 4 Buttons for my Pally.
the 2 class buttons (Buffs/Auras)
the pala monuts (only the pala mounts no other mounts = fly mounts, pvp mounts...)
and the professions
That it, all other Buttons don't work even if i delete all saved variables. I use deDE Client. Looks like LibPeriodicTable-3.1 is not used like it should and because of that Autobar don't know that i have the items for this Buttons in my Bags.
EDIT: Now after your last change in LibPeriodicTable-3.1-AutoBar.lua i get this Spam in chat on Login/reload ui:
AutoBar: AutoBar could not find the PT3,1 set Misc.Usable.Quest. Make sure you have all the libraries AutoBar needs to function.
AutoBar: AutoBar could not find the PT3,1 set Misc.Usable.Replenished. Make sure you have all the libraries AutoBar needs to function.
AutoBar: AutoBar could not find the PT3,1 set Consumable.Warlock.Firestone. Make sure you have all the libraries AutoBar needs to function.
AutoBar: AutoBar could not find the PT3,1 set Consumable.Warlock.Soulstone. Make sure you have all the libraries AutoBar needs to function.
AutoBar: AutoBar could not find the PT3,1 set Consumable.Warlock.Spellstone. Make sure you have all the libraries AutoBar needs to function.
I use Autobar form SVN with embedded Libs = It should be all there or u have missed to add something.
I don't see how that can confuse you, you just COPY the scripts.
Either make a new library in a SVN module called LibPeriodicTable-3.1-AutoBar, or just hardcopy the stuff into your addon.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Extras would not go away. But there would be either a default of having their buttons on the main bar or some easy way to move its buttons around. Perhaps easy mass movement of buttons between bars is a better way to go. There is a ton of other stuff to write though so this is not high priority. Until I hear or come up with a compelling idea the current state is likely to be preserved.
All right, this sounds like while you were in Move the Bars mode you clicked on the bar, turning it red and hidden? Go back into move the bars mode and make sure it is green. I also checked in settings for hide in the Bar options in the latest version. You need to make sure it does not say hide.
Not at the moment. I will however be adding a "shuffle" option to buttons. Buttons with shuffle set to true will have the top button specifically use a particular bag and slot. As items get depleted the next "cheapest" / best item gets swapped into that spot. Shuffle buttons also will specifically never allow macros or spells to be set as the best item (on the base button).
Since this sounds less boring than bar movement im going to work on it today. I have almost implemented it for a couple of weeks now so today is the day!
Not your fault, doing hiding like that is not an obvious UI move. I think I am going to add "Hide" to the Bar name just so there is another chance of noticing.
Sounds perfect, Toadkiller - particularly if we have some way of governing the priority...:-) Thanks!
I was thinking of enabling <Ctrl|Alt|Shift>-MouseWheel for that perhaps. However that potentially implies saving off a lot of data if the category is large. Better to just have the Categories order determine it. The only real issue is if u specifically want the worst ones to be used up first. But that can be handled via a checkbox to invert the sort.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumReading though the LibPeriodicTable-3.1-AutoBar stuff, I worry about how it will be updated. From what I understand. compresssplit.lua is used to update the split offs. (Currently the AutoBar stuff is not listed there.) If it is moved to it's AutoBar it would seem to be more likely to end up out of data with respect to LibPeriodicTable-3.1. Also the whole prefix LOD stuff might have some strange interactions with this, especially in the case that AutoBar's copy is out of date. Note that LibPeriodicTable-3.1-AutoBar calls AddData with "Consumable" even though it contains a mixature of "Tradeskill.", "Misc." and "Gear" stuff as well, hence it only checks the revision of the consumable data.
Degenerate case one. For example consider what would happen if addon A had an older version of LibPeriodicTable-3.1-Consumable embedded, addon B has a newer version of LibPeriodicTable-3.1-Gear embedded. addon C (AutoBar) has it's own LibPeriodicTable-3.1-AutoBar which is newer than A, but older then B. The gear information in addon B would be replaced by the older stuff embedded in AutoBar.
Degenerate case two. Addon A has a newer version of Consumable, AutoBar has an older version of LibPeriodicTable-3.1-AutoBar. The data table in LibPeriodicTable-3.1-AutoBar would not load because it would be checked against Consumable and found to be older. This means there wouldn't be data for any of the other sets besides Consumable.
(Edit: Removed an aside that I had here since it wasn't 100% true.)
I am totally confused Rabbit. If I do that then how does it get generated and maintained via compresssplit and changes to data.lua and runs of the miner? I have however removed it from the modules.xml file since it should not get loaded for standalone as it is only a subset of the other files.
assert(type(arg2) == "string", "Invalid arg2: must be revision string") local version = tonumber(arg2:match("(%d+)")) if embedversions[arg1] and embedversions[arg1] >= version then -- The loaded version is newer than this one. return endLibPeriodicTable-3.1-Consumable will not be loaded it's data when embedded in other addons.
I think this part is ok. The AutoBar sets are all of consumable + some extra bits.
Well there are 2 subcases.
1) AutoBar loads first and its extra sets get replaced. Absolutely no problem.
2) By some miracle another mod loads PT3 before AutoBar. This is the case described. Now this part does suck because of the replacement with old stuff.
Still, it does not seem too terrible. Update your mods and all is fine.
This is totally fine. The AutoBar user will get spammed on startup with a list of missing sets and will have to make sure their mods are up to date.
So can this be made bulletproof? I think so. The adddata for consumable stays the same. The non consumable items get broken out into their regular AddData calls but with a rev # that is the first PT3.1 rev. This means they stay if there is no competition, but absolutely get replaced if there is any, no matter how old or out of date. This would only impact AutoBar users who would be required to update ALL their PT3 using mods in order to get non Consumable updates.
I am totally happy to deal with that and tell people to update their stuff. The debugging FAQ on the AutoBar site would already let them identify which mod is screwing up.
Ok I think I have bulletproofed this. AutoBar consumable section only is added to Consumable and is totally equivalent.
The other 3 set groups are now added to their respective file, but with an unchangeable rev number from the dawn of PT3.1. Any loading of Misc, Gear or Tradeskill will thus replace them
r73268+ of LibPeriodicTable
the 2 class buttons (Buffs/Auras)
the pala monuts (only the pala mounts no other mounts = fly mounts, pvp mounts...)
and the professions
That it, all other Buttons don't work even if i delete all saved variables. I use deDE Client. Looks like LibPeriodicTable-3.1 is not used like it should and because of that Autobar don't know that i have the items for this Buttons in my Bags.
EDIT: Now after your last change in LibPeriodicTable-3.1-AutoBar.lua i get this Spam in chat on Login/reload ui:
I use Autobar form SVN with embedded Libs = It should be all there or u have missed to add something.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI don't see how that can confuse you, you just COPY the scripts.
Either make a new library in a SVN module called LibPeriodicTable-3.1-AutoBar, or just hardcopy the stuff into your addon.