Stargazer

I think that sometimes there's a breakdown in communications, sometimes between players and devs, sometimes between players and QA, and sometimes between QA and devs. This is unfortunate, because often you could avoid a lot of grief by changing something right away (when fewer people are affected by it) instead of waiting until it becomes relatively common (not infrequently because people discover that they can take advantage of it, and flock to it because "it's good" and "it's been this way for such a long time that it's probably not going to change").



This current situation is a fairly good example of that.
The behavior was noticed, /bugged, and PMd within days of the Real Numbers system being introduced. At the time people were already benefiting from it (and had since the IOs were introduced), but they generally didn't know about it, and if a change had been made they probably wouldn't even have noticed. Moreover, since people weren't aware, they weren't actively building towards it, and only got the bonuses by accident.

Fast-forward two years, and the situation is entirely different. The behavior is fairly well known among people who are interested in IO mechanics, and people are knowingly taking advantage of it in their builds. There was probably an upsurge of this when Physical Perfection was introduced, and I'm pretty sure that it's been an important factor in how some players have planned their builds.


If the change had been made back then, most players probably wouldn't have noticed. The ones that did would probably have been surprised that they ever had the bonus, and would probably for the most part be understanding (though I'm sure there would have been exceptions).

Now, it's changing something that people have planned builds around, and lots of players are knowingly taking advantage of it.


Bugs should of course be fixed even (maybe particularly) if people benefit from them (and seek them out for this reason), and people should have definitely seen this change coming (so I'm not really feeling sorry for them).
However, there *will* be people who are upset about this (to varying degrees of course), and it will at least inconvenience the players who'll change their builds because of this (again, not a reason to not fix the issue).

This could have been avoided if four flags (two for the Numina, one each for the Miracle and the Regenerative Tissue) had been changed two years ago.

The easy fix here is to simply make the Defense Debuff Resistance unaffected by enhancements (this is already the case for the majority of powers that give DDR). If you like, you could increase the base DDR given by these powers to offset the change a little.

That is of course assuming that you want to prevent the DDR from being enhanceable. It's possible that it's a desired effect.


Shield is however also subject to something related that I have a hard time believing is a desired effect.

The Recharge debuff resistance given by Grant Cover is also affected by buffs.
This has the interesting side-effect that any Recharge debuffs placed on the user will actually reduce their Recharge debuff resistance.


Grant Cover gives a 30% Recharge (debuff) resistance.
However, since this resistance is affected by Strength modifiers, both from enhancements and from outside sources, we get the following behavior:


1) The Recharge resistance is increased by Recharge buffs (from */Rech enhancements slotted into the power, or from buffs such as Hasten or Recharge set bonuses)

2) The Recharge resistance is *decreased* by the very Recharge *de*buffs it's intended to resist.
This leads to a recursive decrease in Recharge resistance as the effective Recharge debuffs increases for every server tick (as the resistance goes down).

Here be math. The specifics aren't really all that important (the general behavior is), so if you'd like you can probably skim the next part.

Example:
A 50% Recharge debuff (D).

After one tick, the effective debuff (E) is 50%*(1-30%) = 35%
This reduces the Recharge resistance, and after two ticks the debuff is 50%*(1-30%*(1-35%)) = 40.25%
After three ticks the debuff is 50%*(1-30%*(1-40.25%)) = 41.04%
After four ticks the debuff is 50%*(1-30%*(1-41.04%)) = 41.16%
After five ticks the debuff is 50%*(1-30%*(1-41.16%)) = 41.17%
After six ticks the debuff is 50%*(1-30%*(1-41.17%)) = 41.18%

This is to where the resistance will converge.

We can calculate the effective debuff (E) for a given applied debuff (D) by:
E=0.7D/(1-0.3D)

(much like how Accuracy buffs stack recursively in Combat Training: Offensive, and used to in beta i13 Focused Accuracy)

For D = 50% this gives us E = 41.18% (as mentioned above), which is an effective 1-41.18/50 = 17.6% Recharge resistance (down from the base 30%).

