Kosmos

No, it does nothing for Regen or MaxHP at all, it only buffs Heals. I don't see that happening in Mids myself either. Are you sure you're not just enhancing a +Reg power directly with the 4th IO?

None at all.

The Entropic proc is OK in some powers as a little sop or if used in an entire chain as a bit more than that.

If you can fully saturate an attack chain with an average cast time of C and you spend P percent of the time fighting, then the equivalent +Reg is 10% * 5% / (1 + HP bonus pct) * 240s * P / C. (That's chance to proc times heal as a percentage of MaxHP times number of casts per 240s, which is the period it normally takes to Regen 100% of your MaxHP.) If you have, just for argument, 20% +HP, your average cast (in ArcanaSecs) is 1.8 and you spend 70% of the time fighting then the equivalent +Reg is around 40%.

I did a build like this for a FF/En Def (with only +6% HP) and achieved a +64% Equivalent in continuous fighting (i.e. plinking Targeting Drones), but in practice and using Force Bolt as a filler I managed +45%. Breaking it down from the logs I was getting the following +Reg equivalencies: Power Bolt 20.4%, Power Blast +11.7%, Power Burst +9.6% and Force Bolt +3.2% (limited by not being used unless nothing else was available).

In a soft-capped FF Def chasing +Reg (for the obvious reason) and +Rech (since the toon has passive defenses having a full attack chain is nice) it's not bad, but not great either. For ranged attackers who aren't tough enough for a bit of healing to make much difference or who have real self-heals, it's pretty irrelevant.

This is off slightly, as powers don't begin to recharge until the casting has finished, while the duration begins at casting. This can significantly affect powers where Rech Bonus Needed * Cast / Base Rech is not small. Anyway the formula for required recharge to make something perma is:

RechNeeded = BaseRech / (Duration - Cast) - 1

For Haunt that's...

RechNeeded = 210s / (60s - 2.33s) - 1
RechNeeded = 2.641 = +264.1%

So that's +14.1% more than calculated ignoring the Cast time above. Not small in terms of Set Bonuses, but since you're going to need Hasten to get there getting it's - Hasten's that is - up time improved with each bonus helps.

Without going crazy and listing all the math... it should be possible with about 93% Global using soft-capped slotting in Haunt, a Spiritual or Agility T3 and putting Hasten on auto-fire with 2 L50 IOs in it. That gives no margin for delay in casting Haunt though, of course. That formulation is roughly what I consider the minimum possible Global needed. 3-slotting Hasten could lower that a bit, but I'm usually slot-poor, so my base formula assumes 2.

As stated, it's NOT what the PPM code is using. Also, the calculated value for Tremor isn't actually what is used for it; it has a DS of 1 instead of the calculated 0.8. I tried using both the DS AoEMod formula and (0.16*Rech + 0.36)/DS to account for tweaks such as Tremor received, and neither worked well. I'd just started to try to figure out alternatives when I22 launched and I lost interest in testing.

Anyway, I've always hated that messy formula you listed. I can't imagine anyone wouldn't hate it; so if you're going to code it in anywhere you may want to use this instead...

AoEMod = 1 + radius * (11 * arc + 540) / 30000

... it's the same thing but with the variables collected and the constants scaled to use integer values.

Unfortunately it doesn't work for the general case however. The aforementioned Crowd Control, for example, would have a 69.8% proc rate instead of 100% using the Damage Scale AoEMod.

True. But they either need to produce a much better fit for the SBE-to-IO relationship, or bite the bullet. I think they meant to balance the AoE cost and the ST benefit but seem to have ignored the fact that some procs are balanced around only being able to be slotted in ST powers to begin with (or in the case of the P Shifter, are far more useful slotted in certain passives than elsewhere). Having SBEs outperform IOs to the extent they've produced is just not a good idea unless they really do want a "pay to win" model.


Here's a little math to consider...

p = IO Proc %

P = SBE PPM
P = ceiling(30 * p) / 2 {I think}

A = SBE AoE modifier for a given power
p' = SBE proc % in a given power
p' = min(Cycle / 60s * P / A, 100%) {best guess}
p' = min(Cycle * ceiling(30 * p) / 120s / A, 100%)

R = Ratio of performance between an SBE and corresponding IO in a given power
R = p' / p
R = min(Cycle * ceiling(30 * p) / 120s / A, 100%) / p

Simplifying by losing the ceiling function and breaking down the minimum function...

R = Cycle * 4s / A : Cycle * p / 4s / A < 1
R = 1 / p : Cycle * p / 4s / A >= 1


I think I got that right, but I've been up all night, so cut me some slack if I missed something. It was right in my head, but I'm not sure it made it to the computer intact.

Looking at the second to last line note that Fireball has a base cycle time of 17s and an A value somewhere around 3. So even in what I'll call a "standard" AoE, we see the SBEs outperforming the IOs. It's only powers with a Cycle/A value under 4 that are hurt by using SBEs, and that seems to be mostly AoE Immobs and Tanker ST attacks with punch-voke.

Moving to the last line you see that most SBEs can theoretically outperform their IO counterparts by at least 5:1 in the right situation.

The more I look at it the more it appears that the SBEs were deliberately set to perform at least as well as IOs except in some strange outlier cases. And the more I look at it the more I think the only practical fixes - assuming they aren't deliberately going to a "pay to win" model - are to make IO procs use the PPM code or SBE procs use the old straight percentage method. Which would leave the PPM code for just enhancements specifically designed and balanced to use it such as ATOs. Any other solution is going to require a more sophisticated formula for calculating proc % from PPM and power specifics and a lot of balance work on the PPM values for individual procs.

Well, you'd still have issues with a lot of other procs. For example, an SBE Mako proc is also roughly twice as effective in a typical power as an IO Mako in the same manner as the P Shifter. To illustrate, let's say I slot Makos into all of the ST attacks on my recently respec'ed DM/Regen Stalker (which I intend to do as he levels up from 38). The ratio of SBE performance to IO for each is... Boxing 0.89:1, Smite 1.74, Siphon Life 2.98, Assassin's Eclipse 4 (I don't think the Interrupt period counts in the PPM calculation, but I need to test that with a lower PPM than Stalker's Guile, which is 100% either way) and Midnight Grasp 4.27. Weighting by my usage rates in logs that comes out to the SBEs being 2.39 times as effective as the IOs (which would up my ST DPS by 9%, essentially letting me piggy back 1.4 additional procs onto each attack by using SBEs). And since Mako's are only supposed to go in ST attacks, the AoEMod provides no excuse for the PPM given either.

As you said, they should have switched all procs to the PPM model to put the "pay to win" issue completely to rest. But even then, I think they needed to do a better job with the Proc% -> PPM conversion.

Because of the potential for abuse in passives, toggles and pseudo-pets, I wouldn't have even considered anything much less than 10s. Maybe 8s at the lowest. That puts an SBE proc at 25% better than the equivalent IO when slotted in a passive.

As for leveling off near 100%, consider the OP: The PS +END SBE outperforms it's IO brother by 2.5-to-1 at a mere 50% proc rate.

For those reasons my thinking was just the opposite of yours: I would have picked 12s (just above the 10s that makes SBEs and IOs perform the same in passives, toggles and such and also a value that produces a tidy 1 PPM rating for the 20% chance proc) and then used a non-linear, probably hyperbolic, element to cause the function to level off as it neared (a relative term) a floor of 5%. That 5% also had something to do with AoE performance for me.

When you add in the AoE complications for SBEs, this whole balancing a plane on a single point act they've done with the mechanical Proc% -> SBE PPM rate formulae becomes rather tricky. It's quite possible they chose the extremely low 4s midline for the cycle time to offset the AoE penalties SBEs suffer from. Whatever the thinking it results in any SBE that goes into medium-to-long cycle time single target power being MUCH better than it's IO counterpart for such use (up to 6.67x for a 15% proc in a 24s cycle time ST power). On the flip side, any SBE in a short cycle AoE is going to be notably worse than the IO version. Though usually not to the same extent, as the AoE factors don't seem to reach that 6.67 value and because AoEs rarely have a cycle time under 8s (for example, I'm seeing about a 1.4:1 advantage for the Trap of the Hunter proc IO over the SBE in Fire Cages in limited testing).

The bottom line is that the "provides the same value in all powers" concept seems to have trumped any desire to make the SBEs and IOs perform similarly. The result is that some SBEs (those with a high value effects when applied to a single target - usually the caster) have been provided with very long levers that players can use to boost performance.

First, Crowd Control doesn't have the extra punch-voke AoE added on to it, no Tanker AoEs do, only the ST attacks. The do have punch-voke, but since they're already AoEs, they're already paying the SBE/ATO proc rate penalty. ST attacks do have an extra AoE hiding in the background that does nothing but taunt... and ruin their SBE/ATO proc rate.

Second, you misunderstood the bug... the proc rate doesn't change with the number of targets you have, it only changes with the particulars of the power. Once it's slotted in a power it's always the same (unless it's an ATO and you upgrade it with a Catalyst). What I'm trying to say is that it only checks once per activation no matter how many times it hits. Since you're using powers with a 100% chance to proc you aren't seeing this. Though you would if you noted that it never procs more than once per activation no matter how many you hit.

For Crowd Control the AoE modifier is apparently less than 1.167, so it's proc chance is 100% when you hit 1 target or 5. If it was 80% it would also have an 80% chance of firing whether you hit 1 target or 5. Not 1-(0.2^5) = 99.968% chance as you'd expect when hitting 5 if it was checking for each target hit. I say as you'd expect because you'd be paying a proc chance penalty for the IO being in an AoE so naturally I think you'd expect it being in an AoE to provide some sort of benefit.

For Shield Charge to reduce the proc rate to less than 100% it would have to have an AoE mod of 9.84 or higher, which is highly improbable. It should be in the 4-5 range. For observing this bug you need to deliberately choose powers that will NOT give you a 100% chance to proc. You've chosen two that do. Once again, when you choose a power that gives a 100% chance to proc the issue of one activation = one chance to proc if you hit anything is completely irrelevant unless there is a possibility for multiple procs per power activation (as there should be if you're paying a penalty to have the proc in an AoE). However, with a power such as Tremor it does matter even without considering the multiple proc potential; as the proc rate is somewhere around 43%. It has a 17.3s cycle time compared to Crowd Control's 14s. So the AoEMod is clearly much higher. In the neighborhood of 3. So the IO pays a significant penalty to its proc chance for being in Tremor. However, in testing versus 1 target it proc'ed on 43% of the hits, while in testing against 4 it proc'ed in just 12% and there were never instances where it proc'ed more than once on a cast. That's not because the proc chance changed, it's because any hit past the 1st on each activation didn't result in a chance to proc at all. The proc rate per activation in which there was at least one hit was 48%, consistent with the 1 target tests. If it was giving me the benefit of multiple checks I should have seen an average of 1.67 procs per activation and at least one on 89% of my casts.

I believe the reason this proc behaves this way is because it targets the caster, not the target of the power it is slotted in. To try to confirm this during beta I tested all of the procs that target the caster and on beta all but the Brute proc behaved this way. And since going live they have changed the Brute proc. So I suspect it now behaves this way as well.

It's very definitely not just Recharge, and Recharge+Cast seems to fit the data I have very well.

I suspect Arcanaville's unease is similar to mine when I learned the PPM was a simple formula for the proc chance instead of some sort of throttling mechanism. Too many possibilities for weird outliers.

However, the problem illustrated by this thread is much simpler. The devs equated a 20% proc chance with 3 PPM, which only balances out for powers with a base cycle time of 4s. In anything longer than that it will over-perform because the proc chance will be (Cycle Time / 4s) * 20%.

Here's the base formula I have for proc chance...

Proc% = Cycle * PPM / 60s

Rearranged that gives...

PPM = Proc% * 60s / Cycle

And someone clearly chose 4s for the standard cycle time for SBEs which produced insanely overpowered procs. They even rounded up to half point increments for the 15% procs and gave them a 2.5 PPM rating instead of 2.25. In my opinion 12s would have been a much more reasonable standard. And frankly, using something with non-linear elements would have been better. Maybe they do have such elements in there, though I haven't seen any evidence of it.

It seems what Arcanaville expected (and so did I, though I have no idea where I got that idea) was that the PPM was the maximum the IOs would produce. And for all practical purposes they chose a formula for deciding the PPM of SBEs that makes that value pretty much the minimum they will produce in a single target power.

When you drop to Premium everything gets locked and it gives you your tokens to unlock what you choose. So Exalted shouldn't be an issue (which is undoubtedly one of the reasons they implemented it this way).

Assuming he didn't miss a server, it sounds as if something did indeed go awry and it will require customer service to resolve.

My tests with the Tanker attacks are not working out to MaxTargets. For example, in 134 hits against a single target with Tremor (14s Rech, 3.3s Cast) using a 5 PPM proc I saw a 43.3% proc rate, despite a 10 target cap. That's an error of a whopping 9.5 sdev assuming the MaxTargets modifier (11.4 sdev if you use the incorrect Rech only formula). The AoE mod for a 15', 360 deg, 10 tgt attack appears to be pretty close to 3, not 10.

This is almost certainly wrong, my tests on beta put the odds of the results I saw given this formula as essentially impossible. For example, in 791 hits with Barb Swipe and a 2.5 PPM ToD proc I saw 134 procs, over 12 standard deviations from the mean expected given a normal approximation of an underlying binomial distribution with the proc chance given by the above formula. Another 491 hits with the 3 PPM Mako proc produced 102 procs, 11+ sdev off itself. And that's just the last two test sets I ran to test the hypothesis that it's actually...

