Note that abilities in the Mr. Robot rotation like blood fury or trinket uses or heroism will not trigger unless you have the required gear, race, or raid buffs. The default just puts a bunch in there as a convenience -- they'll execute only when appropriate.
Another thing to note -- I don't have haste potions implemented yet, so I left that out of both rotations.
I realize that putting time-to-live conditions in will definitely increase DPS. I left them out of both rotations for now, so the comparison between the two should still be valid.
It seems that there are definitely some differences in the decision engines used by the Mr. Robot simulator and SimC. I find it interesting that trying to do the SimC rotation in Mr. Robot loses about 300 DPS, but doing the Mr. Robot rotation in SimC loses about 600 DPS. Would be nice to figure out what each simulator is doing differently.
I did these tests on my current gear, which is not optimal. I'll try making a rotation that uses 4T10 and BiS gear, see if a different priority is optimal in that case. As you have suggested, I would expect favoring higher rake up-time to be desirable with 4T10.
As for rip up-time, I find that there is a trade-off between rip and the number of ferocious bites that you use. This tipping point does not seem to be constant for all ferals, and probably needs to be tweaked to the individual player to get optimal DPS. Letting rip drop here and there isn't that huge a deal, as long as it's not for too long. One ferocious bite is usually worth about 4-5 ticks of rip, so if you're losing less than that to get off an FB, you're coming out ahead.
I did a comparison between the SimC rotation and the Mr. Robot rotation using both simulators and my character (Yellowsix). I don't have optimal gear of course -- I'll do a BiS simulation later today when I have time. But here's the results:
(I did 1000 iterations of 300 second fights, with gcd_lag set to 50ms in both simulators)
I removed all "time to live" conditions from all cases. I also removed potions.
SimC:
SimC rotation: 9211 DPS
Mr. Robot rotation: 9093 DPS
Mr. Robot:
SimC rotation: 8910 DPS
Mr. Robot rotation: 9035 DPS
It seems that there is some amount of "gaming" the simulator that can be done to produce optimal results with both simulators: the SimC rotation works better with SimC, and the Mr. Robot rotation works better with Mr. Robot. Nevertheless, the results are all pretty close considering that the code and design of each simulator is completely independent.
I'll do a BiS comparison later, which I assume will require a slightly tweaked rotation.
Do you implement any kind of energy pooling? If you don't, then you'll never have over 42 energy (except right after using TF). Whereas the SC profile often ends up over this value, frequently up to 70 or higher with OoC procs. The TTL codes are to make sure you don't have energy you could have used at the very end of the fight. If you get one more 10k shred in, you get another 33 DPS for the fight. The real difference is probably 20 DPS on average.
I haven't personally seen a large difference between T10 BiS and everything else-- the numbers slightly change when going from soft ArP cap to hard ArP cap (from ~6 seconds left on Rip to ~8-10 seconds left on Rip) but that's less about T10 and more about the ArP. Before 4T10, shred can overcome Rake at ArP cap, eliminating it from the sequence.
I don't think that we're quite communicating Allev...
Firstly, if you run a SimC simulation or a Mr. Robot simulation, using either of the rotations posted above, you will see a roughly similar breakdown of ability usage, and a roughly similar DPS output. If one simulation or the other were not implementing "energy pooling" as you say and allowing 42 energy to build up for shred, you could be sure that the differences would be a lot larger than +/- 100 DPS.
As far as I know, neither SimC nor Mr. Robot implement special "energy pooling" explicitly (correct me if I'm wrong) -- it's unnecessary. If you feed a priority-based simulator the proper priority logic, it will decide to wait until it meets the correct conditions to perform an action, one of those conditions being "do I have enough energy?"
Secondly, I have stated that I'm going to be adding TTL conditions in an upcoming update, because they do indeed increase DPS slightly. But only slightly. 1 extra FB in a 5-minute fight is hardly worth getting excited about. But since these conditions are not ready yet, when comparing SimC and Mr. Robot rotations, I have removed them. This will yield slightly less than "optimal" DPS, but it will yield a valid direct comparison of the two simulators.
And yes, at some point it is possible that it becomes inefficient to use Rake at all from a DPE perspective, if your ArP to AP ratio is high enough, and you don't have any of the Rake-enhancing set bonuses.
I'll be comparing SimC and Mr. Robot more extensively over the weekend, and see if I can discover why the Mr. Robot rotation performs almost the same in both simulators, but the SimC rotation swings 300 DPS between the two.
So, I got Mr. Robot to load here.
- It's really hard to see what's a DPS increase and what isn't when two simulation sessions with 1000 iterations end up varying by up to 100 DPS (well outside of expected error).
- You shred to 5 CP, constantly. This will lead to dropping Rake uptime a lot and dedicating more CP to FB than it's really optimal to do.
- The strategy of always shredding when not at 5 CP means that you're rarely conserving energy-- essentially, only when you're waiting for Rip to expire.
- You aren't even getting that many additional FBs-- loading my character, I only get 2.4% damage from my FBs.
- You may attack twice without an SR buff if you don't crit the first one. That's just a bad idea.
In other words, you're doing tons of things in your cycle that are logically sub-optimal. My guess is that the SC profile didn't get trans-coded properly to Mr. Robot, if all mechanics are functioning properly in each.
Edit: Something is wrong with the "Target missing SR or less than X seconds remain". With X = 8, a 4 CP SR is being refreshed after ~14 seconds. Either your SR length is computed wrong or the phrase simply isn't doing what it's designed to do. Is it triggering the "missing SR" after the 1-point SR has expired?
- It's really hard to see what's a DPS increase and what isn't when two simulation sessions with 1000 iterations end up varying by up to 100 DPS (well outside of expected error).
When I've been running at 1000 iterations with Yellowsix, I haven't seen the result fluctuating by more than 10-20 DPS in either direction, which is within the estimated margin of error... I don't claim to be a statistics wizard though. I'll try it with some different characters and cases, but as of now I cannot reproduce this behavior. I'll keep an eye on it.
- You shred to 5 CP, constantly. This will lead to dropping Rake uptime a lot and dedicating more CP to FB than it's really optimal to do.
This is just an assertion... I can't really do anything with this statement. So say I lose 10% rake uptime, which is about 10 ticks in a 5-minute fight. Why is it obvious that this is a problem? There are too many variables to just assert this as truth. Same for dedicating more CPs to FB... just saying that it is not optimal does not make it so... thus simulators! It would be better if you were to create a rotation with higher rake up-time and less FBs that does more damage, and show it to me.
- You may attack twice without an SR buff if you don't crit the first one. That's just a bad idea.
Same as above -- tell me why, or better yet, show me why with a custom rotation -- don't just assert that it is true, or I can't do anything with it. Let me try and think about this particular statement though... let's estimate this potentially bad scenario: I get 4 auto-attacks, 2 rip ticks, 1 rake tick, and 2 shreds without SR up. With Yellowsix, I would have done ~13,000 extra total damage had SR been up. So then the question becomes... what did I gain by allowing that gap in SR up-time? Say I gained one FB. My average FB damage is ~19,500. Thus, I gain 6,500 damage overall.
While I agree that gaps of SR downtime is probably a bad thing... it is not trivial to determine at what point 100% up-time is worth potentially sacrificing an extra FB during the fight.
Something is wrong with the "Target missing SR or less than X seconds remain". With X = 8, a 4 CP SR is being refreshed after ~14 seconds. Either your SR length is computed wrong or the phrase simply isn't doing what it's designed to do. Is it triggering the "missing SR" after the 1-point SR has expired?
I checked the code, and it was possible that an SR could be executed as if the player had less CPs than they actually had. I have fixed this, so this situation shouldn't happen anymore. Good catch.
The suggestions that I incorporated were changes to the shred condition to use it when berserk is up and there's nothing else to do, and also to keep higher rake up-time.
Also, I properly implemented the following condition in SimC into the Mr. Robot simulator:
SimC
SimC rotation: 9229 DPS
Mr. Robot rotation: 9173 DPS
Mr. Robot
SimC rotation: 8901 DPS
Mr. Robot rotation: 9325 DPS
So as before... there's something about the SimC rotation that is not translating into the Mr. Robot simulator quite right. I think that either the feral code or the energy-tracking code in SimC must be doing some behind-the-scenes magic. For example, you don't have to code into the rotation logic "don't apply a DoT if it's already up." This is not generally true for all classes, so I'm assuming that it's part of the feral code, not SimC as a whole. Also, SimC seems to be doing some kind of behind-the-scenes energy conservation in order to build up for berserk... Mr. Robot will not implicitly do this. I have lowered the energy threshold to 70 for the SimC rotation as implemented in Mr. Robot, which causes it to use berserk twice for me. Not ideal, but works for now.
Also, SimC does not seem to be modeling the on-use effect of Victor's Call, or else it has to be explicitly put into the rotation somehow, but I'm not sure how to do that.
First things first: Just because SimC was born before MrRobot does not mean SimC is "more" right.
The default behavior for DoTs is to NOT let them get overwritten..... however, with the introduction of the if= conditionals that is something in the process of being changed.
I would examine damage break-downs. How many of each type of ability is used? (on average, fractional values)
I would examine the rate of CP generation (and CPs "wasted" due to 5-stack).
I would also closely examine the rate of energy regen and how each sim "waits" for energy regen. SimC performs power-regen every 0.1sec by default. These are particular/arbitrary modeling decisions that could potentially have an unexpectedly large impact on DPS. When a player comes to the end of his action list with nothing to do, he "waits" for some period of time. I used to make this a super-tiny value but it was killing my performance. Now it is a function of current energy levels.
This is the function used to determine how far into the future to insert the next "player_ready" event when the player comes to the end of his action list.
double druid_t::available()
{
if( primary_resource() != RESOURCE_ENERGY ) return 0.1;
double energy = resource_current[ RESOURCE_ENERGY ];
if ( energy > 25 ) return 0.1;
return std::max( ( 25 - energy ) / energy_regen_per_second, 0.1 );
}
I'll add something to what dedmonwakeen said: just because Mr. Robot is new and shiny doesn't mean that it's trying to replace SimC or prove that SimC is wrong.
I think that the major takeaway from these comparisons of SimC and Mr. Robot is that both simulators are very close. Sure there are a few minor things to dig into and figure out, mainly with some probably minor differences in how each simulator decides which ability to use next, but on the whole, two independently-developed simulators are giving confirming results. This is a good thing for both simulators.
I ran into similar design issues dedmonwakeen: how long should I wait before checking again if I can't perform an action? I will double check that Mr. Robot isn't waiting too long to re-evaluate the condition logic. Whereas you had the issue of checking too often, I ran into the problem of not checking often enough and fixed it, but it's possible that I missed a case or two.
When I've been running at 1000 iterations with Yellowsix, I haven't seen the result fluctuating by more than 10-20 DPS in either direction, which is within the estimated margin of error... I don't claim to be a statistics wizard though. I'll try it with some different characters and cases, but as of now I cannot reproduce this behavior. I'll keep an eye on it.
This is just an assertion... I can't really do anything with this statement. So say I lose 10% rake uptime, which is about 10 ticks in a 5-minute fight. Why is it obvious that this is a problem? There are too many variables to just assert this as truth. Same for dedicating more CPs to FB... just saying that it is not optimal does not make it so... thus simulators! It would be better if you were to create a rotation with higher rake up-time and less FBs that does more damage, and show it to me.
Same as above -- tell me why, or better yet, show me why with a custom rotation -- don't just assert that it is true, or I can't do anything with it. Let me try and think about this particular statement though... let's estimate this potentially bad scenario: I get 4 auto-attacks, 2 rip ticks, 1 rake tick, and 2 shreds without SR up. With Yellowsix, I would have done ~13,000 extra total damage had SR been up. So then the question becomes... what did I gain by allowing that gap in SR up-time? Say I gained one FB. My average FB damage is ~19,500. Thus, I gain 6,500 damage overall.
While I agree that gaps of SR downtime is probably a bad thing... it is not trivial to determine at what point 100% up-time is worth potentially sacrificing an extra FB during the fight.
I checked the code, and it was possible that an SR could be executed as if the player had less CPs than they actually had. I have fixed this, so this situation shouldn't happen anymore. Good catch.
I've always had the fluctuating DPS problem-- maybe it's something specific with the gear my character is currently using (NES/DMC:G/Idol of Mutilation/Berserking enchant are the odd items).
Trading a higher DPE attack (i.e. Rake) for a lower DPE attack (i.e. shred) is clearly a good thing. Waiting for Rakes instead of shredding all the way until 5 CP is increasing your DPE, while simultaneously creating more CP than if you shredded (since it is less energy per CP).
The requiring 2 points to cast SR (in every circumstance) simply means that if SR falls, you can attack twice (instead of once) when starting your cycle. You aren't generating 5 extra CP by delaying using your SR. I'm really trying hard, and failing, to understand your logic on how this increases your DPS. I don't see any basis for a DPS increase unless you are trying to stabilize a healthy rotation; but you're throwing away roughly 1/4 of each attack by not having SR up already.
The building up energy in the SimC profile is completely done by not shredding unless you have a reason to do so. Shredding when berserk is up is one of those reasons; OoC, high energy, TF coming off cooldown, or needing more CP for a finisher are all good reasons. And this naturally gets us above thresholds to use Berserk and below thresholds to use TF.
I don't see MrRobot as a threat to SimC, and in fact I look forward to the time where your sim is as tested and robust as SimC is. But right now, I don't think it is approachable as a finished product when you're still uncovering fundamental mechanical bugs.
There is definitely some tweaking to do to the simulator, which is going to come with good discussions like this one. But, I think that we can approach Mr. Robot as more than just a beta at this point. Mr. Robot was not created purely as a simulator: it uses a simulator under the hood to achieve it's main purpose, which is gear comparison. We absolutely want to have these discussions to get the DPS numbers as accurate as possible, but, in the end, we care more about the relative value of gear.
Right now, Mr. Robot is accurately telling us which gear is an upgrade in 95% or more of cases - and that is just with the estimates. When you actually run the simulator it is giving us good results 99% of the time.
Tweaking the simulator is going to help us offer more features, such as enchant and gemming optimization, which require much higher accuracy.
You seem to be using resist values that include multiplicative damage bonuses. As in, if the total buffed value of a hit is 1000, you're showing Hit 900 (100 resisted). But the game applies some effects (not sure which ones, maybe all multiplicative damage effects?) after resists are calculated, and doesn't modify the resisted value correspondingly. So resist values in-game look smaller than they "should."
I'll look into that arawethion. If I read what you are saying correctly, you're saying that the combat log shows a smaller resist number than it should, but the overall amount of damage that is resisted should be the same. In other words, I'm doing:
[buffed damage] * 0.9 = [final damage] for a 10% resist, and I say that 0.1 * [buffed damage] = resisted amount.
But the game actual does something like:
[damage] * 0.9 * [damage multipliers] = [final damage] for a 10% resist, and 0.1 * [damage] = resisted amount.
In both cases [final damage] is the same, but the combat log reports different resist amounts.
I did the research on resists quite a while ago, and unfortunately I didn't keep track of my source for the information... I tried looking it up again when I started the moonkin, but couldn't find it.
Currently I use this table for resists:
0.5756 chance for full damage
0.3372 chance for 10% resisted
0.0872 chance for 20% resisted
Allev -- the main reason that I changed it to wait for 2pc instead of doing 1cp savage roars was completely empirical... the simulator does a little more damage if I do it that way. I have to dig into why, but my assumption is that it has something to do with the timing and lining up of finishers at some point, and waiting for 2 results in a different outcome. Either way, the difference in DPS is extremely small, almost within the margin of error. It is possible that another condition elsewhere in the rotation would produce the same result, and allow 1cp savage roars to work better.
All of the conditions that you mention for not shredding unless you have a reason to do so are in both the SimC and Mr. Robot rotations, with the exception of "TF coming off cooldown." I'll play around with that one and see if it makes a difference, though due to the limited circumstances it will be minor at best.
Also, while I agree that an ability that does more damage per energy is better, it is not immediately clear to me that DPE is the whole story. Your highest DPE attacks are your cp-consuming moves, no matter what your gear level is. If I get to the point where shred is higher DPE than rake and drop rake entirely, I'm now spending more total energy on cp-generating moves than cp-consuming moves. In other words, my combo points have become more expensive. Now the difference here is probably pretty small, and we're splitting hairs at this point. I tried a rotation without rake on a character that had 100% ArP, and thus a significantly higher DPE with shred, and total DPS was almost identical to a rotation that contained rake. Thus, I am lead to believe that this incongruity between cp-generators and cp-consumers makes it more complex than simply "use your highest DPE attack, amen."
The physical damage part of the simulator has not had a "fundamental mechanical bug" in quite a long time. The caster damage part is newer, and with the help of arawethion and erdulf's testing, has become much better over the last couple weeks.
I fixed a minor timing issue with savage roar that you found -- not "fundamental", just a bug with a single action. And the issue that I mentioned with checking for the next action at a different interval is not likely to make a huge impact... we're talking about checking on the order of 100 milliseconds earlier for a condition here. At this point it is more of a curiosity thing on my part, to see if I can translate a SimC rotation into a Mr. Robot rotation and consistently get a similar result. It is quite possible that due to the different design of the simulators, you will need slightly different conditions to produce the same attack pattern in each simulator.
Right what, I was describing only affects the amount resisted in the log, not the actual damage. Doing it your way actually makes it easier to see how much damage is lost to resists, but it doesn't match the in-game log.
Originally Posted by Yellowsix
I did the research on resists quite a while ago, and unfortunately I didn't keep track of my source for the information... I tried looking it up again when I started the moonkin, but couldn't find it.
Currently I use this table for resists:
0.5756 chance for full damage
0.3372 chance for 10% resisted
0.0872 chance for 20% resisted
I've been poking around on this question recently and don't think anyone has a really solid answer. This post is a good summary: General Mage Discussion and Information
He gets 6% here, which is what I've been using in WC. It also agrees with what I saw when I tested Nibelung. If you're not sure on your values, I'd just use the ones in his post until we get something better.
The rotation editor itself is a self-described alpha version. While you addressed the SR bug I found, what about the bug where SR wasn't working at all a few weeks back?
Intuitively, giving up damage is stupid. If your simulator says to do sething empirically stupid, isn't it more likely that you either have a bug, or the spec isn't right?
Thank you for agreeing that reducing rakes is a bad idea-- so why does your sim do it?
Finally-- the sim is probably fine for gear evaluation. But more important than gear (to me) is the specifications themselves-- an action list is effectively an interactive guide on how to play. You are right that we are talking about small margins, but those margins separate decent players from great ones.
I will continue to be skeptical, but that's actually a good thing-- I'm more likely to find bugs that way!
That guy's analysis seems pretty sound arawethion. Since I can't find the source anymore where I got my previous resist numbers, I'll use his distribution around a 6% average resist for spells. It looks like I was using a similar distribution, but probably around a slightly lower value like 5%.
I should probably take the "alpha" label off of the rotation editor. That was more of a PR thing. The rotation editor is a fully functional and tested part of the simulator, but we do not feel that its user interface is on par with the usability of the rest of the website. Thus, we called it an "alpha" to reflect this fact. It is a perfectly good power-user tool, we just never got to another round of UI improvements on it. You sort of have to think like a computer programmer to use it well.
I disagree-- as a programmer, it hurts my head.
- It's amazingly unreadable. All the buttons to click for "not" and "and" and "or" plus not actually typing anything makes it a pain to use.
- The icons might save space, but since they're so big, they hurt readability.
- no "or" at the top level.
- the "difference in time remaining on X and Y", to me, implies that it's an absolute value, but it's not. At the very least it's not really clear. I think "time left on X minus time left on Y" would be more clear.
Other bugs:
- Most feral theorycraft puts the ashen ring proc worth only a small amount of DPS because of its low procrate, making the exalted version not even BiS. Whereas MrRobot is rating the revered version as 250 DPS better than any other ring.
- Just overall, something is wrong with the cycle and your percent damages. Only the worst ferals I know reach 38% auto-attack damage (since you can't affect white damage except through SR, the white-to-yellow ratio is a good indicator of good play). The number should be in the 33-36% range, depending on ArP (my character should be around 34%, since I have decently high haste but am only soft-capped ArP).
- So I looked at your "empirically 1SR is better than 2SR" statement. It turns out, most of the difference disappears if I set the CP check after the SR check. Weird. Then, I looked at the SR check itself. I switched out the "NOT have >=1 stacks of SR" with "target missing SR or less than 1 sec remains" and ended up losing 50-100 or so DPS. My DPS varied depending on how many CP I had at that point, which means it didn't invalidate the line, it's just being interpreted wrong (since refreshing SR one second early wouldn't cause a 50 DPS drop). If that line is broken, then the SimC profile would be significantly broken since it uses it a few times.
I think what he meant Allev is that a programmer will most certainly have a good grasp on conditional "if/then" logic flow right away, while a lay person will probably struggle with that concept somewhat, at least without big happy buttons and icons or a detailed wizard or tutorial. In that way a programmer will be able to "use it well". I agree, as Yellowsix indicated, that it could stand to have some UI improvement, but it's certainly functional at this time, and better than just a simple text box for typing (probably proprietary) code for non-programmers.
Moonkin looking at Mr. Robot (extremely nice UI by the by) and seeing something a bit confusing.
Using default rotation in both cases, with (customized) raid buffs, DPS is about where I'd expect it to be; however, with the self buffs setup it is far lower than that. Self buffed is lower than what I see in WrathCalcs, Rawr, and what I know from experience I can do on a dummy. 8.2k raid buffed, only 4k self buffed - the difference is usually not that great.
What I meant is exactly what greenriche said. Hopefully I can find some free time at some point to clean up the rotation UI and make it super-slick for even more casual users.
Let me address your individual concerns Allev:
- A point-and-click interface has its advantages: the main one being that it is harder to make mistakes. As a programmer, you are used to having more control and being able to type whatever you want. For the typical user though, this is a hindrance. The drop-down lists and highly structured UI force you to do (mostly) reasonable things, and also guide/suggest to you what is possible.
- There is indeed "OR" at the top level. Create a new action, choose "Ability" for this example. Then click "add a condition", and choose any condition. Then click the OR button.
- There are two conditions that can compare actions that occur over time:
"time remaining on X is greater than Y"
"difference in time remaining on X and Y is less than N"
The first is self-explanatory.
The second could perhaps use better wording, but it is indeed the absolute value of the difference in time remaining.
I chose to break these into two conditions that are exposed on the UI because I felt it was more intuitive. The SimC feral rotation uses (rip - SR >= -3) as a condition. While that is much more succinct, it is conceptually obfuscated for the majority of users. I would argue that people will not do math in their head like that when playing; instead they will think more "conceptually": "do this whenever rip has more time than SR, or if the time left is really close."
In general, realize that we have a wide audience in mind with this tool, many of whom will not be as technically proficient as yourself.
- The DPS estimates are indeed giving too much value to the ashen band procs, I'll try and figure out why. If you press the "simulate" button, it will give you an accurate result in the meantime. I'm going to be adding a reminder to the UI that you can use the "simulate" feature if any of the estimates look off.
- When I run the simulator for my character, I am at 34% white damage. You may need to tweak the rotation to get an optimal result for your particular character. I'll try some other combinations of gear to see if I can find a rotation that is a good compromise for a wide range of gear. Remember that the goal of the default rotation is to be pretty good for anyone who wants to use the simulator, not just people in full ICC25 gear.
- Changing from the condition "don't have SR" to "don't have SR or < 1 sec remains" will potentially change the timing with which you use finishers, and how much energy you allocate to SR vs. other moves. It is not immediately clear to me that this change would necessarily be a DPS increase -- as stated before, there are too many variables to assert that as fact and then impose it as a criterion for correctness on a simulation tool.
- A double-check of the code confirms that "AND" is being implemented in a commutative fashion. A test of your case with the SR conditions using the simulator shows zero difference in the result if I change the order of the conditions. Did you perhaps not enter the conditions correctly, or make another change that you forgot about?
You also have a selection bias in that higher uptimes on Berserking/Mongoose lead to more damage overall. Most average uptimes are near 33% across multiple theorycraft tools.
I have fixed a bug that was causing PPM procs for ferals to proc too often (basically it was using your equipped weapon's speed rather than 1.0 to calculate the proc rate). On my local version, I'm showing about a 45% up-time for mongoose using a 1 PPM proc rate... might be a little high, but it's closer.
Unfortunately I haven't had a lot of time to work on the simulator this last week, so it'll be another day or two before I can post an update.
Berserking and Mongoose use the same PPM mechanics, so I'll use that to specifically nail down this number. Mongoose will have a slight self-stacking effect, but that factor should only add up to less than 1% uptime.
Rawr with my character's DPS gear shows an 86.16 damage increase for the Berserking enchant, which translates into roughly 143.6 AP on average, 143.6/400 = .359, or roughly 36% uptime.
Toskk's shows it as a 190 AP average = .475. That doesn't seem right, so I'm going to investigate that over at his site.
I looked into it a little closer, and it appears that I was allowing physical-damage DoTs to trigger actions flagged as triggering on "physical". I've fixed that such that bleed ticks will only trigger actions specifically flagged to trigger on dot ticks.
01/30/10, 4:53 PM
Similar Threads
