1. #1

    Amber-shaper un'sok, no possess bar with bartender4

    As the title says, when we were on this boss last night and i became a construct i didn't get any new abilities which resulted in a whipe because i couldn't do shit.
    The odd thing is that in bartender i have possess bar checked on bar 1.
    I might add that on the earlier kills when i became a construct i could see the abilities but i had to click on them with my mouse, why?
    How do i fix this? Cheers!

  2. #2
    Check if there's a new update for bartender if you havn't.

    Wouldn't really know what else to do.

  3. #3
    Quote Originally Posted by Proberly View Post
    Check if there's a new update for bartender if you havn't.

    Wouldn't really know what else to do.
    I have the latest version from curse :/

  4. #4
    Have you checked if vehicle bar is enabled?
    If yes check the visibility on that bar.
    Try to queue for isle of conquest to check it before raid.
    There's the Use Blizzard vehicle ui option as well.
    You may wanna check/uncheck that to see differences.
    Can't think of anything else that would cause the issue.

  5. #5
    Quote Originally Posted by Louna View Post
    Have you checked if vehicle bar is enabled?
    If yes check the visibility on that bar.
    Try to queue for isle of conquest to check it before raid.
    There's the Use Blizzard vehicle ui option as well.
    You may wanna check/uncheck that to see differences.
    Can't think of anything else that would cause the issue.
    But the possess bar don't have anything to do with the vehicle bar, or?
    Because i have bartenders vehicle bar disabled but "use blizzard vehicle UI" enabled and that works fine in BG's and at my farm.

  6. #6
    Actually in this special case the possessbar has sth to do with the vehicle (now called OverrideActionBar)

    The solution is posted here: http://www.wowinterface.com/forums/s...d.php?p=269156

    Running the following macro while the bar is active will return [possessbar] as true.
    Code:
    /run local s=SecureCmdOptionParse print(s("[extrabar]extrabar"),s("[overridebar]overridebar"),s("[possessbar]possessbar"),s("[vehicleui]vehicleui"))
    .
    How the heck is this possible if what is actually displayed is the OverrideActionBar? Well that is sth you can ask Blizzard. Neither [vehicleui] nor [overridebar] returned true.

    It can be fixed by using the [possessbar,@vehicle,exists] condition. This will return true for this special case. The possessbar condition fired and the vehicle unit exists. The feast tables use the same condtion and can be used for easy testing.

    The problem is: Normally if possessbar fires it will use the default main actionbar. But not in those special cases. Some wierdo decided to use the OverrideActionBar instead without telling anyone.

    Currently there are 3 conditions to spawn the OverrideActionBar: [vehicleui][overridebar][possessbar,@vehicle,exists]
    Last edited by zorker; 2012-11-20 at 01:21 PM.
    | Simple is beautiful.
    | Roth UI | Roth UI FAQ | GoogleCode | Zork | TDMOG

    "I wonder what the non-pathetic people are doing tonight?" - Rajesh Koothrappali (The Big Bang Theory)

  7. #7
    Quote Originally Posted by zorker View Post
    Actually in this special case the possessbar has sth to do with the vehicle (now called OverrideActionBar)

    The solution is posted here: http://www.wowinterface.com/forums/s...d.php?p=269156

    Running the following macro while the bar is active will return [possessbar] as true.
    Code:
    /run local s=SecureCmdOptionParse print(s("[extrabar]extrabar"),s("[overridebar]overridebar"),s("[possessbar]possessbar"),s("[vehicleui]vehicleui"))
    .
    How the heck is this possible if what is actually displayed is the OverrideActionBar? Well that is sth you can ask Blizzard. Neither [vehicleui] nor [overridebar] returned true.

    It can be fixed by using the [possessbar,@vehicle,exists] condition. This will return true for this special case. The possessbar condition fired and the vehicle unit exists. The feast tables use the same condtion and can be used for easy testing.

    The problem is: Normally if possessbar fires it will use the default main actionbar. But not in those special cases. Some wierdo decided to use the OverrideActionBar instead without telling anyone.

    Currently there are 3 conditions to spawn the OverrideActionBar: [vehicleui][overridebar][possessbar,@vehicle,exists]
    Thanks mate, i do however don't understand much of what you wrote.
    Should i paste that macro in the chat when i become a construct or?

  8. #8
    No. I was just explaining that the [possessbar] can and does fire under certain circumstances while in a vehicle. This exception has to be catched and handled appropriately. This is more an information for the action bar developer. No clue how Bartender handles the OverrideActionBar.
    | Simple is beautiful.
    | Roth UI | Roth UI FAQ | GoogleCode | Zork | TDMOG

    "I wonder what the non-pathetic people are doing tonight?" - Rajesh Koothrappali (The Big Bang Theory)

  9. #9
    Pit Lord Odina's Avatar
    Join Date
    Sep 2008
    Location
    Montreal, Quebec, Canada
    Posts
    2,260
    Bartender was working fine for myself... best bet is to mess with the settings in LFR on the same fight! As well go look at all your paging options and ensure the bars that will be paged are enabled!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •