Bopper

Added new chart to reflect what the +HP proc's equivalent regeneration is as an easy comparison to +Regeneration IOs. This isn't new findings, just a new way of comparing.

I'm not sure how you got to 22.5% regen equivalent, but it appears incorrect. I will update my cheatsheet to include this new table for clarity, but I'll add it here as well since it applies. The Power Transfer (P.T.) proc is equivalent to 60% regeneration at Base Hit Points, and at capped Hit Points it varies. I put in a new section of the table that shows the equivalent regeneration the P.T. and Panacea procs provide, but you will notice that under no circumstance does the P.T. proc ever count as less than 26.7% regeneration (which is when you reach capped HP for one of the 4 EATs). For a capped HP brute, the proc is equivalent to 28% regeneration, however that is hard to reach. Let's say the brute sits at +100% HP (double base), then you're looking at the P.T. proc as being equivalent to 30% regen. Stack that 3 times for 90%. That is a bit much.

It might have stalled. But I haven't seen it confirmed by Cipher or any other developer. Then again, we haven't seen much from any Dev on the forums since Page 5 was released and Patches to Live and Beta haven't happened for over a month, so perhaps everything has stalled. I'm guessing they're busy on Page 6 and being secretive with it. But who knows.

That would be OP, given that it easily slots into Stamina whereas CotS requires you to take and use a sleep power. As a 3 PPM 5% heal, it is better than a +25% regeneration. Those regeneration IOs are unique, but the PT proc doesn't have to be. You can still slot more than one if you want to (you have to accept the diminishing returns if you put them into autos) and you can slot them in things that are not autos. An Electric character can have a field day with this proc. Making it unique at 15% is not the way to go. Truth be told, I like how it works now. Yes, I think this is a bug. But I think the bug's unintended consequences make for a better mechanic when all things considered. Otherwise, you're looking at a proc that is not unique doing more HP/s than a 25% regen proc. I refer you to my cheat sheet that shows how it stacks up when compared between all ATs and you'll see this proc is almost twice as strong as the 25% regen in most situations.