The stronger the Recharge debuffs on you are, the lower your effective Recharge resistance will be (i.e. the more you need it, the less it'll give you).

Note that the formula is only valid up to an applied Recharge debuff of 81.08% (at which point you'll reach the 0.25 StrMin for Recharge). This also means that at an applied Recharge debuff stronger than 81.08%, you'll get no benefit from the Recharge debuff in Grant Cover.
(at a 81.08% debuff, the effective Recharge resistance is 7.5%)

If you want to know the Effective debuff (E) from an applied Debuff (D) when you also have a Recharge *buff* (R),
E = D*(.7-.3*R)/(1-.3D)

(with Hasten, a 50% Recharge debuff is reduced to a 50%*(.7-.3*70%)/(1-.3*50%) = 28.82% debuff, for an effective resistance of 1-28.82/50 = 42.35%)

bottom line:
The Recharge resistance given by Grant Cover increases with Recharge buffs or slotting, and decreases when you're affected by the very Recharge debuffs it's intended to protect against.

To me, this seems strange.
It's a potentially interesting mechanic, but I don't think it was intended to behave this way.

There are relatively few powers (PP is one of them) that accept both Heal sets and Endurance Modification enhancements, so it's relatively rare that you can boost the Recovery given by the Numina (and the Miracle) proc.

However, any power that accepts Heal IO sets also accepts Heal enhancements, so the Regeneration bonus given by both the Numina and Regenerative Tissue procs could (and still can in the case of Regenerative Tissue) always be boosted in any power you can slot them in (i.e. all powers that take Heal IO sets).

They were informed about it just over 2 years ago. I'm sure they get a lot of reports though, and they have to prioritize which ones to act on (sometimes I get the feeling that they down-prioritize my PMs somewhere around "Hi").


Anyway, I agree with you. I wouldn't conclude that this fix is because of any upcoming game additions. The situation definitely became much more known after the addition of Physical Perfection, and that may have been the extra nudge that was required to make the devs do something about it.

The Miracle: +Recovery and the Regenerative Tissue: +Regeneration procs still have their effects amplified by appropriate enhancements slotted into the same power. I'd expect them to be similarly changed Soon(tm).

But if they were focusing on MA from the start, then hiring them was by default taking up resources that would have otherwise been used on something else. Similarly, if they can not make an impact anywhere else, then keeping them is using resources that could otherwise be used for something else. Unless of course they're working for free...


Of course this doesn't mean that spending resources on MA is a bad idea, but if you have a dev completely dedicated to MA, then MA is most definitely using up resources that could have otherwise been used on something else. The question is if you feel that it's worth spending these resources on the MA, and the decision was made that it is.

If "the MA dev" is working for free (and insists on only working on MA stuff), then sure, whatever time they spend on MA could not have been spent somewhere else. However, since I'm presuming that they're actually being paid, this is not the case - the money that's used to pay their salary could instead be used to pay a dev to work on something else. If anything, having a "single function" dev is the extreme case of "locking up" a resource.

Anyway, even if that wasn't the case, you still also have several *other* devs working on MA from time to time, so there'd still be time spent on MA that could in theory be used elsewhere.


That's not really interesting though. The question is "simply" if it's worth spending resources on developing the MA, and the devs clearly believe that this is the case.

This is related to something I find a bit annoying.

When running missions on a team, it's only really the team leader/mission owner that gets to see the full story. Other team members have the option of reading the mission briefings, but they can not see the *de*briefings. Further, they often do not get to see the clues associated with the missions either (recently some clues have been given to the entire team). Taken together, debriefings and clue texts can contain a significant portion of the story given by the missions, and this is something that only the mission owner gets to see.

This basically leaves other team members with the following options:
1) Ask the mission owner to copy the information for them
2) Look up the information on some external source (e.g. Paragon Wiki)
3) Run the missions again as a mission owner (now that we can simul-complete missions, it's sometimes possible to run your own missions in parallel to the team mission, thus at least giving you the debriefings).
4) Miss out on the information, thus leaving them with only fractured parts of the story given in missions.

I believe that most people opt for the latter alternative (the other options tend to be disruptive and/or unpractical). This is a pity, since there's a lot of interesting story in the game. To me at least, this is even more of an issue for Mission Architect missions. There we no longer have the option of simul-completing missions, and there are usually no external sources to refer to either (besides, I've already run most "normal" missions about umpteen times each anyway, so I'm fairly familiar with their stories. That's not the case for MA missions). Further, many MA missions have a strong story-focus, and the lack of debriefing/clue texts can really reduce the enjoyment you get from some of them.

