nzer

I figured it out, it's the rainbow path aura

I'm coming back to the game after a few years, and I wanted to reuse an aura I had on one of my characters on another character but wasn't sure which one it was. But when I opened the original character to check, I got a message saying the costume had invalid parts. Can someone help me figure out what aura this is?

No, they're not. Even if you accept that a premium power set should be more powerful than a free power set, which you shouldn't, those power sets aren't premium anymore. It's not part of the "integrity of their original design" to be overturned relative to all the non-premium power sets. Quite the contrary, that's an affront to the integrity of their original design.

Having thought about this some more, I think the solution is actually really straightforward: we need something that can multiplicatively modulate an attribute's resistance without also modulating its value. I can see two possible options: Change strength to not affect resistance, and add a second strength modifier that only affects resistance Add flags that can be applied to sources of strength that restrict them to affecting either the attribute's value or the attribute's resistance Either solution would allow the team to handle these problematic interactions directly rather than with kludges like "ignores external buffs." For example, if damage inspirations were flagged to only affect attribute value and not attribute resistance powers with enhanceable resistance wouldn't have to be flagged to ignore external buffs in order to prevent those inspirations from boosting their resistance values. This would allow for abilities that both have enhanceable resistance and are affected by power boost.

Not if the scale factors are set appropriately, as increasing enhanced recharge also increases the effective PPM of the proc. Eliminating the behavior you're referring to is actually the primary goal of the change. I'm not sure what PPM you're using, but there's really not any reasonable way to stop long recharge powers from capping proc chance when PPMs are as high as they are on the high end (meaning >4). You could do it, but it wouldn't really be a PPM system any more. Ideally PPM values would be lowered across the board, and L and E would be set such that fast recharge abilities get enough of a boost to counteract that. The values I used actually aren't too far off what you'd want, as they nearly double effective PPM for very fast recharge abilities and nearly halve it for very long recharge abilities. In the absence of lowering PPMs across the board, you could get the same effect by leaving L at or near 1. That would leave effective PPM nearly the same for fast recharges and heavily nerf it for long recharges. I don't recommend that though, as it makes the listed PPMs misleading.

Since a couple people have mentioned my "solution" I'll explain it in a bit more detail. The gist is to add a couple scale factors to the proc chance formula such that powers below a certain level of recharge proc more often than the listed PPM and powers above that level proc less often than the listed PPM. Here's the current proc chance forumla for a click power: ProcChance = PPM * (ModifiedRechargeTime + CastTime) / (60 * AreaMod) And here's the modified formula: ProcChance = PPM * (L * ModifiedRechargeTimeE + CastTime) / (60 * AreaMod) ModifiedRechargeTime is the power's recharge time after enhancements and alpha, but before global recharge, and the additions are obviously L and E, where L is a constant value greater than 1 and E is a constant value less than 1. What the values are set to controls at what recharge time the actual PPM is equal to the listed PPM and how strong the deviation is above and below that recharge time. Here's a graph to illustrate. In this example L is 2.51, E is 0.6, CastTime is 1 second, and PPM is 2 procs per minute. The green line is the current formula, the red line is the modified formula. As you can see, the modified formula boosts proc chance below a 10 second recharge time and lowers proc chance above a 10 second recharge time. The current formula hits the maximum proc chance around 26 seconds for this PPM, but the modified formula doesn't hit it until after 47. Here's a graph with all the same values except PPM, which is at 3.5: The primary thing to see here is that the curves still intersect at a 10 second recharge; this is the point at which the actual PPM and the listed PPM are equal. This consistent intersect makes the formula both easy to tune relative to the current formula and easy to explain to less mathy players; abilities with a ten second recharge get the listed PPM, abilities with a shorter recharge get more than the listed PPM, abilities with a longer recharge get less than the listed PPM. Here's a link to an interactive version of the formula so people can fiddle with the values. I'm not suggesting the above values for L and E, or even these specific modifications to the formula, are what we would actually want to go forward with; this is just a proof of concept to demonstrate that if the goal is to lessen the effectiveness of procs on abilities with long recharges and increase their effectiveness on abilities with short recharges we probably don't need to do anything more involved than modifying the proc chance formula. I don't think there's a need for a fundamental redesign of the proc system like other posters have suggested.

All I'm saying is that I don't find "I don't see it much" particularly compelling when the available data clearly demonstrates that it's tremendously popular.

Would you notice if someone was using it? It's not a particularly flashy set.

It's the most popular Scrapper set at level 50 by a huge margin...

The secondary is just as important, if not moreso. Thugs, Bots, and Demons to a lesser extent have enough survivability to work with almost any secondary, but the rest don't, and will need to be paired with a secondary that plays to their strengths.

I'm going to be very bold and propose that scaling resists should always take full effect no matter how large the hit is. The way they work now defeats the primary advantage resists have over defense.

They're basically arbitrary, I just wanted something that looked mostly sane at a wide range of PPMs. Definitely play around with it, I'd love to hear more of your thoughts.

@Bopper, here's a better explanation of what I'm suggesting. It's a graph of a modified version of the proc chance formula for a single target click power where y is proc chance, x is modified recharge time, TA is the power's activation time, P is procs per minute, L and E are scale factors I've added, and the green line is the current formula. I'm not saying we should go back to flat percentages, just skewing slightly in favor of faster recharging powers.

No, I'm suggesting something in between the original method and what we have now, where how far in between it is can be tuned by adjusting the weighting. PPM would decrease as recharge time increases, but not to the degree that the proc chance is constant.

We can solve all three of these at the same time, I think, by applying a weighting to recharge time in the PPM formula to skew the proc chance more in favor of short recharge powers. This will make it harder to turn long recharge powers into nukes, compensate for the cost of animation time in short recharge powers @oedipus_tex mentioned, and lower the damage loss of additional recharge so people aren't avoiding slotting recharge because it will hurt their proc damage. The downsides are that it turns procs into even more of math problem than they already are, and renders the actual PPM text meaningless, as the number of procs per minute would depend on the recharge time on the power.

Presumably the second option, but I don't see it as rewarding mastery over obtuse systems as much as providing build tension for minmaxers to chew on. In that I think it's pretty successful, while having the side benefit of allowing support ATs to build for some damage if they want to. The problem is that offers so much benefit to abilities that aren't meant to be relied on for damage that they can end up superceding abilities that are.

I've never argued FF competes with Time in practical scenarios...

Or we could look at +4s, which is what people actually run. Or we could look at +4 incarnates, which is the closest this game comes to actual difficulty, and where FF's def is twice as effective as Time's. But both of those are bad for the argument you're making, so sure, +3s are fine. And let's certainly ignore that in a real team either set will likely put everyone well above 80% def to everything.

Time gets significantly less defense than FF, significantly less -def and -tohit than Rad, no mez protection, and very little -regen. I'm not going to argue it's not better than both (though that's not a terribly high bar, especially for FF), but it's nowhere near the entirety of both. Maybe if you just look at buff/debuff types and ignore the amounts.

Good thing we're not talking about armor sets then. Again, Force Field provides 53% defense to the entire team without IO sets or incarnates. Are we pretending that would be allowed in an armor set?

Yeah, that actually sounds right now that I think about it, and it does seem generally correct from a balance perspective; defense provides resilience to def debuffs by making them less likely to hit, res should also provide some kind of innate resilience to res debuffs. But it's still icky. The better way to handle that would be for all sources of resistance to also provide resistance to -res, that way if the team wants a particular source of resist to not do that, they have a way to make that change.

Yup. Ultimately, damage resistance and damage should just be separate attributes. It really, really doesn't make sense for damage resistance to be implemented as res(damage) if you think about it for more than a few seconds. This isn't even the only problem it creates. How would resistance to -res be implemented under the current system? Can it be?

Assuming I understand the system correctly, this would also prevent those powers from having their damage/damage resistance increased by enhancements, which defeats the point.

Oh for sure, the cat's out of the bag now

Hmm. It seems to me like the real problem here is that damage resistance is implemented as Res(DamageType) rather than as its own attribute.