(Base Recharge + Cast) / 60s x PPM

With that formula every single one of my test series fell within the 95% confidence interval and the total testing over 2768 hits was 0.38 sdev high.

My testing in beta indicated that the proc chance uses combined Base Recharge and Cast times for the calculation. For single target attacks (currently no Tanker attacks are considered single target due to punch-voke) the formula appears to be Proc/Minute Rate * (Recharge + Cast) / 60s.

For AoEs I believe the only change is that this value is divided by a factor that estimates the number of hits per cast and appears to be based off just Radius, Arc and Maximum Targets. I only have the sketchiest idea what the formula for that AoE factor is at the moment. However, for melee cones this factor appears to be fairly small, which is why Crowd Control is at or near a 100% proc rate. If the factor is less than 1.167 then it should be at 100%.

Unfortunately, due to the punch-voke bug, right now you are usually better off putting the Tanker proc in a true AoE, as the radii for the Taunt for longer recharge ST attacks can get to be quite large (17' on a 20s Recharge attack such as Seismic Smash or Knockout Blow) and so it will knock the proc chance way down.

On top of that punch-voke bug alluded to above, the IO also has only one chance to proc per casting, regardless of how many targets you hit. Which means you pay the penalty for it being in an AoE but actually get no benefit whatsoever from hitting multiple targets. (Almost all of the self-buff SBE/ATOs that I tested in Beta suffer from this handicap; the only one that didn't was the Brute proc, but that has now been changed, invalidating my Beta test, and probably resulting in it having the same problem as the others.)

Translation: The awards are even wonkier than *I* thought, let alone being more wonky than *you* asserted.

I responded to an explanation you gave for how the reward systems work that is simply not true...

Now even you imply that you don't get your Transfer Token on a set date, let alone at the start of the billing cycle as you asserted. Maybe you meant "near the start of the billing cycle". Given that it can't be more than 15 days off, and that for some players I know it is as much as 10 days off (received on the 1st instead of the 21st), even calling it "near" would seem a little iffy. (Btw, posting a picture that shows no Transfer Tokens tells me nothing about when you get them, only that you used your tokens between that time and when the screen capture was made.)

As for the Reward Tokens, CS told me that it was based on Freedom launch, not billing dates, and that checked out perfectly with what players were reporting then and still seems to be consistent with what I hear from others now. Your assertion that Reward Tokens come at the end of the billing cycle is at odds with CS statements, my systematically tabulated (though sparse) data from Oct/Nov, continuing anecdotal reports I hear from friends complaining that they don't get their Reward Tokens when they expect, and with numerous posters on these forums.

Uh, no, I didn't say "a supervisor told me" because it didn't occur to me to make that distinction to keep the CoX forum's attack squirrel at bay. It was in fact a CS supervisor who told me that. Two of them actually, the second one elaborating on the initial Reward Token grant procedures, as my support request was questioning why I didn't get a Reward Token on my bill date on Oct 6.

And the explanation I was given by those gentlemen works for everyone I collected data from back in October and November when trying to pin down why some people seemed to have gotten one more token at launch than CS' explanation seemed to indicate they should. While your explanation works for exactly ZERO of them. If you get the Transfer Token on a date other than the 1st then you would be the first person I've heard of that does. And out of the 32 I collected info from, only 1 gets their Token and points exactly one month apart, and that's because they have a bill date of the 27th (there are two people with that bill date in my data set, but one gets their Reward Token on the 23rd - or at least they did in Oct).

So, translation: Your tidy little explanation does not appear to be accurate.

Are people being routinely cheated out of their perqs as the OP's post seems to imply? No. Are the awards nice and tidy? Not by a long shot.

That's not what the CSR told me, and it doesn't line up with my dates either.

Everyone I know gets the Transfer Token on the 1st of the month, regardless of what their billing cycle is.

From what I was told the Paragon Points are supposedly awarded on the billing date. I get mine the day after that (my bill date is the 6th, I get the points on the 7th).

And lastly, I was also told the Reward Token is given at the end of a period deemed to constitute a full month of play time. This Reward Token apparently is considered a replacement for the Veteran Reward time and so if your VR date was off for some reason, then that offset got carried forward. Also, it's dated from the launch of Freedom, not your billing date. For example, I get my Reward Token on the 22nd because due to a correction made for a missed VR years back I was getting my VR's 5 days early and Freedom launched on the 27th.

According to City of Data the Taunt aura (which is actually in the mez prot toggle Entropic Aura) is supposed to suppress when Energy Cloak is on. However, on my Brute I can stand next to foes with Cloak/Stealth IO indefinitely with no aggro, and then they aggro the instant I turn Entropic on. Either Entropic itself is causing aggro or it's causing Fury to aggro.

You overlooked those two items. Those HOs are a cool 300M apiece, maybe more. Replacing them with something else is mostly going to hurt END-wise.

I've been considering using a minor variant of the Tanking Crab build Trilby posted in his guide (I think the one here is a touch different, but essentially the same) for my 2nd build. Here's my 1st build, it was a leveling build and could use an optimization pass now that I have the Agility Alpha. I actually have ATOs in Venom Grenade now too. It's just a hair short of perma on the 6 pets (and Hasten), as well as on the Ranged Def soft-cap. The perma-pets and soft-cap to Ranged were the design goals. I used the FF proc in Frag Grenade to make up for some of the missing Recharge while leveling.

Villain Plan by Mids' Villain Designer 1.953
http://www.cohplanner.com/

Click this DataLink to open the build!

Der Fiedler: Level 50 Natural Arachnos Soldier
Primary Power Set: Crab Spider Soldier
Secondary Power Set: Crab Spider Training
Power Pool: Speed
Power Pool: Leaping
Power Pool: Leadership
Ancillary Pool: Mace Mastery

Villain Profile:
Level 1: Channelgun -- Achilles-ResDeb%(A), Thundr-Acc/Dmg/Rchg(3), Thundr-Acc/Dmg/EndRdx(5), Thundr-Dmg/EndRdx/Rchg(7), Thundr-Dmg/EndRdx(21), Thundr-Dmg/Rchg(27)
Level 1: Crab Spider Armor Upgrade -- S'fstPrt-ResKB(A)
Level 2: Longfang -- Thundr-Acc/Dmg(A), Thundr-Dmg/EndRdx(3), Thundr-Dmg/Rchg(5), Thundr-Acc/Dmg/Rchg(7), Thundr-Acc/Dmg/EndRdx(25), Thundr-Dmg/EndRdx/Rchg(31)
Level 4: Combat Training: Defensive -- LkGmblr-Rchg+(A)
Level 6: Hasten -- RechRdx-I(A), RechRdx-I(17)
Level 8: Suppression -- Det'tn-Acc/Dmg/EndRdx(A), Det'tn-Dmg/EndRdx/Rng(9), Det'tn-Dmg/Rchg(9), Det'tn-Acc/Dmg(11), Det'tn-Dmg/EndRdx(11), Range-I(15)
Level 10: Tactical Training: Maneuvers -- LkGmblr-Def/EndRdx(A), LkGmblr-Def/EndRdx/Rchg(27), LkGmblr-Def(31), LkGmblr-Rchg+(34)
Level 12: Venom Grenade -- Posi-Acc/Dmg(A), Posi-Dmg/EndRdx(13), Posi-Dmg/Rchg(13), Posi-Acc/Dmg/EndRdx(15), Posi-Dam%(17), RechRdx-I(31)
Level 14: Aim -- RechRdx-I(A)
Level 16: Tactical Training: Assault -- EndRdx-I(A)
Level 18: Frag Grenade -- Det'tn-Acc/Dmg(A), Det'tn-Acc/Dmg/EndRdx(19), Det'tn-Dmg/EndRdx/Rng(19), Det'tn-Dmg/EndRdx(23), Det'tn-Dmg/Rchg(23), FrcFbk-Rechg%(25)
Level 20: Wolf Spider Armor -- S'fstPrt-ResDam/Def+(A)
Level 22: Mental Training -- Run-I(A)
Level 24: Fortification -- Aegis-ResDam/EndRdx(A), Aegis-ResDam/Rchg(42), Aegis-ResDam(43), Aegis-ResDam/EndRdx/Rchg(43)
Level 26: Maneuvers -- LkGmblr-Def/EndRdx(A), LkGmblr-Def(43), LkGmblr-Def/EndRdx/Rchg(46), LkGmblr-Rchg+(50)
Level 28: Serum -- Dct'dW-EndRdx/Rchg(A), Dct'dW-Heal/Rchg(29), Dct'dW-Heal/EndRdx/Rchg(29), Dct'dW-Heal(42), Dct'dW-Rchg(42)
Level 30: Tactical Training: Leadership -- EndRdx-I(A)
Level 32: Omega Maneuver -- Posi-Acc/Dmg/EndRdx(A), AirB'st-Dmg/Rchg(33), Det'tn-Acc/Dmg(33), Det'tn-Dmg/Rchg(33), Posi-Dmg/Rchg(34), RechRdx-I(37)
Level 35: Summon Spiderlings -- ExRmnt-Acc/Rchg(A), ExRmnt-Acc/Dmg(36), ExRmnt-EndRdx/Dmg/Rchg(36), ExRmnt-Acc/Dmg/Rchg(36), C'Arms-Acc/Dmg/Rchg(37), C'Arms-EndRdx/Dmg/Rchg(37)
Level 38: Call Reinforcements -- ExRmnt-Acc/Dmg/Rchg(A), ExRmnt-Acc/Rchg(39), ExRmnt-Acc/Dmg(39), ExRmnt-EndRdx/Dmg/Rchg(39), C'Arms-Acc/Dmg/Rchg(40), C'Arms-EndRdx/Dmg/Rchg(40)
Level 41: Web Envelope -- Enf'dOp-Acc/Rchg(A), Enf'dOp-Acc/Immob/Rchg(45), Enf'dOp-Acc/EndRdx(45), Enf'dOp-EndRdx/Immob(45), Enf'dOp-Immob/Rng(46), Enf'dOp-Acc/Immob(46)
Level 44: Disruptor Blast -- Acc-I(A)
Level 47: Summon Blaster -- ExRmnt-Acc/Rchg(A), ExRmnt-Acc/Dmg(48), ExRmnt-Acc/Dmg/Rchg(48), ExRmnt-EndRdx/Dmg/Rchg(48), C'Arms-Acc/Dmg/Rchg(50), C'Arms-EndRdx/Dmg/Rchg(50)
Level 49: Combat Jumping -- LkGmblr-Rchg+(A)
Level 0: Born In Battle
Level 0: High Pain Threshold
Level 0: Invader
Level 0: Marshal
Level 50: Agility Partial Core Revamp
------------
Level 1: Brawl -- Empty(A)
Level 1: Sprint -- QckFt-EndRdx/RunSpd(A)
Level 2: Rest -- Empty(A)
Level 1: Conditioning
Level 5: Ninja Run
Level 3: Swift -- Run-I(A)
Level 3: Hurdle -- Jump-I(A)
Level 3: Health -- Numna-Regen/Rcvry+(A)
Level 3: Stamina -- P'Shift-End%(A), P'Shift-EndMod(21), P'Shift-EndMod/Rchg(34), EndMod-I(40)
------------