So, I'm hoping that these things are among the i17 "enhancements" (or that they're added at some future date):
1) The ability for non-mission-owners to read mission debriefings for missions that the team completes.
2) That clues given in the currently active mission are also given to non-mission-owner team members (possibly with a few exceptions if such are warranted).


To me at least, those changes would make running MA missions on teams much more attractive than it currently is.

Sorry for the delayed response.

It's almost like that, but not quite.

What we get is:

Final Resistance = Unresistable Resistance + Resistable Resistance * (1 - Unresistable Resistance).

If we like we can separate buffs from debuffs, giving us:

Final Resistance = Unresistable Resistance Buffs - Unresistable Resistance Debuffs + (Resistable Resistance Buffs + Resistable Resistance Debuffs) * (1 - Unresistable Resistance Buffs + Unresistable Resistance Debuffs)

Since Resistance Buffs as a rule are Unresistable, this can generally be simplified to:

Final Resistance = Resistance Buffs - Unresistable Resistance Debuffs - Resistable Resistance Debuffs * (1 - Resistance Buffs + Unresistable Resistance Debuffs)


Looking at it as two steps would give:

Working Resistance = Resistance Buffs - Unresistable Resistance Debuffs
Final Resistance = Working Resistance - Resistable Resistance Debuffs * (1 - Working Resistance),

which is basically the same as what you wrote, with "Total Debuffs" replaced by "Resistable Resistance Debuffs".

(and I think that's what you meant)

Numerical error detected.

s/24/240

Alert: Backlog has grown beyond desired parameters.

I'm not sure if this still happens somewhere, but there was a time when you'd sometimes find lower level mobs in the middle of mission-spawns. This happened a lot for Crey, and you'd frequently find grey-conning Lts (Crey Crisis Unit I think) among the "normal-conning" mobs.

For a brief period Claws/Follow Up gave buffs that obeyed Combat Modifiers (higher buffs against lower level foes), which made these Lts convenient Follow Up targets.

Not that I'd ever think about doing something like that of course...

Achilles' Heel *always* gets its own entry. It has to, since the Combat Attributes window shows each "source" separately (in this case the debuffs even have different origins, the Acid Mortar debuff is used by the Acid Mortar, and the Achilles' Heel debuff is "used" by the target).


(picture showing the Mastermind version of Acid Mortar against a -5 foe, base debuff = 20%)



It is also not a case of lack of accuracy, nor is it the case that the Defender version of Acid Mortar was accidentally set to ignore Combat Modifiers for the Resistance debuff.


(picture showing the Defender version of Acid Mortar against a -3 foe, base debuff = 26.60%)


Are you sure that you read the Combat Numbers window correctly? Maybe there was one entry for Acid Mortar and one for Achilles' Heel, and you happened to latch onto the number for Achilles' Heel?

It'd be interesting to see a screenshot of what you describe.

The power info window for Paralytic Blast does indeed show it as still giving -Recovery Strength.

I still don't think this was the reason for the current behavior though.

For starters, other procs don't behave this way.
The Performance Shifter: Chance for +Endurance ignores Endurance Strength.
The Kismet: +ToHit ignores ToHit Strength (and ToHit Str is not entirely uncommon).
The Panacea: +Heal/+End ignores both Heal Strength and Endurance Strength (but does accept Regen Str for its PvP component).


Second, why would this guideline not extend to set bonuses? Regen set bonuses ignore Str, as do set bonuses for Defense (and Def Str is *way* more common than Regen Str).

Third, I wouldn't insist on strictly following such a guideline just in case I might potentially want to add things in the future that would make it useful, if doing so would mean adding massive (and rather unintuitive) side-effects to the current behavior of the IOs. I would especially not do this in this case, since having these IOs start out ignoring Str modifiers and then changing them to be affected by Str modifiers downstream (if I add things that would require this) would be a strict buff, and thus probably would not cause much of an uproar among players.


As it is, the Numina and the Regen Tissue procs are *only* slottable into powers where they will be exposed to this fairly unintuitive behavior, and they can be strongly affected by it.

It seems odd to me that the Regen/Recovery procs are treated differently from just about every other IO effect out there, especially since it is *always* trivially easy to take advantage of this effect for the Regen procs.

There's also Drain Psyche and the Warshade power Stygian Circle.

Last time I checked the Numina/Regen Tissue/Miracle procs also obeyed Combat Modifiers ("level difference scaling", "purple patch") though, so when slotted in these powers they give a lower effective Regen/Recovery buff when used against higher level foes (and a higher effective buff when used against lower level foes, but I generally find myself fighting higher level foes more often than lower level foes).

