• 0

    posted a message on Mounted (official thread)
    Quote from yssaril
    any errors? it works fine on my end. when you go to the config does the mount show up in the priorities list? also what locale are you using?

    if its not enUS then it may fail the can fly check.
    check the local file for your locale and make sure that all the translations for the zones under --======Special locations======-- are translated correctly

    edit: committed a fix for the options.lua line 284 error shouldn't have impacted functionality just options


    enUS, no errors were popping up, and mounts were showing in the priority list.

    Updated to 1.0.2 and the problem is now fixed it appears to be detecting [flyable] correctly now.
    Posted in: General AddOns
  • 0

    posted a message on Mounted (official thread)
    Quote from yssaril
    alright released version 1.0.0 enjoy


    Uhhhm, not sure what is going on, but it does not seem to like flying mounts on the beta realms. While in Outland(checked Shattrath), and in Northrend, it only puts me on my ground mounts.

    ...even when I edit out all calls for the ground mounts and make it flyers only. :?
    Posted in: General AddOns
  • 0

    posted a message on Threat-2.0 / Omen2 - request for PTR testers
    Would put this on Jira, but not sure exactly where Threat-2.0 falls under that system.

    Also not sure which thread is entirely relevant to Threat-2.0 at this point, but anyhow...

    Threat-2.0 is using LibSink-2.0 but does not include that library on the files.wowace.com version(r65697) of it. Which is going to be a likely cause of errors for others, as it was one for me.
    Posted in: Raid AddOns
  • 0

    posted a message on LibHealComm-3.0 Official Thread
    Quote from xbeeps »

    Resurrection does not belong in LibHealComm-3.0. But I see the usefulness of a LibResurrection-1.0, which simply just passes resurrection info around. It will be very small, very easy to implement, and won't require any external dependencies (but will embed LibStub+Callbackhandler). If there's any active development on SmartRes, i suggest the relevant functionality is split into a library - this was the approach I used with HealComm-2.0, which initially just contained the communication code from VisualHeal.


    ...Or alternately the people working on oRA2 can split off the resurrection reporting off from oRA2 and make it a library of its own. Considering the CTRA channel seems to be the current defacto standard comm channel for that purpose. Of course, it is kind of pointless to undertake that step if no other AddOn authors are going to use it.

    http://fish.wowace.com/browse/WowAce/trunk/oRA2/Participant/Participant.lua?r=63125

    Lines 45-48 and 51 ; 53-54? ; 58-86 ; 120-125 ; 183-197 ; 218-230 ; 251-310 seem to be the relevant ones for how oRA approaches detection of an incoming resurrection.

    It should be mentioned the above selections of code is lacking some of the code for Comms, which is back in the core module of oRA. (namely registering the oRA:SendMessage event which is back in the core module for oRA2)
    Posted in: Libraries
  • 0

    posted a message on Recount
    A Guild Member was running an AddOn that was monitoring spam coming through the addon channels in game during our raid last night.

    Top offenders was found to be DoTTimer and Recount(mine specificaly - I seemed to be only person in the raid running Recount).

    Which prompted a little bit of searching through code to find out how Recount is handling the spam it sends to other users/addons.

    Now, seeing as Recount is a damage meter first and foremost, I was rather intrigued by this:

    http://fish.wowace.com/browse/~raw,r=47034/WowAce/trunk/Recount/Sync.lua

    function Recount:ConfigComm()
    Recount:SetCommPrefix("RECOUNT")
    Recount:RegisterComm("RECOUNT", "GROUP", "OnCommReceive")
    Recount:SetDefaultCommPriority("ALERT")
    Recount:RegisterMemoizations("ABBREV","RESETABBREV","DAMAGE","HEALING","VERSIONREQUEST","VERSION","RANGELIST","PLAYERSYNC","EVENTNUM","HEALCORRECT")


    Now checking into the API for chatthrottlelib, I seem be under the impression that Recount is sending its addon spam at the highest priority available. Is there a particular reason that damagemeter data is considered to be of such an urgent priority? Personally, I'd prefer that the ALERT priority be reserved for addons that are communicating far more vital information, such as Threat Reporting and Boss Event triggers. (Edit to add: FWIW as a frame of reference, Violation sends its sync data at the "bulk" data priority)

    They're not going to be finding their way to the outside world very fast if every other addon out there decides their sync data is of the highest priority as well...
    Posted in: General AddOns
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    Sorry for the quote pyramid. =/

    Quote from Buio »

    Quote from Fwip »

    Quote from Queda »

    Quote from Leialyn »

    From Worldofraids
    ... what can we expect before the next expansion?
    - They will add a threat meter into the game ...
    Then we can really get accurate info and differentiate between mobs with same name \o/

    Not really, as you can't tell whether it's (Skull) Mobname or (Circle) Mobname that has been hit through the combat log.

    Why wouldn't Blizzard's ingame threat meter have access to information that is restricted from access by mods? It's not like the threat meter will bot for you.

    Yeah, and also mods will gain access to this of course.
    http://www.wowinterface.com/forums/showpost.php?p=64418

    ...they answered by saying that the new api associated with the combat log will expose unique identifiers for each target in your sphere of influence. This will allow you to identify each target individually, even if all have the same name. This system will also allow other details be exposed, although specific data that would be available is yet to be revealed.


    Also it mentions a simple threat meter. My guess is that Omen and Threat will be able to benefit alot from the new functions (when the arrive, which aint around the corner), and that most users will continue use Omen due to full and advanced functionality even if Blizzard has plans for a simple ingame threat meter.


    I was present at that panel, and the combat log question was actually a two parter, the first part asked by the person immediately in front of me(who generally asked about improvements to the combat log), and the second part asked by me as a follow up(about being able to determine who pets belong to via the combat log).

    As I'm now roughly 1.5 weeks removed from the panel. The response I received was along the lines of:

    "Every unit that exists in the game has a unique identifier associated with it already, in an upcoming patch we will be making that 'layer' of information available for UI mod authors to take advantage of." And that was in turn followed by a comment from about their intention to add a threat meter into the default game UI.

    There were several questions asked in regards to that addition specifically. The general impression they seemed to be getting across is that the Blizz default threat meter once implemented is going to be very minimalisitic and likely will do nothing more than alert you that you are about to pull aggro. So if you're looking to see threat tables like KTM/Threat-1.0 are generating, you'd have to continue using them to get that functionality. The example they were going for specifically was their threat meter would be implemented with about the same default functionality you can get out of the cast bars they added to the stock UI in WoW 2.0.
    Posted in: Raid AddOns
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    Quote from Aestil »

    Quote from TheDeamon »

    2) The aggro-gain bar should be tracking with the person the mob is currently attacking(random secondary target generator notwithstanding), as they actually are the person that has aggro on the mob.


    Didn't KTM find away around RST?


    You caught part of what I said, but missed the other part. People targeted by the RSTG do not have aggro, and shouldn't be tracked. (hence the comment about RSTG notwithstanding)
    Posted in: Raid AddOns
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    Quote from Glith »
    another thing.. I also noticed a few times that the "aggro gain"-bar ends up in the middle of the bars and 2-3 ppl are above it. Shouldnt the aggro gain bar be at the top all the time?


    Two things on this:

    1) I'd lay odds on the people running above the aggro gain bar were KTM users. KTM under normal conditions(no master target set), does not track threat on any particular mob. So KTM users will be reporting their global threat value back to the raid. This can result in them showing a higher amount of threat on the target being attacked than what the tank has.

    2) The aggro-gain bar should be tracking with the person the mob is currently attacking(random secondary target generator notwithstanding), as they actually are the person that has aggro on the mob.
    Posted in: Raid AddOns
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    Quote from wallix »

    Our guild is an all-Omen guild currently. Usually it works great but last night we were having several quirks in Karazhan. First off, some of us were getting nasty lua-errors from Threat 1.0. Switching to an older version of Omen fixed it for now. I was having an issue where, if I pulled a bar out, it would stick to my cursor no matter where it went. I would actually have to type /logout to logout because I couldn't press any buttons. Once I re-logged back-in it was fine, though. And on Nightbane, our druid pulled aggro off of the tank and he was well below our MT in threat (This was before he Nightbane took-off, too. It was in the early stages). Everyone was very confused because we had not seen this happen before. It could've been a game glitch, though.

    Thanks!


    My guild was likewise seeing some weirdness with Threat-1.0 and Omen last night in Karazhan. While on Prince the main tank would occasionally stop transmitting data to the Threat-1.0 users in the raid(he was running threat-1.0/omen only at that point), the KTM users could still see him. We had him update his install of threat-1.0/omen to the most recent version. He exited out of wow and logged back in, only to be presented with the LUA errors and another round of threat data ceasing to be transmitted mid-fight, with it resuming transmission upon the tanks death(!).

    Ultimately we had him log out, disable Threat-1.0/Omen, and had him turn on KTM and ran through the encounter that way without incident(except some Threat-1.0 users had to reload their own UI to get Threat-1.0 to realize he was no longer running a Threat-1.0 client so it could pull his KTM data instead).

    I've also seen occasions where Omen/Threat isn't registering the mob making a target change. It's happened on my hunter a few times, here I'd pull aggro from my pet, then the pet would grab aggro back from me, but Omen would continue generating an aggro gain bar for me rather than the pet(which actually had aggro).

    Related minor annoyance thing too: On bosses with the RSTG thing going on, it isn't uncommon for Omen to pick up on those target changes, assume it was a change in who had aggro, and immediately begin warning me that I was about to pull aggro from the person getting the TLC of the Random Secondary Target Generator. Not exactly sure how you'd go about telling the difference between an actual aggro-pull versus a momentary retargeting via the RSTG but thought I'd put that one out there as well.
    Posted in: Raid AddOns
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    Quote from Diabolique »

    Quote from Diabolique »

    Love the addon, just some visual adjustments..

    Can you:
    1. make option to have window size fixed, not changed dynamically?


    Right click menu option.
    Skin settings -> Bars -> Number of Bars

    I don't remember seeing Omen dynamically resizing the window on me ever, and I've been using it since early June.

    2. make option to hide version number of Omen and Thread ?


    Not happening until Omen leaves Beta, as that information is useful to Antiarc when people submit bugged screenshots.

    2. make option to hide word "omen" in the title bar, which would make more room for target name....and title bar width should be limited by actual window width, not to grow over on some long target names. Hiding word "omen" will help on that...


    Not happening until Omen leave beta.

    I repeat this post since havent got any answers


    He'd answered most of those questions for other people previously.
    Posted in: Raid AddOns
  • 0

    posted a message on Official Threat-1.0 error reporting and discussion thread
    Quote from Cal »

    Has been discussed and the short answer is, no.


    I imagine it does check level of the target, however? =P

    Not that it does much good in the encounters where Blizzard spawns several mobs with the same name/level.... Which I expect will become more common as time goes on, because I'm 99% certain that threat meters are now the WoW 2.0 version of Decursive from the middling days of "Vanila WoW" for the ecnounter designers.
    Posted in: Libraries
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    Quote from ThePopeRope »
    and there are more fights like that.. so an option to disable global threat would be really really nice.


    I'm not sure that is entirely needed with Threat-1.0/Omen seeing as its default behavior is to track threat on a per target basis to the best of its ability with what the Blizzard API allows. There aren't that many classes with abilities with very long range global threat generating(damage dealing) abilities anyhow, AoE threat is almost exclusively the domain of healers to begin with and generally they shouldn't be near the top of the threat meters to begin with.
    Posted in: Raid AddOns
  • 0

    posted a message on Official Threat-1.0 error reporting and discussion thread
    Quote from Smrtonoska »

    Quote from TheDeamon »

    Quote from HunterZ »

    The tank and most other players in the raid are using KTM (I am not) and they said they could see me go above the tank before pulling aggro.


    If you have Threat-1.0 providing that data to them, and they saw you pull aggro on their meters, Threat-1.0 was working properly, Omen is the mod that wasn't behaving properly.


    Omitted some of the extraneous quotes from my previous post for relevancy purposes here

    From my understanding of KTM vs Threat 1.0 this is not necessarily error.
    - THreat 1.0 tracks your threat for every target
    - KTM tracks only sum of all your threat
    - when KTM users are detected, Threat 1.0 sends them "expected KTM-like" data (sum of all threat)
    - Omen shows your threat for single target and also threat from pure-ktm users (marked with "*")

    So you see your Omen with your relatively small threat and really big threat from MT using KTM -> "OK, I am safe ... zeeeeerg!!!" :-)
    At same time your guildmates see their KTM frame with your threat. This is KTM-like data simulated by Threat 1.0 -> "OMG, n000b. Overagroed MT"


    There are a few possible scenarios here. One of which is what you mention here, Threat-1.0 was working as it was designed to do, but due to the poor quality of the KTM data being provided(as it was presumably global in nature), he pulled aggro off the tank even though he looked fine on Omen. Because Omen was comparing the tanks global threat against his single target threat. So as I said, the problem isn't with threat, but with Omen. Albeit not a bug in this particular scenario as Omen likewise was functioning as it was designed to. So this scenario becames a case study for potentially being able to force a display of global threat in Omen instead of its current default functionality. (though I do belive some other ace2 mods already have this kind of functionality(global threat) built in, like Violation)

    The alternate option that I was thinking of is he had Omen glitch and cease updating his displayed threat while threat contined to provide updates, which would cause a comparable result. If it was due to him not receiving visual threat updates on himself via Omen, but other people were continuing to receive threat updates from him via Threat-1.0(which he indicates was happening), it once again points at a potential bug with Omen, not Threat-1.0.

    But as Antiarc mentions in this thread(and I have in the Omen thread elsewhere) Changing your display to Global Threat in a multiple mob encounter doesn't provide you with any additional protection against pulling aggro, as global threat makes the assumption that everyone has the same proportion of threat spread across all mobs, and the only people likely to be even close to meeting that criteria are the healers. Which is how they can often pull aggro on mobs that aren't being tanked/CC'd to at least some moderate extent.
    Posted in: Libraries
  • 0

    posted a message on Official Threat-1.0 error reporting and discussion thread
    Quote from HunterZ »

    r42153 threat compared to KTM is waaaaaay off on Tidewalker. I kept pulling aggro when I was way, way under the tank on my Omen display. The tank and most other players in the raid are using KTM (I am not) and they said they could see me go above the tank before pulling aggro.


    Sounds like a display glitch with Omen, not a problem with Threat-1.0 unless you happened to still be running KTM in the background to provide the raid with threat data that way. If you have Threat-1.0 providing that data to them, and they saw you pull aggro on their meters, Threat-1.0 was working properly, Omen is the mod that wasn't behaving properly.
    Posted in: Libraries
  • 0

    posted a message on Omen - Bug Reports and Suggestions
    Quote from Rufuspalmer »

    Quote from teedog »

    A shadow priest in my raid said the latest revision from last night still gave him very inaccurate results. Sorry I don't have more concrete data. Is there something wrong with the calculations for Vampiric Touch and Vampiric Embrace?


    I was on my Shadow Priest in a Black Morass run last night and kept pulling agro on the Rift Lords despite Omen reporting that I was at least 2k or more in threat behind the MT. He was running KTM, I was running Omen. Everyone in the party observed the same thing, so yeah, I'm thinking the VT/VE calculations might be off. I haven't noticed this before, though I usually run with tanks that generate more threat so it's probably less of an evident issue with them.


    This is something I haven't exactly run into problems with during my shadowpriesting, though I'm probably attributing a fair amount of aggro "fudge factor" on multi-mob situations where KTM users are concerned as I know it handles global threat only. Global threat value != single mob threat value, while in some cases(healers in particular) this generally means people will potentially show as having less threat than they actually do, it can also result people (DPS/tanking classes) showing as having more threat on a target than they atually do.

    For Example in Black Morass: The tank single-target attacks and gains 3,000 threat on an Infinite Executioner, the tank now gains a fair amount of global threat in KTM.

    The tank then single-target attacks and generates another 2,000 threat on an Infinite Assassin, tank now gains more global threat on KTM.

    The tank then begins attacking an Infinite Chrono-Lord, due to how KTM handles threat(globally), he will potentially start out with ~5K threat showing on KTM, and by extension Threat-1.0. Whereas Threat-1.0 will have you start out at 0 threat on the Chrono-Lord because it actually is smart enough to do it on a per target basis. So you getting within close proximity of the tank's (global) threat on a single target can result in you pulling aggro off the tank, but that is a problem you could just as easily have with KTM as well if the Chrono-Lord was the only mob you were attacking(so that even though KTM deals in global threat, for you it is effectively single-target threat like Threat-1.0 deals in).

    Easiest solution for a more detailed /bug report of this is to try it with a tank running Threat-1.0 so you are working off the same kind of data. Though this has the downside of doing nothing to potentially resolve the KTM <-> Threat-1.0 issue for Spriests.
    Posted in: Raid AddOns
  • To post a comment, please or register a new account.