Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
I figured out what my problem was the WoWAceUpdater did not install the KeyBound library. Once I installed that it worked with no errors. When I mouse over Infinibar in the WAU it doesnt list that as a dependency though, had to look at the toc to find out what I was missing.
Thanks for your time and again I must say it's my most used addon )
ok I actually play arround with things and wanted the border (with Buttonfacade Caith-theme) to hightlight on mouseover in a light color (white) soo... Border Hightlight: [Border(IB2MouseOver and White, 0)]
dont worked, whats wrong?
And the tag
[FreeSlots()]
gives me an syntax error....
ok I actually play arround with things and wanted the border (with Buttonfacade Caith-theme) to hightlight on mouseover in a light color (white) soo... Border Hightlight: [Border(IB2MouseOver and White, 0)]
dont worked, whats wrong?
Do any of the other tag fields contain a Border command? Only one will function at a time.
And the tag
[FreeSlots()]
gives me an syntax error....
Not sure why. can you tell me what the error is?
"Fade empty" seems to fade bagbuttons too <.<
That is the way it is programmed. If you don't want your bags to fade when empty, don't enable it on the button group containing the bag buttons.
Hmm I dont find one, I post you all tags I have:
[BindKey]
[DrD:DrDColor]
[ItemCount]
[Highlight(Casting or AutoCast or BagOpen or Channeling or Equipped or (CastName:HasAura and Color(0, 0.7, 0)) or (CastName:HasAura(unit='target') and Color(0.7, 0, 0)), 0.1]
[Border(IB2MouseOver and White, 0.9)]
[Overlay(InCooldown or Unusable or OutOfMana or NotInRange, 0.25)]
For "[FreeSlots()]" there only on the little buttonfield "Syntax Error" written.
@jjsheets:
The reason for putting the pet commands in a separate macro is that Kill Command sometimes "locks up" and prevents you from using Auto Shot or pressing Esc (among other annoyances). If Kill Command is in the same macro as your shot rotation, it will also render the entire macro inoperable. If it is split into a second macro (even if it's called in the first with the /click command) when Kill Command locks, you can continue using your macro, and once you get another crit and your pet successfully executes Kill Command, you'll "unlock". If it's all in one macro, you'll be stuck without Auto Shot or your Esc key until you reload your UI.
@Terak:
Create a new bar. Name it "Hidden" (or whatever you want). Add one button to it. Place your second macro on this button. Get the name of the button by placing the mouse cursor over it and typing:
/print GetMouseFocus():GetName()
Put the name that's printed in your chat frame in the first macro instead of MultiBarBottomLeftButton12, like so:
/click [target=pettarget,exists] IBSecure_Hidden1
The reason for putting the pet commands in a separate macro is that Kill Command sometimes "locks up" and prevents you from using Auto Shot or pressing Esc (among other annoyances). If Kill Command is in the same macro as your shot rotation, it will also render the entire macro inoperable. If it is split into a second macro (even if it's called in the first with the /click command) when Kill Command locks, you can continue using your macro, and once you get another crit and your pet successfully executes Kill Command, you'll "unlock". If it's all in one macro, you'll be stuck without Auto Shot or your Esc key until you reload your UI.
Ah. Now I see. Your solution should work perfectly then. :)
ok I actually play arround with things and wanted the border (with Buttonfacade Caith-theme) to hightlight on mouseover in a light color (white) soo...
Currently if you enter a color that is lighter than the "normal" border, you will not get a visible highlight on mouseover. The only colors that work are colors that are darker than the "normal" border.
Ok my problem was that I wrote [FreeSlots()] instead of [Freeslots] <.<
so... the border highlight problem is still there, on some bars the highlight works on some not and they share alle the same dogtags.... appears like a bug to me...
also... is there a slashcommand to show and hide bars?
or a simple script^^
Quote from Phanx »
Currently if you enter a color that is lighter than the "normal" border, you will not get a visible highlight on mouseover. The only colors that work are colors that are darker than the "normal" border.
sooo why does autobar highlight then on mouseover and InfiniBar not? At least one InfitiBar does it too but the other not :(
This sounds like the same problem Phanx and I have been seeing with IB and ButtonFacade. IB does not show the highlight textures that are defined in ButtonFacade skins. I have no clue why, and jj hasn't said anything about it. :(
It's because InfiniBar does not use the state effects (such as highlighting) provided by ButtonFacade skins. Instead, it uses its own system, which is configurable via DogTags. Unfortunately it currently does not work with light colors, and doesn't quite work the same way as the ButtonFacade state effects, thus InfiniBar cannot currently match the rest of the BF-skinned addons in your UI.
JJ has promised to look at the problem with light colored highlights, but seems to be quite attached to the monolithic DogTag library, and has stated that InfiniBar will always use a tagging library, so it is unlikely that IB highlights will ever look exactly like highlights in other BF-skinned addons.
I actually prefer IB's border-only highlight, though. I think the BF highlight that includes the gloss looks horrible with anything but a white highlight, and even then it makes the gloss so bright on mouseover that it's difficult to see what you're actually mousing over. I just wish IB would actually highlight, rather than "darklight". :P
I just recently returned to WoW and, after looking at about 8 bajillion bar addons, found Infinibar.
FINALLY, someone understands just how useful it is to be able to have a few things change dynamically... like I can have my pet bar change to have buttons to tame/call/revive pet if I don't have a pet, etc. I previously had a lot of this same 'magic' in Flexbar, it's nice having it back.
However, just a few problems:
1. On the aforementioned pet bar, when it's NOT in the pet state (and the configuration utility specifically says a button is not the 'pet' type), sometimes I am unable to drag abilities onto the slots that are pet actions when it IS in the pet state.
2. It'd be nice if the built-in "Pet" state considered a dead pet the same as no pet. I use "[pet,target=pet,nodead]" and "[nopet] [target=pet,dead]" as a workaround but haven't tested to see if it really works in the 'dead pet' case yet.
3. I have 4 12-button bars: 1 thru = and ctrl/shift/alt variants of the same. The ctrl and alt bars also have shift- versions (ctrl-shift and alt-shift). These DISPLAY properly, but ctrl+shift+1 tries to activate the shift+1 button on the 'shift' bar instead.
I think the client is confused as to where to send a ctrl+shift+1 when there's effectively conflicting keybinds. I'm also fairly certain that if I could bind both ctrl+1 and ctrl+shift+1 to the same button it would work, but I don't see a way to do this.
I could probably create new ctrl+shift and alt+shift bars for this purpose, but I'd rather not waste the screen real-estate (they're for seldom-used actions that are still handy to have hotkeyed)
... and suggestions:
1. My pet bar is a 12-action bar. With a pet, the first 10 are the first 10 pet actions, 11 and 12 are mend/feed pet. Without, the first action is tame, 11 is revive, 12 is call. When setting up the 'with a pet' version, it was annoyingly tedious to select button 1, choose 'pet', set to ID 1, select button 2, choose 'pet', set to ID 2, repeat. Especially when I had to rebuild the bar a few times as I was getting the feel for the plugin.
Possibly a button or something to 'assign pet IDs 2-10 to next 9 buttons' or similiar would be helpful here.
2. I noticed Infinibar doesn't use the 120 standard IDs (or at least I didn't see a way to tell it to) It would be nice if it had an option to use them, because then I can use essentially the exact same profile on all of my characters with their own character-specific macros. P.S. If you do add this, please make it easy to say 'assign IDs x thru x+count to all buttons in this group' -- see my complaint about the tedium with pet commands.
3. (minor) It would be neat to have some way to separate the 'state pages' from the actual states themselves, so you could go:
2. It'd be nice if the built-in "Pet" state considered a dead pet the same as no pet. I use "[pet,target=pet,nodead]" and "[nopet] [target=pet,dead]" as a workaround but haven't tested to see if it really works in the 'dead pet' case yet.
The "pet" state is a Blizzard-supplied secure state; it's exactly the same as using the "pet" conditional in a macro. Blizzard apparently did not feel that a dead pet is equivalent to no pet, so the best you'd be able to do is to use macro conditionals to set your bar states, and try what you posted. I'm not sure how that will work though... I'm pretty sure "[pet,target=pet,nodead]" would mean "if I have a pet, and my target is my pet, and my target is not dead".
3. I have 4 12-button bars: 1 thru = and ctrl/shift/alt variants of the same. The ctrl and alt bars also have shift- versions (ctrl-shift and alt-shift). These DISPLAY properly, but ctrl+shift+1 tries to activate the shift+1 button on the 'shift' bar instead.
Again, I believe this is a Blizzard limitation; addons have no control over how WoW recieves and interprets keypresses. In your specific case, you could workaround the problem (albeit rather messily) by turning all of your "shift" bar buttons into macro buttons and doing "/use [mod:ctrl] <ctrl ability>; <shift ability>". Probably not worth the hassle, though.
1. My pet bar is a 12-action bar. With a pet, the first 10 are the first 10 pet actions, 11 and 12 are mend/feed pet. Without, the first action is tame, 11 is revive, 12 is call. When setting up the 'with a pet' version, it was annoyingly tedious to select button 1, choose 'pet', set to ID 1, select button 2, choose 'pet', set to ID 2, repeat. Especially when I had to rebuild the bar a few times as I was getting the feel for the plugin.
Seconded. I don't actually play any pet classes, so the pet bar preset meets my needs in this area, but with the possession state, it would be nice if I could simply say "assign all of the buttons on this bar in this state to the possess actions corresponding with their button number", or "assign all of the buttons on this bar in this state to the possess actions beginning with N and incrementing upward". If I wanted one or two buttons to remain "normal" it would be much easier to go back afterward and set them as normal buttons, rather than have to go through and select button 1, click the button type dropdown, click "possess action", select possess action 1, select button 2, etc.
2. I noticed Infinibar doesn't use the 120 standard IDs (or at least I didn't see a way to tell it to) It would be nice if it had an option to use them, because then I can use essentially the exact same profile on all of my characters with their own character-specific macros. P.S. If you do add this, please make it easy to say 'assign IDs x thru x+count to all buttons in this group' -- see my complaint about the tedium with pet commands.
I'm slightly confused as to why you would want to use the same actions on all of your characters? Do you play 5 characters of the same class or something?
Either way, you can easily copy the setup of another character by navigating to the Profile section of the config and using the "Copy Profile" option. From there it would be trivial to swap in the character-specific macros.
3. (minor) It would be neat to have some way to separate the 'state pages' from the actual states themselves, so you could go:
How would this be useful? If you want to use the same page in multiple states, use the "macro conditionals" option and enter multiple states on the same line. For example:
[bonusbar:5]
[mounted] [stance]
[actionbar:1] [actionbar:4]
[actionbar:6] [actionbar:3]
[actionbar:5] [actionbar:2]
I use these macro conditionals on my shaman to set up one state to be shown if I am possessing something, one state to be shown if I am mounted or in a stance (Ghost Wolf is considered a stance), and three states to be shown depending on which actionbar page I'm on. Note the multiple conditions on all but the first line. This creates a bar that scrolls smoothly through just three pages, and changes to a single page if I am mounted/in a stance, or possesing something.
The "pet" state is a Blizzard-supplied secure state; it's exactly the same as using the "pet" conditional in a macro. Blizzard apparently did not feel that a dead pet is equivalent to no pet, so the best you'd be able to do is to use macro conditionals to set your bar states, and try what you posted. I'm not sure how that will work though... I'm pretty sure "[pet,target=pet,nodead]" would mean "if I have a pet, and my target is my pet, and my target is not dead".
From what I've read it, the target=XXX part determines what I'm checking to see if is nodead. Regardless of whether that's accurate or not, my pet bar IS in the correct state if I have a pet out whether I target it or not... it's the "dead but not despawned" instance I haven't tested yet, mainly because I don't feel like killing my pet.
[[ctrl+shift and alt+shift]] I believe this is a Blizzard limitation; addons have no control over how WoW recieves and interprets keypresses. In your specific case, you could workaround the problem (albeit rather messily) by turning all of your "shift" bar buttons into macro buttons and doing "/use [mod:ctrl] <ctrl ability>; <shift ability>". Probably not worth the hassle, though.
Addons have no direct control, but a binding of ctrl+shift+1 will take precedence over both ctrl+1 and shift+1. Being able to bind both ctrl+1 and ctrl+shift+1 to the same button would prevent the shift+1 button from triggering on ctrl+shift+1, at least in theory. But Infinibar can't do dual key binds. :(
[...]
I'm slightly confused as to why you would want to use the same actions on all of your characters? Do you play 5 characters of the same class or something?
Either way, you can easily copy the setup of another character by navigating to the Profile section of the config and using the "Copy Profile" option. From there it would be trivial to swap in the character-specific macros.
I'm referring to having the same layout/keybindings/state changes (it's nice to get it all set up generically once and have it 'just work' on any character regardless of class, and can easily be done at the cost of a few (unused) states per character.
If buttons are tied to the standard 120 action IDs instead of the macros they use now, I could load the exact same profile on multiple characters and have it automatically have the correct buttons (because Blizzard internally remembers the 120 action IDs). It also means slightly less work if I'm forced to use Blizzard's UI or some other bar addon if Infinibar is broken in an update, as the actions will already be assigned to fairly-standard places.
[[re: multiple states->one 'page']]How would this be useful? If you want to use the same page in multiple states, use the "macro conditionals" option and enter multiple states on the same line. For example: [...]
a) This doesn't do me much good if I want to change states after-the-fact.
b) Possibly it'd allow the built-in states to be a bit more useful.
This particular 'idea' was only a really minor one anyways, so I could definitely live without it.
I'm referring to having the same layout/keybindings/state changes (it's nice to get it all set up generically once and have it 'just work' on any character regardless of class, and can easily be done at the cost of a few (unused) states per character.
You can already do that with the existing profile system. Button layout, state config, and keybindings are all copied when you copy a profile.
You can already do that with the existing profile system. Button layout, state config, and keybindings are all copied when you copy a profile.
Yes, but so are the actual buttons themselves.
I'd rather it copy the fact that button X is action 1, button Y is action 2... instead of button X is Attack, button Y is Concussive Shot.
Sure, I can make copies and change each character individually, but what happens when I decide I want to make a minor change to the setup? I have to
a) make the change on every copy of the profile
or
b) re-copy the profile and redo things on each character.
With action IDs, I can have all characters using the SAME profile (not multiple copies) and have things propogate correctly.
Maybe I will dig in the LUA later and see if I can add support for the standard action IDs myself. If so, I'll submit a patch.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Okay, you cannot possibly have the latest version. Get Revision 74848 and try again.
Thanks for your time and again I must say it's my most used addon )
Border Hightlight: [Border(IB2MouseOver and White, 0)]
dont worked, whats wrong?
And the tag
[FreeSlots()]
gives me an syntax error....
"Fade empty" seems to fade bagbuttons too <.<
Do any of the other tag fields contain a Border command? Only one will function at a time.
Not sure why. can you tell me what the error is?
That is the way it is programmed. If you don't want your bags to fade when empty, don't enable it on the button group containing the bag buttons.
[BindKey]
[DrD:DrDColor]
[ItemCount]
[Highlight(Casting or AutoCast or BagOpen or Channeling or Equipped or (CastName:HasAura and Color(0, 0.7, 0)) or (CastName:HasAura(unit='target') and Color(0.7, 0, 0)), 0.1]
[Border(IB2MouseOver and White, 0.9)]
[Overlay(InCooldown or Unusable or OutOfMana or NotInRange, 0.25)]
For "[FreeSlots()]" there only on the little buttonfield "Syntax Error" written.
here is my bar layout
main bar
12x4
Left bar
6x2
Right Bar
6x2
Petbar
Macro 1
Macro2
Im not sure where i should place macro2
on blizzard ui i have to place it in Bottem left bar slot 12
The reason for putting the pet commands in a separate macro is that Kill Command sometimes "locks up" and prevents you from using Auto Shot or pressing Esc (among other annoyances). If Kill Command is in the same macro as your shot rotation, it will also render the entire macro inoperable. If it is split into a second macro (even if it's called in the first with the /click command) when Kill Command locks, you can continue using your macro, and once you get another crit and your pet successfully executes Kill Command, you'll "unlock". If it's all in one macro, you'll be stuck without Auto Shot or your Esc key until you reload your UI.
@Terak:
Create a new bar. Name it "Hidden" (or whatever you want). Add one button to it. Place your second macro on this button. Get the name of the button by placing the mouse cursor over it and typing:
/print GetMouseFocus():GetName()
Put the name that's printed in your chat frame in the first macro instead of MultiBarBottomLeftButton12, like so:
/click [target=pettarget,exists] IBSecure_Hidden1
Ah. Now I see. Your solution should work perfectly then. :)
Currently if you enter a color that is lighter than the "normal" border, you will not get a visible highlight on mouseover. The only colors that work are colors that are darker than the "normal" border.
so... the border highlight problem is still there, on some bars the highlight works on some not and they share alle the same dogtags.... appears like a bug to me...
also... is there a slashcommand to show and hide bars?
or a simple script^^
sooo why does autobar highlight then on mouseover and InfiniBar not? At least one InfitiBar does it too but the other not :(
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumJJ has promised to look at the problem with light colored highlights, but seems to be quite attached to the monolithic DogTag library, and has stated that InfiniBar will always use a tagging library, so it is unlikely that IB highlights will ever look exactly like highlights in other BF-skinned addons.
I actually prefer IB's border-only highlight, though. I think the BF highlight that includes the gloss looks horrible with anything but a white highlight, and even then it makes the gloss so bright on mouseover that it's difficult to see what you're actually mousing over. I just wish IB would actually highlight, rather than "darklight". :P
FINALLY, someone understands just how useful it is to be able to have a few things change dynamically... like I can have my pet bar change to have buttons to tame/call/revive pet if I don't have a pet, etc. I previously had a lot of this same 'magic' in Flexbar, it's nice having it back.
However, just a few problems:
1. On the aforementioned pet bar, when it's NOT in the pet state (and the configuration utility specifically says a button is not the 'pet' type), sometimes I am unable to drag abilities onto the slots that are pet actions when it IS in the pet state.
2. It'd be nice if the built-in "Pet" state considered a dead pet the same as no pet. I use "[pet,target=pet,nodead]" and "[nopet] [target=pet,dead]" as a workaround but haven't tested to see if it really works in the 'dead pet' case yet.
3. I have 4 12-button bars: 1 thru = and ctrl/shift/alt variants of the same. The ctrl and alt bars also have shift- versions (ctrl-shift and alt-shift). These DISPLAY properly, but ctrl+shift+1 tries to activate the shift+1 button on the 'shift' bar instead.
I think the client is confused as to where to send a ctrl+shift+1 when there's effectively conflicting keybinds. I'm also fairly certain that if I could bind both ctrl+1 and ctrl+shift+1 to the same button it would work, but I don't see a way to do this.
I could probably create new ctrl+shift and alt+shift bars for this purpose, but I'd rather not waste the screen real-estate (they're for seldom-used actions that are still handy to have hotkeyed)
... and suggestions:
1. My pet bar is a 12-action bar. With a pet, the first 10 are the first 10 pet actions, 11 and 12 are mend/feed pet. Without, the first action is tame, 11 is revive, 12 is call. When setting up the 'with a pet' version, it was annoyingly tedious to select button 1, choose 'pet', set to ID 1, select button 2, choose 'pet', set to ID 2, repeat. Especially when I had to rebuild the bar a few times as I was getting the feel for the plugin.
Possibly a button or something to 'assign pet IDs 2-10 to next 9 buttons' or similiar would be helpful here.
2. I noticed Infinibar doesn't use the 120 standard IDs (or at least I didn't see a way to tell it to) It would be nice if it had an option to use them, because then I can use essentially the exact same profile on all of my characters with their own character-specific macros. P.S. If you do add this, please make it easy to say 'assign IDs x thru x+count to all buttons in this group' -- see my complaint about the tedium with pet commands.
3. (minor) It would be neat to have some way to separate the 'state pages' from the actual states themselves, so you could go:
'Default' actions
'Alternate' actions
'Alternate 2' actions
and then
"[conditional]" = "Alternate 2"
"Shift key down" = "Alternate"
"Ctrl key down" = "Alternate"
"default' = "Default"
Just my thoughts ;)
The "pet" state is a Blizzard-supplied secure state; it's exactly the same as using the "pet" conditional in a macro. Blizzard apparently did not feel that a dead pet is equivalent to no pet, so the best you'd be able to do is to use macro conditionals to set your bar states, and try what you posted. I'm not sure how that will work though... I'm pretty sure "[pet,target=pet,nodead]" would mean "if I have a pet, and my target is my pet, and my target is not dead".
Again, I believe this is a Blizzard limitation; addons have no control over how WoW recieves and interprets keypresses. In your specific case, you could workaround the problem (albeit rather messily) by turning all of your "shift" bar buttons into macro buttons and doing "/use [mod:ctrl] <ctrl ability>; <shift ability>". Probably not worth the hassle, though.
Seconded. I don't actually play any pet classes, so the pet bar preset meets my needs in this area, but with the possession state, it would be nice if I could simply say "assign all of the buttons on this bar in this state to the possess actions corresponding with their button number", or "assign all of the buttons on this bar in this state to the possess actions beginning with N and incrementing upward". If I wanted one or two buttons to remain "normal" it would be much easier to go back afterward and set them as normal buttons, rather than have to go through and select button 1, click the button type dropdown, click "possess action", select possess action 1, select button 2, etc.
I'm slightly confused as to why you would want to use the same actions on all of your characters? Do you play 5 characters of the same class or something?
Either way, you can easily copy the setup of another character by navigating to the Profile section of the config and using the "Copy Profile" option. From there it would be trivial to swap in the character-specific macros.
How would this be useful? If you want to use the same page in multiple states, use the "macro conditionals" option and enter multiple states on the same line. For example:
[bonusbar:5]
[mounted] [stance]
[actionbar:1] [actionbar:4]
[actionbar:6] [actionbar:3]
[actionbar:5] [actionbar:2]
I use these macro conditionals on my shaman to set up one state to be shown if I am possessing something, one state to be shown if I am mounted or in a stance (Ghost Wolf is considered a stance), and three states to be shown depending on which actionbar page I'm on. Note the multiple conditions on all but the first line. This creates a bar that scrolls smoothly through just three pages, and changes to a single page if I am mounted/in a stance, or possesing something.
From what I've read it, the target=XXX part determines what I'm checking to see if is nodead. Regardless of whether that's accurate or not, my pet bar IS in the correct state if I have a pet out whether I target it or not... it's the "dead but not despawned" instance I haven't tested yet, mainly because I don't feel like killing my pet.
Addons have no direct control, but a binding of ctrl+shift+1 will take precedence over both ctrl+1 and shift+1. Being able to bind both ctrl+1 and ctrl+shift+1 to the same button would prevent the shift+1 button from triggering on ctrl+shift+1, at least in theory. But Infinibar can't do dual key binds. :(
[...]
I'm referring to having the same layout/keybindings/state changes (it's nice to get it all set up generically once and have it 'just work' on any character regardless of class, and can easily be done at the cost of a few (unused) states per character.
If buttons are tied to the standard 120 action IDs instead of the macros they use now, I could load the exact same profile on multiple characters and have it automatically have the correct buttons (because Blizzard internally remembers the 120 action IDs). It also means slightly less work if I'm forced to use Blizzard's UI or some other bar addon if Infinibar is broken in an update, as the actions will already be assigned to fairly-standard places.
a) This doesn't do me much good if I want to change states after-the-fact.
b) Possibly it'd allow the built-in states to be a bit more useful.
This particular 'idea' was only a really minor one anyways, so I could definitely live without it.
You can already do that with the existing profile system. Button layout, state config, and keybindings are all copied when you copy a profile.
Yes, but so are the actual buttons themselves.
I'd rather it copy the fact that button X is action 1, button Y is action 2... instead of button X is Attack, button Y is Concussive Shot.
Sure, I can make copies and change each character individually, but what happens when I decide I want to make a minor change to the setup? I have to
a) make the change on every copy of the profile
or
b) re-copy the profile and redo things on each character.
With action IDs, I can have all characters using the SAME profile (not multiple copies) and have things propogate correctly.
Maybe I will dig in the LUA later and see if I can add support for the standard action IDs myself. If so, I'll submit a patch.