There was mention a while ago about a seperate Main Tank module being released that would work with oRA3, is this still planned or was the idea scrapped? I'd love to switch to oRA3 but without built in Main Tank frames I won't be able to.
oRA3 uses the Blizzard MT info. If you are like me, and don't like the look of that, then I suggest WTFrames (who's tanking frames) or oUF_DaMT, which do the job of looking good, and WTFrames supports oRA3's ability to sort the MTs.
WTFrames was just updated to 1.31 about 2 hours ago.
If Ammo and Rabbit decide to write a module for oRA3, power to them; but it isn't necessary.
Realistically all we'd need by now is a standalone MT frames addon, since both DaMT and WTF rely on oUF. That being said I think Pitbull has integrated MT frames support? Don't know about other unitframes.
I have souldstones unchecked on cooldowns to track, yet everytime its cast on anyone it pops up a timer bar that's empty, never goes away until I leave the raid and I get the following error
oRA3-291\modules\Cooldowns.lua:550: attempt to index local 'c' (a nil value)
oRA3-291\modules\Cooldowns.lua:766: in function <oRA3\modules\Cooldowns.lua:749>
oRA3-291\modules\Cooldowns.lua:894: in function `?'
CallbackHandler-1.0-5 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[4]":4: in function <[string "safecall Dispatcher[4]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[4]":13: in function `?'
CallbackHandler-1.0-5 (Ace3):92: in function `Fire'
oRA3-291\oRA3.lua:403: in function `DispatchComm'
oRA3-291\oRA3.lua:398: in function `?'
CallbackHandler-1.0-5 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[4]":4: in function <[string "safecall Dispatcher[4]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[4]":13: in function `?'
CallbackHandler-1.0-5 (Ace3):92: in function `Fire'
AceComm-3.0-6 (Ace3):268: in function <Ace3\AceComm-3.0\AceComm-3.0.lua:257>
I have souldstones unchecked on cooldowns to track, yet everytime its cast on anyone it pops up a timer bar that's empty, never goes away until I leave the raid and I get the following error
oRA3-291\modules\Cooldowns.lua:550: attempt to index local 'c' (a nil value)
oRA3-291\modules\Cooldowns.lua:766: in function <oRA3\modules\Cooldowns.lua:749>
oRA3-291\modules\Cooldowns.lua:894: in function `?'
CallbackHandler-1.0-5 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[4]":4: in function <[string "safecall Dispatcher[4]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[4]":13: in function `?'
CallbackHandler-1.0-5 (Ace3):92: in function `Fire'
oRA3-291\oRA3.lua:403: in function `DispatchComm'
oRA3-291\oRA3.lua:398: in function `?'
CallbackHandler-1.0-5 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[4]":4: in function <[string "safecall Dispatcher[4]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[4]":13: in function `?'
CallbackHandler-1.0-5 (Ace3):92: in function `Fire'
AceComm-3.0-6 (Ace3):268: in function <Ace3\AceComm-3.0\AceComm-3.0.lua:257>
ok maybe I missed it completely but, I am trying to reduce the amount of background communicating addons that me and my guild use, so I was trying to switch to ora3 (from ora2) and remove Raidcooldowns completely (since ora3 already provides the info in a similar manner, btw on that note anyway you can add an option to have the bars go left to right instead of just right to left?), however I miss the readycheck window that ora2 gives us. Has it been hidden away somewhere that I just missed it or do I have to do something different to see my ready/not read/afk players again?
ok maybe I missed it completely but, I am trying to reduce the amount of background communicating addons that me and my guild use, so I was trying to switch to ora3 (from ora2) and remove Raidcooldowns completely (since ora3 already provides the info in a similar manner, btw on that note anyway you can add an option to have the bars go left to right instead of just right to left?), however I miss the readycheck window that ora2 gives us. Has it been hidden away somewhere that I just missed it or do I have to do something different to see my ready/not read/afk players again?
Must be missing it, there is a box that comes up with ready/not ready and such built in
ok maybe I missed it completely but, I am trying to reduce the amount of background communicating addons that me and my guild use, so I was trying to switch to ora3 (from ora2) and remove Raidcooldowns completely (since ora3 already provides the info in a similar manner, btw on that note anyway you can add an option to have the bars go left to right instead of just right to left?), however I miss the readycheck window that ora2 gives us. Has it been hidden away somewhere that I just missed it or do I have to do something different to see my ready/not read/afk players again?
There is currently a bug that assistants can't issue readychecks. THis has nothing to do with oRA3/2. It's a blizzard bug. So that might cause your missing window.
Noticed the Cooldown monitor doesn't get my own fearward cooldown in AV but does in like ICC raids, no settings changed. Other fearwards do appear when in AV, I 'think' this also happens in 5mans if active.
6x <event>ADDON_ACTION_BLOCKED:AddOn 'oRA3' tried to call the protected function '<unnamed>:SetPoint()'.
<in C code>: in function `SetPoint'
oRA3-331\oRA3.lua:362: in function `UpdateContentFrame'
oRA3-331\oRA3.lua:306: in function `?'
CallbackHandler-1.0-5 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[1]":4: in function <[string "safecall Dispatcher[1]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[1]":13: in function `?'
CallbackHandler-1.0-5 (Ace3):92: in function `Fire'
AceEvent-3.0-3 (Ace3):120: in function <Ace3\AceEvent-3.0\AceEvent-3.0.lua:119>
r331 LUA error, was in my offspec tank spec and gear:
1x <event>ADDON_ACTION_BLOCKED:AddOn 'Ace3' tried to call the protected function 'oRA3TankTopScrollTank1:EnableMouse()'.
<in C code>: in function `EnableMouse'
oRA3-331\modules\Tanks.lua:72: in function `?'
CallbackHandler-1.0-5 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[2]":4: in function <[string "safecall Dispatcher[2]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[2]":13: in function `?'
CallbackHandler-1.0-5 (Ace3):92: in function `Fire'
oRA3-331\oRA3.lua:300: in function `?'
CallbackHandler-1.0-5 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[1]":4: in function <[string "safecall Dispatcher[1]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[1]":13: in function `?'
CallbackHandler-1.0-5 (Ace3):92: in function `Fire'
AceEvent-3.0-3 (Ace3):120: in function <Ace3\AceEvent-3.0\AceEvent-3.0.lua:119>
2/25 23:51:06.646 An action was blocked in combat because of taint from Ace3 - <unnamed>:Enable()
2/25 23:51:06.646 Interface\AddOns\oRA3\modules\Tanks.lua:72 ?()
2/25 23:51:06.646 Interface\AddOns\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147 method()
2/25 23:51:06.646 safecall Dispatcher[2]:4
2/25 23:51:06.646 xpcall()
2/25 23:51:06.646 safecall Dispatcher[2]:13 ?()
2/25 23:51:06.646 Interface\AddOns\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:92 Fire()
2/25 23:51:06.646 Interface\AddOns\oRA3\oRA3.lua:301 ?()
Not entirely sure if I reloadedUI after I got the alpha that supposedly fixed the previous taint error.
Since this is a different one I'm posting it 'just in case'.
Recently took the plunge switching from oRA2.
(main reason strangely enough was not any dissatisfaction with oRA2 feature set more the lack of integration with the default blizzard tanks that raiders take for granted nowadays)
It was mostly painless (using WTFrames for tank frames) and I like it.
One difference I noticed (not sure it's a bug or not) is that oRA3 doesn't observe the masterloot and quality option (set from Blizz options) when I convert a party to raid manually. (from the "convert to raid" button of the raid frame)
It's not a problem for guild runs but it has caused me trouble in the occasional VoA25 pug or such as I was used to it happening automatically and never bother to check loot settings.
Recently took the plunge switching from oRA2.
(main reason strangely enough was not any dissatisfaction with oRA2 feature set more the lack of integration with the default blizzard tanks that raiders take for granted nowadays)
It was mostly painless (using WTFrames for tank frames) and I like it.
One difference I noticed (not sure it's a bug or not) is that oRA3 doesn't observe the masterloot and quality option (set from Blizz options) when I convert a party to raid manually. (from the "convert to raid" button of the raid frame)
It's not a problem for guild runs but it has caused me trouble in the occasional VoA25 pug or such as I was used to it happening automatically and never bother to check loot settings.
Is this expected behavior?
oRA3 has it's ML settings in the options menu. And will automatically switch to those settings.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
oRA3 uses the Blizzard MT info. If you are like me, and don't like the look of that, then I suggest WTFrames (who's tanking frames) or oUF_DaMT, which do the job of looking good, and WTFrames supports oRA3's ability to sort the MTs.
WTFrames was just updated to 1.31 about 2 hours ago.
If Ammo and Rabbit decide to write a module for oRA3, power to them; but it isn't necessary.
oRA3-291\modules\Cooldowns.lua:550: attempt to index local 'c' (a nil value)
oRA3-291\modules\Cooldowns.lua:766: in function <oRA3\modules\Cooldowns.lua:749>
oRA3-291\modules\Cooldowns.lua:894: in function `?'
CallbackHandler-1.0-5 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[4]":4: in function <[string "safecall Dispatcher[4]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[4]":13: in function `?'
CallbackHandler-1.0-5 (Ace3):92: in function `Fire'
oRA3-291\oRA3.lua:403: in function `DispatchComm'
oRA3-291\oRA3.lua:398: in function `?'
CallbackHandler-1.0-5 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[4]":4: in function <[string "safecall Dispatcher[4]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[4]":13: in function `?'
CallbackHandler-1.0-5 (Ace3):92: in function `Fire'
AceComm-3.0-6 (Ace3):268: in function <Ace3\AceComm-3.0\AceComm-3.0.lua:257>
This should have been fixed now in alphas
Must be missing it, there is a box that comes up with ready/not ready and such built in
There is currently a bug that assistants can't issue readychecks. THis has nothing to do with oRA3/2. It's a blizzard bug. So that might cause your missing window.
6x <event>ADDON_ACTION_BLOCKED:AddOn 'oRA3' tried to call the protected function '<unnamed>:SetPoint()'.
<in C code>: in function `SetPoint'
oRA3-331\oRA3.lua:362: in function `UpdateContentFrame'
oRA3-331\oRA3.lua:306: in function `?'
CallbackHandler-1.0-5 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[1]":4: in function <[string "safecall Dispatcher[1]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[1]":13: in function `?'
CallbackHandler-1.0-5 (Ace3):92: in function `Fire'
AceEvent-3.0-3 (Ace3):120: in function <Ace3\AceEvent-3.0\AceEvent-3.0.lua:119>
---
1x <event>ADDON_ACTION_BLOCKED:AddOn 'Ace3' tried to call the protected function 'oRA3TankTopScrollTank1:EnableMouse()'.
<in C code>: in function `EnableMouse'
oRA3-331\modules\Tanks.lua:72: in function `?'
CallbackHandler-1.0-5 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[2]":4: in function <[string "safecall Dispatcher[2]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[2]":13: in function `?'
CallbackHandler-1.0-5 (Ace3):92: in function `Fire'
oRA3-331\oRA3.lua:300: in function `?'
CallbackHandler-1.0-5 (Ace3):147: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147>
<string>:"safecall Dispatcher[1]":4: in function <[string "safecall Dispatcher[1]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[1]":13: in function `?'
CallbackHandler-1.0-5 (Ace3):92: in function `Fire'
AceEvent-3.0-3 (Ace3):120: in function <Ace3\AceEvent-3.0\AceEvent-3.0.lua:119>
---
Since this is a different one I'm posting it 'just in case'.
fixed last night
(main reason strangely enough was not any dissatisfaction with oRA2 feature set more the lack of integration with the default blizzard tanks that raiders take for granted nowadays)
It was mostly painless (using WTFrames for tank frames) and I like it.
One difference I noticed (not sure it's a bug or not) is that oRA3 doesn't observe the masterloot and quality option (set from Blizz options) when I convert a party to raid manually. (from the "convert to raid" button of the raid frame)
It's not a problem for guild runs but it has caused me trouble in the occasional VoA25 pug or such as I was used to it happening automatically and never bother to check loot settings.
Is this expected behavior?
oRA3 has it's ML settings in the options menu. And will automatically switch to those settings.