This generally makes it less than ideal to slot these procs into powers that affect foes.


edit: Oops, forgot to mention Drain Psyche.

I don't think that's accurate.
Regeneration- and Recovery-debuffs don't tend to be Regeneration Str and Recovery Str, they tend to be straight Regeneration and Recovery.

(off the top of my head, I actually can't think of any Regen/Recovery debuffs that are Str debuffs)


Plainly put, Regen/Recovery debuffs don't tend to work by reducing the effect of other Regen/Recovery debuffs, they tend to directly reduce the target's Regen/Recovery.



Personally I like to believe that they behave this way because the behavior wasn't anticipated.

To the best of my knowledge, the enhancability of Miracle's Recovery buff was first shown in the very same post that first showed the enhanceability of the Regeneration buffs given by the other Healing set procs.

Oh, I forgot to mention...
The effective debuff would only be different from 20% if the AV in question has any Resistance of the appropriate type. Since many AVs have 0 Resistance to at least some damage types, it's quite possible for Achilles' Heel to give an effective -20% Resistance to an AV.

The Achilles Heel proc gets its own entry in the Combat Attributes window, so it should not have shown up under Acid Mortar. You should have gotten one entry for Acid Mortar (showing a fairly low number), and one entry for Achilles Heel, showing 20%.

As has already been mentioned, the reason that the Purple Patch does not reduce this number is that it is a power granted to the target.


It always *shows up* as -20%, but depending on the resistance of the target, it doesn't always *give* -20%.

The reason for this is that the sub-headings (the entry for each power) for each attribute shows the "natural" value given by that power, before resistances are taken into consideration (but after Combat Modifiers ("purple patch"). This means that these values are not always representative of the actual effect on the target.

The "main headings" for each attribute show the accurate (post-resistance) totals however.


e.g., if you have:

Smashing Resistance: x%
---Resistance affecting power 1: y%
---Resistance affecting power 2: z%

, then the value given for Smashing Resistance is guaranteed to be accurate, but the values listed for Resistance affecting power 1 and Resistance affecting power 2 might not be.
(Resistance buffs are generally unresistable, and will thus generally show the correct values. Most Resistance Debuffs are however resistable, and will thus show inaccurate values when your (unresistable) Resistance is non-zero (unresistable Resistance is what is used to resist resistable Resistance).


If you had a power called "Resistance Buff" giving you 50% Smashing Resistance, and a power called "Resistance Debuff" giving you -50% Smashing Resistance, the Combat Numbers display should show you this:

Smashing Resistance: 25%
---Resistance Buff: 50%
---Resistance Debuff: -50%

Resistance Debuff is *showing* -50%, but the actual debuff the target experiences is -50%*(1-50%) = -25%.
Thus, the total Smashing Resistance is 50% - 25% = 25%.

So, to find out the effective debuff of a power, you will often need to back-calculate it from the *total*, instead of looking at the entry for that specific power.


Going back to the case of Achilles' Heel, its entry should always show -20%, but if the target has Resistance, the effective debuff will actually be lower than this.

One Shield issue down (I may have been more comfortable if it'd been a moderate damage increase for Scrappers and a moderate decrease for Brutes (with Tankers getting the corresponding change), but this is a definite improvement), one (or more, depending on how you look at it) to go.



Grant Cover gives a 30% Recharge (debuff) resistance.
The thing is, this resistance is affected by Strength modifiers, both from enhancements and from outside sources.

This means two things.

1) The Recharge resistance is increased by Recharge buffs (from */Rech enhancements slotted into the power, or from buffs such as Hasten or Recharge set bonuses)

2) The Recharge resistance is *decreased* by the very Recharge *de*buffs it's intended to resist.
This leads to a recursive decrease in Recharge resistance as the effective Recharge debuffs increases for every server tick (as the resistance goes down).

Here be math. The specifics aren't really all that important (the general behavior is), so if you'd like you can probably skim the next part.

Example:
A 50% Recharge debuff (D).

After one tick, the effective debuff (E) is 50%*(1-30%) = 35%
This reduces the Recharge resistance, and after two ticks the debuff is 50%*(1-30%*(1-35%)) = 40.25%
After three ticks the debuff is 50%*(1-30%*(1-40.25%)) = 41.04%
After four ticks the debuff is 50%*(1-30%*(1-41.04%)) = 41.16%
After five ticks the debuff is 50%*(1-30%*(1-41.16%)) = 41.17%
After six ticks the debuff is 50%*(1-30%*(1-41.17%)) = 41.18%

This is to where the resistance will converge.

We can calculate the effective debuff (E) for a given applied debuff (D) by:
E=0.7D/(1-0.3D)

(much like how Accuracy buffs stack recursively in Combat Training: Offensive, and used to in beta i13 Focused Accuracy)

For D = 50% this gives us E = 41.18% (as mentioned above), which is an effective 1-41.18/50 = 17.6% Recharge resistance (down from the base 30%).

The stronger the Recharge debuffs on you are, the lower your effective Recharge resistance will be (i.e. the more you need it, the less it'll give you).

Note that the formula is only valid up to an applied Recharge debuff of 81.08% (at which point you'll reach the 0.25 StrMin for Recharge). This also means that at an applied Recharge debuff stronger than 81.08%, you'll get no benefit from the Recharge debuff in Grant Cover.
(at a 81.08% debuff, the effective Recharge resistance is 7.5%)

If you want to know the Effective debuff (E) from an applied Debuff (D) when you also have a Recharge *buff* (R),
E = D*(.7-.3*R)/(1-.3D)

(with Hasten, a 50% Recharge debuff is reduced to a 50%*(.7-.3*70%)/(1-.3*50%) = 28.82% debuff, for an effective resistance of 1-28.82/50 = 42.35%)

bottom line:
The Recharge resistance given by Grant Cover increases with Recharge buffs or slotting, and decreases when you're affected by the very Recharge debuffs it's intended to protect against.

To me, this seems strange.
It's a potentially interesting mechanic, but I don't think it was intended to behave this way.

I'd suggest making the Recharge Resistance unaffected by Str modifiers.

I'm not really familiar with Maxthon, but...

There's a Maxthon plugin called More Scripts (link), and if you install it you should then be able to install the Quick Links script from its userscript page.

(works for me in Maxthon 2.5.8.1332 at least, though I may have needed to click the "Run and Manage User Scripts button" (that is added by More Scripts) to enable the Quick Link script after it was installed)

More information about More Scripts can be found here.


I've been meaning to update the script, and if/when I do, I'll add the information about how to install it for Maxthon too.


Also, first post from Maxthon.


edit: Oh, I should clarify something. The script is not really "for Firefox". While userscripts *can* include browser-specific code, they tend to use standardized code that work on a multitude of browsers. This particular script works without modification on Firefox (with Greasemonkey), Opera and Maxthon (with More Scripts), and I would assume that it would also work on Safari and Chrome. What differs is how you *install/use* the script on each browser, and since I'm not using all browsers, I don't know how to do that on all browsers. I chose to describe how to install it for Firefox/Greasemonkey since 1) Lots of people use Firefox, and 2) *I* use Firefox/Greasemonkey, so I'm familiar with the procedure. To find out how to use userscripts for other browsers, a web search for "userscripts <browser name>" is usually a good place to start.

I don't really see any added risk here. Sure, if you leave a computer without logging out from the forums, someone can queue a copy to Test, but... there's really not much harm in that. At worst you get some undesired copies on Test (which I suppose might give a small annoyance in some cases, but that's about it). I suppose someone could find out the name of all your characters, but... again, I wouldn't be very worried about that.

I don't think there'd be any additional risk with regards to the account information itself.

There are several things I like about i16, but, as silly as it might seem, this is among the top things.

You'd get more Regeneration by moving the two Numinas from PP to Health, but this would come at the cost of some Recovery.

If you don't want to sacrifice any Recovery, you could still move the Numina: Heal from PP to Health, and replace the plain Heal in Health with a Numina: Heal/End (or Heal/Rech). This would give a tiny (<0.3%) increase in Regeneration, but the main benefit would be that you get more of the Regeneration earlier in the build. The only downside would be that a Numina: Heal/End tends to cost more than a plain Heal, and some that are only interested in high-level performance might not feel that the tiny increase in high-level Regen is worth this cost.


It might be worth noting that the addition of PP (and thus relatively widespread ability to slot both Heal and EndMod sets in a power suitable for procs) could give added incentive to close the loophole that allows us to "enhance" the effect of these procs. Basically, don't be too surprised if things should suddenly change.