• 0

    posted a message on Low-quality tickets from Curse Client
    There is a marked difference in the quality of tickets that I receive from the Curse Client versus tickets that I receive through the project website:
    Would it be possible for the Curse Client to just open up a link to the project website's ticket manager page instead of directly submitting a ticket? That would have the advantage of using the ticket template that I've set up for my project.
    Posted in: General Chat
  • 0

    posted a message on Licensing
    Yes, wherever the license.txt file should be included in the directory tree to ensure that license compliance is easy, it should be there.
    Posted in: General Chat
  • 0

    posted a message on Licensing
    My point is just that it's bad in a legal sense because Curse is hosting and distributing addons that don't comply with the licenses on the software.

    Thankfully the solution is fairly straightforward, especially since all WoW addons are source distributions. You could even have the Curse packager fail to create a ZIP file for the addon if there is no LICENSE.txt file in the root directory of the addon, even if the contents of the file are a bare "All rights reserved."
    Posted in: General Chat
  • 0

    posted a message on Licensing
    Quote from Phanx
    I don't think the packager extracting the license is a good solution, as it won't work for libraries that aren't hosted on Curse.


    Yes, that's true. We should strive for the simplest approach that gets it right in the most cases. Either including the license in each of the LUA files or having a license.txt file in the root addon directory is the simplest approach. At the very least, there should be a short header in each LUA file that has the copyright information and a note that the contents are licensed for use under which license, e.g.,
    --[[----------------
        Copyright (C) 2011, 2012 Author Name
    
        This program can be redistributed and/or modified under the terms of the
        LICENSE file included with this program.
    ----------------]]--
    Posted in: General Chat
  • 0

    posted a message on Licensing
    As an addendum, for addon packages that are uploaded by the authors, the authors should bear the responsibility of correctly complying with the licenses for the library addons they use. Just to make casual compliance simpler, it would still be best if library repositories had a LICENSE file at the root of each addon directory.
    Posted in: General Chat
  • 0

    posted a message on Licensing
    I'm wondering if the addon packages that created by the packager conform to the licenses that apply to the library addons. For example, the Ace3 library addons are licensed under a modified BSD license that requires that all source distributions retain the Ace3 copyright notice and a standard disclaimer. However, in inspecting a random addon in my WoW Interface folder that uses the Ace3 libraries, there is no presence of either the copyright notice or the disclaimer.

    I don't know if it's the responsibility of the addon author to include the appropriate files. The Curse packager is the entity that pulls the various bits out of external repositories and stitches together a complete package for redistribution. I think either the packager should extract the licenses for the various libraries and add them to a default "License" folder, or the library authors should simply include a LICENSE file that gets checked out along with the library code that makes the resultant package correct satisfy the terms of the license.
    Posted in: General Chat
  • 0

    posted a message on Determining if a player knows a spell?
    I've discovered another hiccup with this approach. For a Guardian druid with the Incarnation talent, the spell Incarnation turns into "Incarnation: Son of Ursoc". However, I get the following results:

    GetActionInfo(64) -> "spell", 102558, "spell"
    GetSpellInfo(102558) -> "Incarnation: Son of Ursoc"
    GetSpellInfo("Incarnation: Son of Ursoc") -> empty result
    GetSpellInfo("Incarnation") -> "Incarnation: Son of Ursoc"

    When I open up the spellbook, I definitely see "Incarnation: Son of Ursoc". This is a bit maddening.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Determining if a player knows a spell?
    As an addendum to that, the following seems to be more accurate:

    function HasSpell(id)
        local spell = GetSpellInfo(id)
        return spell == GetSpellInfo(spell)
    end

    This works in the situation where a talented spell replaces another spell from the spellbook, e.g., warrior's Impending Victory replaces Victory Rush.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Determining if a player knows a spell?
    Thank you for that solution, Adirelle. That seems to do the trick.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Determining if a player knows a spell?
    IsPlayerSpell() doesn't seem to give a consistently correct answer either.

    For a Guardian spec druid sitting in bear form, if I drag the Berserk spell to my action bar, I get the following:

    GetActionInfo(13) -> "spell", 50334, "spell"
    IsPlayerSpell(50334) -> false
    IsSpellKnown(50334) -> false

    So GetActionInfo() is telling me that the ID of the Berserk spell is 50334, but the other two function results tell me that 50334 is not a valid spell to cast.

    This is quite frustrating.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Determining if a player knows a spell?
    I'm trying to find a way to correctly answer the question of whether a given spell ID is known to the player.

    IsSpellKnown() would seem to be the right way to do this, but it returns false for spells that overwrite other spells due to talents, e.g., Immolate overwrites Corruption for destruction warlocks.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Grid — compact party/raid unit frames
    A have a new feature request that I'd like to bounce off the forums. By default Grid tracks auras by name, which works well except for when Blizzard allows for two auras with the same name. It's especially bad when one player can have both auras at the same time. In the case of Deep Corruption (in the Yor'sahj boss fight in Dragon Soul), the debuff that shows time left has spell ID 105717 and the one that shows stacks has spell ID 103628.

    I'd like to augment the aura statuses with an additional advanced option that allows for listing the spell IDs that correspond to the aura name. It would be a text input box where a comma-separated list of spell IDs can be entered.

    The important change to support this feature is in ScanUnitAuras(event, unit). Currently, it loops over the buff names we are tracking and calls UnitAura() to get the buff corresponding to that name on the unit in order the process the information. It then loops over all of the debuffs on the unit and calls UnitAura() for each one to see if it matches a debuff we are tracking in order to process the information. The change would be that to support the spell ID feature, if it is non-empty for any of the enabled statuses, then instead of looping over the buff names we track and seeing if it's on the unit, we would loop over all of the buffs on the unit and see if each of them matches one that we track. In the default case where the spell ID list is empty for all of the enabled statuses, we keep the current code.

    Having this feature would definitely make healing Yor'sahj a lot easier. I care about the stacking debuff, so I could add a "Deep Corruption" debuff and augment with a spell ID list of "103628" and bind that to a text indicator.

    Thoughts?
    Posted in: Grid & Grid2
  • 0

    posted a message on [Grid] GridStatusAbsorbs
    GridStatusAbsorbs is a Grid plugin that provides the following statuses:
    • Absorbs: Damage shows the amount of incoming damage that can be absorbed by buffs.
    • Absorbs: Healing shows the amount of incoming healing that will be absorbed by debuffs.
    GridStatusAbsorbs scans buff and debuff tooltips to determine the remaining absorb values.

    Currently, the Absorbs: Damage status text is one color ("low") if the total absorb is less than 25% (configurable value) of the unit's max health, and another color ("high") if it's over that value.

    I'd appreciate comments or suggestions for how to improve the usability of the addon in a raiding situation.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid — compact party/raid unit frames
    I have been doing proof-of-concept in a separate addon so far, so I will just fill out the code and release it as a separate GridStatusShields addon.

    On another note, the changes I made to the aura code to use a resource pool seem to have fixed the performance issues I was having in 25-man LFR. I have tested on two toons and the memory usage is very stable. I believe it is safe to tag another release from the trunk.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid — compact party/raid unit frames
    I'm wondering about implementing a new feature in the GridStatusAuras code as an enhancement to the duration aura code, and I would like some feedback about whether it's appropriate to have in Grid core, or to put it in a separate Grid addon.

    I would like to add another option to show the shield size of shield buffs, e.g., Power Word: Shield, Divine Aegis, Illuminated Healing, etc. The modification would be for buffs for which this option is enabled, we would examine the buff tooltip and extract the number from the tooltip. We would also store the cumulative shield size and enable it to be shown as another status "Buff: Total Shield Size" (disabled by default).

    To ensure that this doesn't have a performance impact on people who don't use this feature, we would only examine tooltips if the "Total Shield Size" status was enabled, or if the individual shield buff/debuff was enabled and the status text was "Shield Size".

    The reasons I want to put it in the GridStatusAura code are:

    1. Prevent a separate loop over all of the buffs/debuffs on each unit since GridStatusAura already does this.
    2. I think it fits neatly into the existing aura code to add another "Shield size" status text option, along with "Time left" and "Stack count" options we have now.

    The reasons why I would want to put this in a separate Grid addon, despite the performance penalty of a whole separate loop over buffs:

    1. The configuration is non-obvious because it's all off by default.
    2. Inadvertently enabling one of the shield statuses, even if not tied to an indicator, would still pay the performance penalty of scanning the tooltips.

    Thoughts?
    Posted in: Grid & Grid2
  • To post a comment, please or register a new account.