haha, I'm not sure if you're being lazy if you're actually doing more work. Those were the things I was thinking about. Also, I am not sure which AVs you had, so I don't know what resistances they might have, resistance debuffs, if they had debuffs (sounds like yours did), if they has status effects (Pylon you just have to protect against KB, maybe that's not the case against an AV). So ultimately, there seemed to be additional variables. But it sounds like this is intended as a personal test, not an all encompassing test, in which case it sounds like it fits your needs perfectly. A GM might be a tad too much of a test. Maybe it's more of a test for those who are posting sub 2 minute times on pylons. I'm working with a team on building a simulator for pylon testing (give no credit to me, I just help with mechanics, the others are doing the real work) that has shown promise so far. If it gets mature enough, I could see the user being able to add more health to the pylon and see how their results do when they have to attack for a full 4 minutes+. I agree with you there. I am trying to balance my toons to be able to do both now. I had a defender that was a pure AoE monster, but when it came time to defeat a hard target it drug on slowly. I had to incorporate single target optimization while trying to maintain as much AoE as I could. In the end, I love it for the hard targets, but for typical mobs I do miss the mass melting. It's all balance, but overall I also am leaning more towards ST specialty as I grow within the game.

It's been a month since I asked, but...any updates?

I don't know if this is a bug that belongs on Beta or on Live, but I noticed there is a discrepancy between the Pylon's attack. On Live, when I get hit, I typically take 4 ticks of damage from the swarm missile. But every now and then...maybe 20% of the time... I get hit with a 5th tick of damage. I was curious about this behavior, so I went on Beta last night and stood next to a pylon for 10 hours in hopes of getting a large enough sample size of how often the 5th tick of damage occurs. Yet, when I woke up this morning to analyze the data, and what do I see? Not once did I get hit with the 5th tick of damage. So...what's going on with that?

I'm surprised you wouldn't use the combat logs for a start and end point, but perhaps I haven't looked at the features of my phone's stop watch. Can it start and stop using voice recognition? If so, then yeah, that would be a great way to measure. There would be some lag, but nothing like a full second. Fighting numerous AVs in a row can certainly be viable for measuring one's performance, although I'm not certain on the controllability of such a test. But with enough samples, you can certainly gain confidence in the performance. Given how over-tuned characters have become, I would have to lean on agreeing with you that Pylon testing may not be the best way to determine DPS. Perhaps Giant Monster killing will need to be the next metric to use. An enemy that can move around a little while having similar debuff resistances of a pylon and twice as much Hit Points would certainly offer up information on how well a character can provide sustained DPS. Of course, you'd have to account for the GMs having resistances that are not constant across all damage types, and there is the philosophical discussion on "who cares about sustained DPS, burst is where it's at", but that's for others to argue.

Defensive Sweep and Titan Sweep would seem like the likeliest of powers to go.

Pylon DPS a range of outcomes This will be a confusing formula, but let me try to break it down. For Pylon testing, what we have to work with are combat logs that provide us with times truncated to the whole second. This is somewhat limiting as we get a time of 00:12:32, but don’t know if that is 12 minutes and 32.00 seconds exactly, or if it is 12 minutes and 32.999 seconds. For this reason, the DPS for Rikti Pylon times cannot be calculated exactly. Instead, we have a range of values that the true DPS lies within. To determine the bounds of this range, we must incorporate some logic that will help determine what is the worst possible DPS we can achieve and the best possible DPS we can achieve given the times shown in our combat log. Before we get into calculating those bounds, we need to go over the parameters for calculating the DPS. We have the following information for the Rikti Pylon target: The formula used to calculate the true DPS is a variation of @Werner formula, which is: The is the time at which the Rikti Pylon is defeated. The startTime is the time at which you start the Pylon run (you must specify what is the start of your run; it can be when you activate a buff, activate an attack, etc). The is the time at which the Rikti Pylon takes its first damage, which starts the clock for its regeneration (which will occur 15 seconds later…barring any regeneration debuffs). This formula would calculate the DPS exactly, however the times in the combat log are truncated to the whole second. Since we cannot be certain of when the exact times are, we must limit ourselves to calculating the best- and worst-case scenarios. Worst-case scenario: Achieve the worst possible DPS by attempting to make the run time as long as possible while also trying to minimize the number of regeneration ticks in an effort to ensure the amount of damage inflicted is minimized. To achieve this, we will always round down (to the nearest second) the and round up the , while also rounding up . To ensure we do not gain a potential extra tick of regeneration between the and , I will round up by adding 0.999s to the and will only add 0.998s to the round up of . The 1/1000th of a second will not matter in the long run, but it will ensure that if the seconds between the and would result in a regeneration tick, the Rikti Pylon will be defeated 1/1000th of a second before that regeneration tick would fire. Note: My use of 0.001, 0.999 and 0.998 was based on personal preference. I picked numbers small enough to not impact the final result while still providing the mathematics necessary for the Floor formula logic to work.If you want, you could use 0.00001, 0.99999, and 0.99998. Whatever pleases you. Best-case scenario: Achieve the best possible DPS by attempting to make the run time as short as possible while also trying to maximize the number of regeneration ticks in an effort to ensure the amount of damage inflicted is maximized. To achieve this, we will always round up the (+0.999s) and round down the , while also rounding down . To ensure we gain a potential extra tick of regeneration, the will have 0.001s added to its rounded down time. Realistically, an extra tick of regeneration occurring 1/1000th of a second before the Rikti Pylon is defeated is unlikely to happen. But who knows, maybe your proc’d out Crushing Uppercut finished animated right after the regeneration tick occurs and you finish the Pylon off anyways. Centralized Best- and Worst-case scenario: We have shown how to bound the extreme limits of our DPS by round up and down the times given to us in our combat log. Now, let’s aim for something in the middle by assuming our , , and all line up right in the middle of our “whole-second window”. We can show this by adding 0.5s to the combat log. However, this is an unnecessary step as we are working in relative differences already and those shifts would cancel each other out. So it turns out, our Centralized scenario is in fact our original formula, however we will caveat it by incorporating whether-or-not the extra regeneration tick occurs. Typically, these numbers will be the same, but 1 out of 15 will give you different +/- results. Example Calculations: I have never been good at explaining things, so I always felt like it’s easier to show how to do something by incorporating examples. Here is an example run of one of my Pylon Tests. I will provide snippets of my combat log, and show how to run the above formulas to get my range of outcomes. 00:28:34 Activated Hasten 00:28:35 Activated Ageless Destiny 00:28:36 Hit Rikti Pylon with Mud Pots for 14.93 points of damage 00:28:37 Activated Rage 00:28:38 Hit Rikti Pylon with Mud Pots for 21.02 points of damage … 00:32:47 Activated Knockout Blow 00:32:49 Hit Rikti Pylon with Knockout Blow for 394.98 points of damage 00:32:49 Hit Rikti Pylon with Perfect Zinger for 57.39 points of damage 00:32:49 Hit Rikti Pylon with Ghost Widow’s Embrace for 57.39 points of damage 00:32:49 Hit Rikti Pylon with Hecatomb for 85.66 points of damage 00:32:49 Defeated Rikti Pylon In this example, I actually hit the Pylon with my Mud Pots before I activated Rage, so we have to decide if we want to call the start of the run when we activated Hasten, activated Ageless Destiny, or when the Mud Pots damage did its damage (which would make and the same). For this example, we’ll use Hasten as out start time, thus: Example #1: In this example, my DPS was fairly tight on its bounds. That’s thanks to being fairly low DPS but also thanks to the fact I was 13 seconds away from the last regeneration tick. Let’s pretend I actually defeated the Rikti Pylon at 32:51, thus 255 seconds after the initial damage and at the same moment of a regeneration tick. Example #2: This shows an interesting effect as despite having a longer time to kill (257s), the best-case scenario for DPS is actually higher than that of the faster time to kill (255s). At the same time, it shows the worst-case scenario as having worse results than the faster kill time. Also, since our delta between the and landed on the same time as a regeneration tick, the centralized best- and worst-case scenarios now shows two results. Let’s finish off with one more example. This time, we will have the at 32:52 (258 seconds), which will guarantee the extra regeneration tick will occur. Example #3: Well wait now, how is that possible? We are 3 seconds slower than our original Pylon time, and yet the worst-case scenario for the 258s time is better than the best-case scenario for the 255s time. What gives? This illustrates the ebbs and flows of an attack chain. The instantaneous DPS of an attack chain will always be fluctuating, and it is possible that you could kill a pylon while at the lower end of your DPS chain and you just missed out on using your best DPA attacks to bring your average DPS higher. With that lesson learned, I know of no better way to conclude this than….WTF.

Thanks again @Sir Myshkin and as well as @Werner. I actually do like how you guys simplify it more than my method. I used my version since it was easy to plug into a spreadsheet and to not have to worry about repeating decimals, but I greatly like the idea of having something that is simple enough to use on a basic calculator (which is how I do most of my forum math haha). This is also a lesson for me that I should not be so anal about the rounding; after all, the whole seconds of time we're measuring in offer far more variance than a fraction of a HP and a fraction of regeneration. That being said, I'll probably use these formulas going forward and call it good enough: DPS = 127.82 + 38346/Time Time = 38346 / (DPS - 127.82) That will be much easier for me to memorize and run numbers on my phone's calculator. As for Werner's approach to getting a better DPS number using regeneration ticks, it looks like a great approach. I have reservations like Werner does, as we can't be certain of how exactly the regeneration ticks are accounted for in the game. Do regeneration ticks average 15s over time, or does arcanatime cause the interval to actually be 15.048s? Ultimately, that is such a small difference, it won't impact numbers so I'll probably just use 15s. The thing that impacts numbers the most is the gap between when you actually start the run and when the pylon takes its first damage. Werner's technique implies the start of the run is at the moment the pylon takes its first damage; however most runs start before this, usually with buffs like Destiny, Hasten, Build-Up, etc. Then you also have to factor in the cast time of that first attack between when you started the animation and when the damage is applied. Ultimately, the best formula to use in that regard would be something like this: ( FLOOR [ ( Time - TimeBetweenStart_and_FirstDamage ) / 15 ] * 1917.321875 + 38346.4375 ) / Time To illustrate my point, let's do a very extreme example. Let's say that time to kill an enemy was 16 seconds. Using Werner's formula would produce the following: (floor(16/15) * 1917.321875 + 38346.4375)/16 = 2516.5 DPS But now let's say the cast time of the first attack took 2 seconds. That means the regeneration clock did not start until 2 seconds into the run, thus the pylon actually dies before it gets to regenerate any health. That means the actual DPS would be: (floor[ (16-2)/15 ] * 1917.321875 + 38346.4375)/16 = 2396.7 DPS (120 less DPS) That is an unrealistic example, so let's look at the same situation with a more reasonable pylon time of 151 seconds (2:31). Original method: 127.82 + 38346/151 = 381.8 DPS Werner's method: (floor(151/15) * 1917.321875 + 38346.4375)/151 = 380.9 DPS Proposed method: ( floor[ (151-2)/15 ] * 1917.321875 + 38346.4375)/151 = 368.2 DPS So that winds up being 12.7 DPS added that wasn't really there. Ultimately, this is nitpicking, but the lesson learned seems to be we probably have far more over-compensation between the actual DPS and the DPS measured by simply using the OP's/Original method. All of those numbers are on the high end as it implies regeneration is happening every second. Werner proposed an excellent approach on how we can back out some of those generous numbers to match closer to their true DPS times, but some fine-tuning is needed to really capture the exact number of regeneration ticks. That's what my proposed formula aims to address. All that being said...there's still no way of truly getting dead-on-balls accurate. We could ask folks to measure the time (in whole seconds based on combat log) at which they cast their first power to represent the start of the run, measure the time at which the pylon takes its first damage, then the time at which the pylon takes its last damage. But since we're dealing with times in whole seconds (as opposed to fractions of a second), we would really only be able to come up with a formula that would cage the range of DPS values the run actually achieved. My guess is people prefer their run as being equal to a "true" single DPS as opposed to a range within which their true DPS resides. If that is of interest, then we can work towards that type of formula, but it would mean starting from new with all pylon times going forward.

Thanks, i'll have to derive that some time. I did see that formula, and I assumed the 38343.75 (I calculate 30677.15/0.8 = 38346.4375...am I doing that wrong?) must have been an outdated HP for the pylon, so I didn't give it a 2nd look. But yes, an easier way would be to simply divide total HP by the time to kill and add the regen of the pylon to equal the dps. I'm just punching numbers into my phone, but I would think the formula would be: 38346.4375/Time + 127.82145833333 = DPS I do agree on properly modeling the the actual dps by measuring the time after a refen tick. Ill look over that later when I get free time.

This was actually fixed in a recent update. It should show 10% for Tankers.

Are you looking at "View Totals"?

You might need to do a full uninstall. Go into your control panel, go into programs, and find where mids reborn is. Uninstall, then reinstall using the first post of Mids Reborn (official)

the Defender ATO? Not sure. It should either stack or replace. In either case, it's not doing that.

Not all procs have changed. This functionality is similar to how Force Feedback works, where it will only proc once per cast. It will not stack from procing off of multiple enemies. The bug lies in how this functionality is mech'd. It appears the "once per cast" mechanic is somehow tied to timing, as you SHOULD be able to have Power Transfer slotted in 2 or more auto/toggle powers and have each enhancement proc 3 times per minute. However, it is only allowing 1 proc at a time. If you want to know the performance of having Power Transfer procs in multiple auto powers, you can use the following formula (n is the number of auto powers with a PT proc in it): Actual Average PPM = 60s* [1-(1 - (3 ppm)*10s/60s)^n ] / 10s = 6 * [ 1 - 0.5^n ] If you only slot PT proc into Stamina (n = 1) you will get an average PPM of: Actual Average PPM = 6 * [ 1 - 0.5^1 ] = 6 * 0.5 = 3 ppm If you slot it into 3 auto powers like LQT did, you will get: Actual Average PPM = 6 * [ 1 - 0.5^3 ] = 6 * 0.875 = 5.25 ppm We need someone like @Jimmyor @Number Sixto tell us if this is intended behavior.

I don't know if anyone cares about this kind of stuff, but I hate to use rounded numbers in my calculations and the fact we're using 102.26 HP/sec as regen has always bugged me slightly. No complaints on the OP, the formula is great, but I just like exact numbers. So if anyone is interested, I wanted to share two of my formulas for use on Pylon times. One is a simplified version of the formula we use now for calculating the DPS when given the Time, and the other is an inverse formula used for calculating the Time when given the DPS. New Pylon Formulas HP = 30677.15 Resistance = 20% Regen = 5% of HP every 15 seconds DPS = (HP + Time*Regen) / Time / (1 - Resistance) *Original Form DPS = ( HP + Time*HP/300) / Time / (1 - Resistance) *Plug in Regen in terms of HP DPS = HP * ( 1 / Time + 1 / 300 ) / (1 - Resistance) *Simplified Form for New Formula Time = HP / [ DPS * (1 - Resistance) - HP / 300 ] *Inverse formula, for finding out the time to kill given the DPS Plugging in the Pylon numbers: DPS = 30677.15 * ( 1 / Time + 1 / 300 ) / 0.8 Time = 30677.15 / ( DPS * 0.8 - 30677.15 / 300 ) Example: Time = 180 seconds DPS = 30677.15 * (1/180 + 1/300) / 0.8 = 340.8572 damage per second DPS = 340 damage per second Time = 30677.15 / ( 340 * 0.8 - 30677.15 / 300 ) = 180.727 seconds

I would not be surprised if it's more. Darkest Night on a tank now does 30% damage debuff...and I could be wrong but I think the KM damage debuffs are unresistable (or used to be). Throw in Ice's Chilling Embrace, and you might floor some of the mob to -90% damage debuff. I do that with my defender occasionally, but a tanker could probably do it too.

Wow...this is why I love the forums...these nuggets right here.

You missed nothing. There were some bugs that have been identified and fixes implemented. Some other stuff is being looked at, but hopefully an update gets pushed today.

Yup, and a fix has possibly been implemented. Hopefully an update is pushed today if all else looks good.

You are not wrong.

only the powers that follow will have the crit buff. But it's possible you can re-attack with the same power and have it land within the crit-buff window.

That is mostly what we have today. The PPM of some of the i23 procs (not all) were increased in i24+, and the rest of the numbers were incorporated into the version we have now. So the 1.25*PPM (I think I even saw it as 1.5*PPM in some archived places) is actually just PPM now after some procs got buffed. Although I use some algrebra for a slightly easier to read area factor, what you posted as 1 + .75*(.15*Radius - 0.011*Radius*(360-Arc)/30) is the same as 1 + Radius x (11xArc + 540)/40,000.