Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
I'll look into some better implementation. Can you explain how the dot ticks work after the initial hit. Do they have a fixed damage or the same range as the initial hit?
It does the full range of damage on-hit, then does additional full-range ticks 1 and 2 seconds later. Each of the 3 ticks (at 0, 1 and 2 seconds) is calculated independently via the same formula, and each can crit independently of the other ticks.
I'm not exactly sure how I'll work around this, I need to look into it. Have you asked from the Macaroon author as well?
No, have not brought it up with him yet. I've was out of town this past week, but wanted to at least mention it here so I didn't forget about it. I'll throw up a post over on wowinterface to ask about it and point him this way for more info.
From what I recall, it seems to be tied to which profile is currently loaded on login. If that's the case, I suppose a reload of the UI may correct for it after a talent swap for the time being... I'll have to try this out and see.
Edit: OK, brought it up in the Macaroon thread over on wowinterface here as well now.
Using r1076 on WoW 3.2.2 enUS, my action bar numbers are all showing zero for my Hunter in either MM or SV spec. Didn't have time to check on any other toons.
Also: armor penetration calculations have changed across the board in 3.2.2 (not sure what the new numbers are), and Hunters' Volley coefficient has been increased from 0.0586 to 0.0837.
Using r1076 on WoW 3.2.2 enUS, my action bar numbers are all showing zero for my Hunter in either MM or SV spec. Didn't have time to check on any other toons.
Also: armor penetration calculations have changed across the board in 3.2.2 (not sure what the new numbers are), and Hunters' Volley coefficient has been increased from 0.0586 to 0.0837.
The numbers came back on their own at some point, not sure what was going on.
Well I think the issue is due to patches clearing game cache.. and after a cache clear DrDamage is unable to retrieve any weapon info on startup (as it takes up to 15 seconds for the server to provide it). Re-equipping the weapon or relogging will fix the issue, and it's only apparent after your cache has been deleted.
But to prevent this in the future, in case the original weapon scan was unable to retrieve info, I've set DrDamage to check it again after 10 seconds. That should solve the problem in most cases unless the server is heavily lagged, but I also don't want to set the delay very long as then the user is without any info for that period (during a load without any cache, if cache is available it works normally).
i really love drdamage, but i'm dying to for a means of "trying on" different talent specs. i had written a mod that connect talented templates to drd a while back, but drd only obeyed certain talents (those that aren't accounted for in the generic base stats) so the project was kind of pointless.
i know you've stated you have no desire to mimic the base stat calcs, but would you be open to a slight reconfiguring of the system to allow a separate mod to plug into the core to achieve that? what i'm thinking is that you could make the api calls a bit more hookable. realizing i'm not totally familiar with the drd code, what i'm thinking is you could have something like:
drd:GetBaseStat(stat, spellid)
spellid would be the current spellid in question (and might not even be considered by the function)
stat would be whatever base stat is interesting from "str" to "spellpower" to "armor"... not that they'd all be interesting to drd...
drd's internal code for that function would simply be a table lookup based on the stat token. since drd deals with specific spell talents later in the pipeline, it would retun the true base stat.
what this would allow is another mod to come in and plug into drd very simply by intercepting that function to provide recalculated base stats from proposed talent specs (using talented or maybe even the blizz api at this point since you can set talents and then accept them when done). i'm thinking the effort to recalculate would probably not be too great given that you have a simple means of verification -- the actual values from the api.
it would be so cool to be able to use a talent calculator and see what the net effect is on my different spells given my current gear. take a point from this and put it in that and now what do i get?
i really love drdamage, but i'm dying to for a means of "trying on" different talent specs. i had written a mod that connect talented templates to drd a while back, but drd only obeyed certain talents (those that aren't accounted for in the generic base stats) so the project was kind of pointless.
i know you've stated you have no desire to mimic the base stat calcs, but would you be open to a slight reconfiguring of the system to allow a separate mod to plug into the core to achieve that? what i'm thinking is that you could make the api calls a bit more hookable. realizing i'm not totally familiar with the drd code, what i'm thinking is you could have something like:
drd:GetBaseStat(stat, spellid)
spellid would be the current spellid in question (and might not even be considered by the function)
stat would be whatever base stat is interesting from "str" to "spellpower" to "armor"... not that they'd all be interesting to drd...
drd's internal code for that function would simply be a table lookup based on the stat token. since drd deals with specific spell talents later in the pipeline, it would retun the true base stat.
what this would allow is another mod to come in and plug into drd very simply by intercepting that function to provide recalculated base stats from proposed talent specs (using talented or maybe even the blizz api at this point since you can set talents and then accept them when done). i'm thinking the effort to recalculate would probably not be too great given that you have a simple means of verification -- the actual values from the api.
it would be so cool to be able to use a talent calculator and see what the net effect is on my different spells given my current gear. take a point from this and put it in that and now what do i get?
Your idea is interesting and I think I've stated before that anyone wanting to make a plugin for this kind of purposes has my support. As I currently don't any longer have that much time to work on the addon I would want to make the needed changes as simple as possible. Actually, I've already added support for outside calculation modification quite a while ago, but since nobody has expressed actual interest for writing a plugin to use this functionality, it's currently commented out and I think it's only available in the caster module. It's not exactly what you proposed but it could work for your purposes.
The caster module is setup to receive a global modification table for setting base values or modifying base values of calculation variables. If you look at the current Caster.lua lines 718-752. This was implemented just as a proof of concept and I'm sure it can be improved, so please give suggestions. Also I'm not actually certain it meets your needs as I haven't looked into that much.
Please tell me what you think and I hope we can make this work :)
i'm a little vague on the exact pathway drd uses to calculate, but what i'm thinking could be done would be as simple as making the api calls to things like GetTalentInfo and GetSpellBonusDamage interceptable so that a custom module could be introduced that would calculate things based on its own system (like preview talents vs actual talents).
i figured rolling all those calls into a single call would be good just to simplify the hooking process (you'd need to intercept all of them or none of them since talents can affect base stats).
drd's own default function would simply call the appropriate base wow api call to provide the "live" data. right now, you're calling those functions directly -- this would just add a layer of indirection that could be exploited.
but if an even simpler approach was needed, then you could just do this:
local DrDamage = DrDamage
...
local GetSpellBonusDamage = GetSpellBonusDamage
...
calculation.spellDmg = healingSpell and GetSpellBonusHealing() or GetSpellBonusDamage(schoolTable[calculation.school] or 1)
becomes:
local DrDamage = DrDamage
...
DrDamage.GetSpellBonusDamage = GetSpellBonusDamage
...
calculation.spellDmg = healingSpell and DrDamage.GetSpellBonusHealing() or DrDamage.GetSpellBonusDamage(schoolTable[calculation.school] or 1)
so you'd simply stuff those global wow api function right into the your drd table and call them from there.
this would let a mod go in and hook whatever it wanted. drd wouldn't really even know or care about it. theoretically, you could even adjust toon levels and spell availability.
i don't know how the modification stuff really works, but it seems to be modifying the current values which would be kind of a backwards way to get where i'd like to go. it would require "undoing" the current talents and then redoing the new ones rather than just recalculating base stats from scratch.
i don't know how the modification stuff really works, but it seems to be modifying the current values which would be kind of a backwards way to get where i'd like to go. it would require "undoing" the current talents and then redoing the new ones rather than just recalculating base stats from scratch.
Not that your idea doesn't have merit, but simply adding a "Set = true" key in the modification table allows you to set all base values instead of modifying the existing values, which I could make the default just as well if that's easier, since not anything else uses the code :)
*EDIT*
Let me elaborate a bit, so for example the idea is:
This would set the fire school base spell damage to 1080 and crit chance to 30.5%. And shadow school base spell damage to 1300 and crit chance to 35%.
The function also supports overriding abilities, the priority is spell school < spell type < spell name. So anything related to the specific spell will override the other setting if you use the Set = true attribute. Without the Set = true attribute the override function will add to the base value.
- This would set the fire school to base 1080 spelldamage and 30.5% crit
- Destruction spells would override the default spell damage and use 1300 spelldamage, even if they're fire school (but they'd still use 30.5% crit if they're fire destruction spells)
- Conflagrate would use 1500 base spell damage and a 40% crit and a 2.3 second cast time (just as an example).
- This would set the fire school to 1080 spell damage and Conflagrate would use 1180 spell damage.
After this base modification talents handled by DrDamage are calculated on top of this normally, which you can feed into DrDamage (I can improve support of that if needed)
*EDIT2*
This would be easier if you'd get on IRC for example, then we can custom tailor whatever you need.
1x DrDamage-1.7.2_release\Melee.lua:454: Usage: GetItemInfo(itemID|"name"|"itemlink")
DrDamage-1.7.2_release\Melee.lua:454: in function `Melee_InventoryChanged'
DrDamage-1.7.2_release\DrDamage.lua:949: 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'
AceEvent-3.0-3 (Ace3):120: in function <Ace3\AceEvent-3.0\AceEvent-3.0.lua:119>
---
1x DrDamage-1.7.2_release\Melee.lua:454: Usage: GetItemInfo(itemID|"name"|"itemlink")
DrDamage-1.7.2_release\Melee.lua:454: in function `Melee_InventoryChanged'
DrDamage-1.7.2_release\DrDamage.lua:949: 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'
AceEvent-3.0-3 (Ace3):120: in function <Ace3\AceEvent-3.0\AceEvent-3.0.lua:119>
---
This code hasn't been touched for several versions and I've never seen or heard about this error happening before. This shouldn't technically even be happening but I've added an additional check to make sure it doesn't :)
Out of interest, did you get it more than once?
Download the latest alpha r1166 or newer for the fix:
What's been happening with the update texts for each new build? It's become increasingly difficult to find what is changing between each alpha, to decide if it's worth grabbing it to test out.
(eg, old builds showed each change and to which files; new builds only seem to show the latest beta/release summary, maybe occasionally adding something to that list)
I guess LibQTip would warrant some testing then.. now I only need to figure out how to do that without a subscription..
Check out the tooltip: http://www.wowhead.com/?spell=60053
It does the full range of damage on-hit, then does additional full-range ticks 1 and 2 seconds later. Each of the 3 ticks (at 0, 1 and 2 seconds) is calculated independently via the same formula, and each can crit independently of the other ticks.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorAre you signed up to receive Curse Points? If not, do it - your addons could end up paying for the subscription.
A very big big big big big Thank to Gagorian and the 3 guys of his team!
No, have not brought it up with him yet. I've was out of town this past week, but wanted to at least mention it here so I didn't forget about it. I'll throw up a post over on wowinterface to ask about it and point him this way for more info.
From what I recall, it seems to be tied to which profile is currently loaded on login. If that's the case, I suppose a reload of the UI may correct for it after a talent swap for the time being... I'll have to try this out and see.
Edit: OK, brought it up in the Macaroon thread over on wowinterface here as well now.
Also: armor penetration calculations have changed across the board in 3.2.2 (not sure what the new numbers are), and Hunters' Volley coefficient has been increased from 0.0586 to 0.0837.
Edit: ArP info: http://blue.mmo-champion.com/28/19717353372-armor-pen-nerf-in-322.html
On my test hunter numbers were visible as they should, so I'm not exactly sure what the issue is about. Have you tried re-equipping your weapon?
Well I think the issue is due to patches clearing game cache.. and after a cache clear DrDamage is unable to retrieve any weapon info on startup (as it takes up to 15 seconds for the server to provide it). Re-equipping the weapon or relogging will fix the issue, and it's only apparent after your cache has been deleted.
But to prevent this in the future, in case the original weapon scan was unable to retrieve info, I've set DrDamage to check it again after 10 seconds. That should solve the problem in most cases unless the server is heavily lagged, but I also don't want to set the delay very long as then the user is without any info for that period (during a load without any cache, if cache is available it works normally).
I'll still add the LDB config launcher later today.
*EDIT*
Added in 1.7.1_beta-2.
i know you've stated you have no desire to mimic the base stat calcs, but would you be open to a slight reconfiguring of the system to allow a separate mod to plug into the core to achieve that? what i'm thinking is that you could make the api calls a bit more hookable. realizing i'm not totally familiar with the drd code, what i'm thinking is you could have something like:
drd:GetBaseStat(stat, spellid)
spellid would be the current spellid in question (and might not even be considered by the function)
stat would be whatever base stat is interesting from "str" to "spellpower" to "armor"... not that they'd all be interesting to drd...
drd's internal code for that function would simply be a table lookup based on the stat token. since drd deals with specific spell talents later in the pipeline, it would retun the true base stat.
what this would allow is another mod to come in and plug into drd very simply by intercepting that function to provide recalculated base stats from proposed talent specs (using talented or maybe even the blizz api at this point since you can set talents and then accept them when done). i'm thinking the effort to recalculate would probably not be too great given that you have a simple means of verification -- the actual values from the api.
it would be so cool to be able to use a talent calculator and see what the net effect is on my different spells given my current gear. take a point from this and put it in that and now what do i get?
Your idea is interesting and I think I've stated before that anyone wanting to make a plugin for this kind of purposes has my support. As I currently don't any longer have that much time to work on the addon I would want to make the needed changes as simple as possible. Actually, I've already added support for outside calculation modification quite a while ago, but since nobody has expressed actual interest for writing a plugin to use this functionality, it's currently commented out and I think it's only available in the caster module. It's not exactly what you proposed but it could work for your purposes.
The caster module is setup to receive a global modification table for setting base values or modifying base values of calculation variables. If you look at the current Caster.lua lines 718-752. This was implemented just as a proof of concept and I'm sure it can be improved, so please give suggestions. Also I'm not actually certain it meets your needs as I haven't looked into that much.
Please tell me what you think and I hope we can make this work :)
i figured rolling all those calls into a single call would be good just to simplify the hooking process (you'd need to intercept all of them or none of them since talents can affect base stats).
drd's own default function would simply call the appropriate base wow api call to provide the "live" data. right now, you're calling those functions directly -- this would just add a layer of indirection that could be exploited.
but if an even simpler approach was needed, then you could just do this:
becomes:
so you'd simply stuff those global wow api function right into the your drd table and call them from there.
this would let a mod go in and hook whatever it wanted. drd wouldn't really even know or care about it. theoretically, you could even adjust toon levels and spell availability.
i don't know how the modification stuff really works, but it seems to be modifying the current values which would be kind of a backwards way to get where i'd like to go. it would require "undoing" the current talents and then redoing the new ones rather than just recalculating base stats from scratch.
Not that your idea doesn't have merit, but simply adding a "Set = true" key in the modification table allows you to set all base values instead of modifying the existing values, which I could make the default just as well if that's easier, since not anything else uses the code :)
*EDIT*
Let me elaborate a bit, so for example the idea is:
DrDamage.CasterGlobalModify = { ["Fire"] = { ["spellDmg"] = 1080, ["critPerc"] = 30.5, Set = true }, ["Shadow"] = { ["spellDmg"] = 1300, ["critPerc"] = 35, Set = true }, }This would set the fire school base spell damage to 1080 and crit chance to 30.5%. And shadow school base spell damage to 1300 and crit chance to 35%.The function also supports overriding abilities, the priority is spell school < spell type < spell name. So anything related to the specific spell will override the other setting if you use the Set = true attribute. Without the Set = true attribute the override function will add to the base value.
DrDamage.CasterGlobalModify = { ["Fire"] = { ["spellDmg"] = 1080, ["critPerc"] = 30.5, Set = true }, ["Destruction"] = { ["spellDmg"] = 1300, Set = true }, ["Conflagrate"] = { ["spellDmg"] = 1500, ["critPerc"] = 40, ["castTime"] = 2.3, Set = true }, }- This would set the fire school to base 1080 spelldamage and 30.5% crit- Destruction spells would override the default spell damage and use 1300 spelldamage, even if they're fire school (but they'd still use 30.5% crit if they're fire destruction spells)
- Conflagrate would use 1500 base spell damage and a 40% crit and a 2.3 second cast time (just as an example).
DrDamage.CasterGlobalModify = { ["Fire"] = { ["spellDmg"] = 1080, Set = true }, ["Conflagrate"] = { ["spellDmg"] = 100 }, }- This would set the fire school to 1080 spell damage and Conflagrate would use 1180 spell damage.After this base modification talents handled by DrDamage are calculated on top of this normally, which you can feed into DrDamage (I can improve support of that if needed)
*EDIT2*
This would be easier if you'd get on IRC for example, then we can custom tailor whatever you need.
This code hasn't been touched for several versions and I've never seen or heard about this error happening before. This shouldn't technically even be happening but I've added an additional check to make sure it doesn't :)
Out of interest, did you get it more than once?
Download the latest alpha r1166 or newer for the fix:
http://www.wowace.com/addons/dr-damage/files/
Shadow Cleave http://www.wowhead.com/?spell=50581
Immolation http://www.wowhead.com/?spell=50589
Immolation scales with spell pwr.
Im not sure about Shadow Cleave, but it is like maul, where it pops on your next melee strike.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium(eg, old builds showed each change and to which files; new builds only seem to show the latest beta/release summary, maybe occasionally adding something to that list)