CurseForge and Overwolf are joining forces!
Awesome More Information
  • 0

    posted a message on Parser-3.0 now has a Parser-1.1 compat layer
    Quote from ckknight »

    Okay, I actually put in a fixlogstrings thing into Parser-3.0, but it's currently not activated due to political reasons (rophy thinks it's bad karma).

    It's very similar to SW_FixLogStrings, only a bit faster.

    Basically, the reason it'd be bad to update is that if some other third-party parser read the global strings, it was fixed, and the event run, said parser wouldn't read it possibly. This is solved, of course, by running the fix before anything else. So, it has the potential to break other addons, but if it isn't done, then some strings are ambiguous and the parsing is fucked anyway.


    I dont think I'm the only one who agree an addon should avoid breaking other addons whenever possible.

    With an external FixLogStrings, if you want to fix your combat log, you use it; if you don't want, don't use it, nothing breaks for not using it, no change required except adding OptionalDeps.

    I don't see why it should be included in Parser-3.0, when Parser-3.0 needs nothing from FixLogStrings to work.

    Sure, the same can be done in Parser-3.0 and adding OptionalDeps to all addons, but if everyone think including the fix in their own addon is a good idea, then SWStats will have an inline FixLogString, ParserLib has an inline FixLogString, Parser-3.0 has an inline FixLogString, along with 100 other addons which parse combat logs, now who should load first?

    I don't think "an addon should not break other addon whenever possible" is poltical,

    "if you don't follow my standard, I kill you" looks more political to me.
    Posted in: Libraries
  • 0

    posted a message on Parser-3.0 now has a Parser-1.1 compat layer
    Quote from Jerry »

    No. I don't think modifying these variable is supported, the fact is that it works, but the code that format the combat log strings is either taint-proof or more likely written in C.



    hmm, add FixLogStrings to OptDeps of the stand alone parsers then.

    This won't work with embedded parser, but most people shouldn't need this fix anyway, those who wants it can/should dis-embed the parsers. So I think it is good enough in the current form.

    Posted in: Libraries
  • 0

    posted a message on Parser-3.0 now has a Parser-1.1 compat layer
    Quote from Jerry »

    Maybe adding
    ## LoadWith: SW_FixLogStrings


    might be enough to make sure that FixLogStrings performs it's task before SW_FixLogStrings.


    It should work, but still I think the original author probably should be notified about this, since the code comes from him.

    Also, does modifying combat logs taint anything? I do have a private mod which modifies combat log and my UI seems to work fine, but I'm not 100% sure on that.

    Posted in: Libraries
  • 0

    posted a message on Parser-3.0 now has a Parser-1.1 compat layer
    Quote from Jerry »



    Been using this for quite some time, and I've never had an issue with it. So I'm pretty sure it does not break anything.


    If FixLogStrings is loaded after an addon which parse the GobalStrings then it might break the addon.

    as an example see http://ace.pastey.net/45382

    A solution is to have all those addons set FixLogStrings as an OptDeps, so it is guaranteed to load before those addons.

    But, if we use our own FixLogStrings, SWStats use its own FixLogStrings, then the first one to be loaded will still break the second one, so before we actually use this, I think we should ask author of SWStats first.
    Posted in: Libraries
  • 0

    posted a message on Parser-3.0 now has a Parser-1.1 compat layer
    Quote from Grayhoof »

    Correct me if I am wrong, but the way 3.0 works now is it basically overrides 1.1 completely. So if you have 3.0 and 1.1 installed, 3.0 will be used for everything. I understand the usefulness of this in that 1.1 written mods don't have to change anything, but I still think the mod authors should have the ability to choose which to use if both are installed.

    I agree it sucks having two Parsers running at the same time doing mostly the same thing, but I'm not sure the best way to move forward.


    I didn't write the compatible layer, but if it works correctly then I think we don't have to care.

    AFAIK, as the current way it works, if an addon is using 1.1, it doesn't have to change to 3.0. The compatible layer is for those who already use 3.0 and wants to only have 1 parser in memory, in that case, 1.1 mod authors don't have to care about 3.0.

    So unless you want to use 3.0 and its API, or you can just keep on using 1.1. Of course all those are under the assumption that the compatible layer works correctly, in case it has any bug, users will direct the complains to the 1.1 mod author, and it'll be hard as hell to find out the cause unless the user turn 3.0 off.



    Posted in: Libraries
  • 0

    posted a message on Parser-3.0 now has a Parser-1.1 compat layer
    Quote from Jerry »

    Quote from rophy »

    Instead of requiring addon to explicitly call the function, SW_FixLogStrings should actively fixes the combat logs patterns known to cause problems.


    Which means keep a database of patterns in SW_FixLogStrings, which is what I think the current design was trying to avoid.

    Quote from rophy »

    Having 2 addons trying to modify combat logs will cause even bigger problems, so duplicating SW_FixLogStrings should be avoided whenever possible, ask the author of SW_FixLogStrings to make it works nicer with other addons.


    As SW_FixLogString corrects metapattern known to be problematic, and not a known list of patterns, you can safely replicate it's logic so that SW_FixLogString has no effect if called after our library has modified the patterns and so that our library has no effect if loaded after SW_FixLogString has been called.

    An other option is to directly add the simple :
    local get_pattern
    do
     local SW_FixLogStrings
     function get_pattern (str)
      if SW_FixLogStrings == nil then
       SW_FixLogStrings = _G.SW_FixLogStrings or false
      end
      local s = _G[str]
      if SW_FixLogStrings then
       local n = SW_FixLogStrings(s)
       if s ~= n then
        _G[str] = n
        s = n
       end
      end
      return s
     end
    end


    to Parser-3.0 and Parser-1.1


    While I understand the design of the current SW_FixLogStrings,
    in my opinion, since SW_FixLogStrings is a stand-alone library, which job is to fix the problematic combat logs, then maintaining a list of problematic patterns, and actively fixes them probably can belong to its job too.

    This way the big bonus is you require no change to any addon/library which is known to incompatible with SW_FixLogStrings, the only requirement is to add SW_FixLogStrings as an OptDeps.

    Of course... explicitly supports SW_FixLogStrings in all parsers work too, but making SW_FixLogStrings more functional will be more friendly to other addons which have some tiny inline parsers.
    Posted in: Libraries
  • 0

    posted a message on Parser-3.0 now has a Parser-1.1 compat layer
    Quote from Jerry »

    is the following supposed to be working with Parser-3.0 alone ?
    /script Parser30Frame:OnEvent("CHAT_MSG_SPELL_BREAK_AURA", AURADISPELOTHER3:format( "Roger's Pet", "Roger's Buff", "Mob's Pet", "Pet's Spell")


    Because it doesn't. Ambiguity is a small problem for enUS, but is a HUGE issue with frFR. Parser-3.0 broke ParserLib-based addons for me.

    Edit: the latest release does not seem to have this problem anymore, provided that I add the following line in Parser-3.0.toc :
    OptionalDeps: SW_Stats


    I used the same trick with ParserLib, because SW_FixLogStrings, part of SW_Stats package, transforms patterns and remove ambiguous cases.

    Maybe it would be a good idea to add SW_FixLogStrings's logic to Parser-3.0 or as another Library that Parser-3.0 and ParserLib would use, because without it, frFR parsing is severely broken.




    SW_FixLogStrings provides a function to modify the combat log patterns to fix the ambiguous patterns, which SW_Stats uses if it exists.

    Instead of adding such logic (modifying combat logs) to parser, I think SW_FixLogStrings should be changed in the way it modifies combat log. Currently it merely provides a function, the function modifies the global combat log pattern when SW_Stats calls it.

    Instead of requiring addon to explicitly call the function, SW_FixLogStrings should actively fixes the combat logs patterns known to cause problems.

    This way all other parsers have to do is to add SW_FixLogStrings as the OptDeps, if you have SW_FixLogStrings, then you got fixed combat logs. If an addon is known to break by SW_FixLogStrings, all you have to do is to add SW_FixLogStrings as OptDeps, and not SW_Stats.

    May be suggest that to the author of SWStats? Having 2 addons trying to modify combat logs will cause even bigger problems, so duplicating SW_FixLogStrings should be avoided whenever possible, ask the author of SW_FixLogStrings to make it works nicer with other addons.

    btw Parser-1.1 works without adding SWStats as OptDeps, as a side effect of the load-on-demand patterns. If you have SWStats loaded, the patterns from ParserLib are loaded after SW_FixLogStrings fixes them.

    Posted in: Libraries
  • 0

    posted a message on Parser-3.0 now has a Parser-1.1 compat layer
    Quote from Rabbit »

    Quote from Astaldo »

    So this is like an attempt to deprecate and eventually obsolete Parser-1.1?
    Or what's the future of Parser-1.x? (which as I understand is maintained and suffers no outstanding issues at the moment)


    You're right, it works fine.

    The only "problem" is that the API is a bit hard to work with, but that doesn't justify spending hours and hours of work to get Parser-3.0 in a working condition.


    I have to state that, while the filters in 3.0 is nice, it requires raid unitid info - without unitid you can't really have much input for the filters except 'player', and you dont get unitid from combat log, so 3.0 embedded a RosterLib, which I personally don't think is a good idea - why should a parser try to guess the unitid from names?

    Since the core algorithm is the same, I personally see Parser-3.0 as Parser-1.1 + RosterLib, and adding a filter layer API after having unitid info. While these two libraries work as a great combo, one can easily make a filter layer on top of 1.1 easily by reusing RosterLib and Parser-1.1, instead of rewriting one with 2 combined, the result is only 1 parser in your UI, which was one of the main objective for me to make a generic parser.

    A generic parser IMO shouldn't try to do things which it shouldn't, stealing the job of RosterLib being one big example. So while 3.0 is nice, it doesn't fit my personal definition of a generic combat log parser, and so I'll still maintain 1.1.

    I do not discourage anyone to use 3.0 though. It's good and well written, it also tries to do some common and useful tasks which Parser-1.1, with the goal of being a low level generic parser, will never support, overheals and raid unitid being some examples.
    Posted in: Libraries
  • 0

    posted a message on Violation
    damage done from raid member to raid member probably shouldn't be counted.

    or I can out DPS everyone by spamming hellfire.
    Posted in: General AddOns
  • 0

    posted a message on KTM/Threat Meters for Ace?
    Quote from FlareCDE »

    Extra aggro talents are only important for tanks (so, warrior, paladin, druid), and I think there's only one each? Abilities like shield spec and devastate are obvious from the chat log. Subtlety is local, so you only need to worry 'bout your own. I'm all for the "use your Blizzard given right to use the chat channel" over making an addon do excessive communication for you.

    No reason for a rogue to be tracking hunters, or a mage to be tracking warlocks, except for the paranoid raid leader (someone I couldn't care less about). Tanks are not DPS ;).



    I'm mainly talking about the performance of the threat meter, because first I read 'Any threat meter will be very inefficient', and then we started discussing on how to make a 'much more efficient and elegant' threat meter by only tracking player and tank threats.

    Although I haven't used KTM for a long time already, afaik KTM only tracks the player's threat.

    But unless you don't take spell, talent, stance into account, I don't see which part of KTM can be removed except may be the display, where the display is just a syncing bar view with only one value, which is no different to Violation, I don't see how such view can make the mod inefficient.

    Posted in: Raid AddOns
  • 0

    posted a message on KTM/Threat Meters for Ace?
    Quote from tekkub »

    Yea, I love the idea of giving people a simple baseline comparison. Just take everyone's values and standardize it against the highest MT threat. So the MT gets 1.0, an overnuker would get a 1.2, a good off tank is at 0.9, and a good nuker is at 0.7 or so. It seems a much simpler solution, and in the end would probably be much more elegant code.


    Where do you get this 'value'? Directly computed from damage/healing done without considering talents / stances? Wouldn't that be too inaccurate?

    If the value takes talents / stances into account, then I think there is no difference to KTM?

    What I wanted to ask is , which part of KTM in your opinion can be removed to simplify the complexity of development?

    If an addon can calculate your threat and MT's threat, then the addon already have the ability to do the same thing on the whole raid. For the numbers, 1.0 vs 0.7 is no difference to 1412312 vs 51312.
    Posted in: Raid AddOns
  • 0

    posted a message on KTM/Threat Meters for Ace?
    Quote from Anias »

    The other choice is to setup a scrolling combat text for a designated player, but if such a thing exists I haven't found it.


    • Get SimpleCombatLog
    • Create a new ChatFrame by Blizzard UI
    • Disable all chat events on that ChatFrame by Blizzard chat menu
    • load 'default' theme on that ChatFrame in SCL theme menu
    • disable 'player' unitid for all type of mesages in the SCL filter menu
    • enable the name you want to watch in the SCL watch menu, both source and victim

    Now you have a ChatFrame with combatlogs for a designated player, I hope that helps.
    Posted in: Raid AddOns
  • 0

    posted a message on ClassTimer - Official thread
    in 2.1, the buffs/debuffs will show how much longer they last in a style similar to spell cooldown animation, and ClassTimer is an alternative display of the buff/debuff durations, right?

    Instead of adding bars which takes extra place, may be another approach is to show the remaining seconds directly on the debuff icons?

    May be someone can create a mod like OmniCC, which adds remaining seconds globally to all the buff and debuff icons? This is off-topic though.

    Edit: Tried on test server and OmniCC already works for debuff icons since debuff icons also used the CooldownFrame_SetTimer() function, which OmniCC hooks.
    Posted in: General AddOns
  • 0

    posted a message on Epeen - PvP Statistics and KoS System
    Working fine for me.
    Posted in: General AddOns
  • 0

    posted a message on EavesDrop 2.0 (a SCT style combat log)
    Quote from Grayhoof »

    imarkon, I'm not sure on dark pact. Do you get a combat log event for it? As for the blank lines, there is currently no way to remove them and its not high on my priority list. Could can always hide the frame itself and then won't notice them =)


    hi Grayhoof, if EavesDrop is using ParserLib, I believe dark pack belongs to "leech", while life tap belongs to "gain".

    Combat log info from http://www.wowwiki.com/Patterns_fired_from_each_CHAT_MSG_events :

    SPELLPOWERLEECHOTHEROTHER
    * %s's %s drains %d %s from %s. %s gains %d %s.
    * Magosko's Dark Pact drains 250 Mana from Bizmir. Magosko gains 250 Mana.

    ParserLib info from http://www.wowace.com/wiki/Parser-1.1#leech :

    leech

    * Your Drain Mana drains 140 Mana from Mage. You gain 140 Mana.
    o source : ParserLib_SELF
    o victim : "Mage"
    o skill : "Drain Mana"
    o amount : 140
    o attribute : "Mana"
    o sourceGained: ParserLib_SELF
    o amountGained: 140
    o attributeGained: "Mana"

    Posted in: General AddOns
  • To post a comment, please or register a new account.