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:
- Registered User
Member for 11 years
Last active Fri, Jun, 21 2019 21:07:11
- 0 Followers
- 148 Total Posts
- 0 Thanks
Sep 20, 2012My 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.Posted in: General Chat
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."
Sep 20, 2012Posted in: General ChatQuote from PhanxI 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. ----------------]]--
Sep 19, 2012As 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
Sep 19, 2012I'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.Posted in: General Chat
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.
Sep 8, 2012I'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:Posted in: Lua Code Discussion
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.
Sep 8, 2012As an addendum to that, the following seems to be more accurate:Posted in: Lua Code Discussion
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.
Sep 8, 2012IsPlayerSpell() doesn't seem to give a consistently correct answer either.Posted in: Lua Code Discussion
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.
Sep 7, 2012I'm trying to find a way to correctly answer the question of whether a given spell ID is known to the player.Posted in: Lua Code Discussion
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.
Mar 22, 2012A 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.Posted in: Grid & Grid2
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.
Mar 12, 2012GridStatusAbsorbs is a Grid plugin that provides the following statuses:Posted in: Grid & Grid2
- 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.
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.
Mar 7, 2012I 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.Posted in: Grid & Grid2
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.
Mar 6, 2012I'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.Posted in: Grid & Grid2
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.
- To post a comment, please login or register a new account.