Arcanaville

[ QUOTE ]
[ QUOTE ]
[ QUOTE ]
So....which is "tier 1"....Hurdle or Sprint? Hover or Air Superiority? Hasten or Flurry?

[/ QUOTE ]

Technically: Sprint, Hover, and Flurry.


[ QUOTE ]
The word "tier" does imply the lvl you can take it. A "lower tier" or "higher tier" anything is not something with the exact same requirements. In this case...lvl 6....you can take either of the tier 1 powers in a pool. You certainly don't have to do anything extra to earn what you are referring to as "tier 2". (And we still don't know which power is "tier 2")

This was just badly worded for what they mean.

[/ QUOTE ]

Actually, the term "tier" has never had that meaning generally accepted. Players have consistently referred to both the final primary power and final secondary power as a "tier 9" power, which ignores level availability. In fact, the phrase "tier-9" itself has been used often enough that it has a special meaning: the phrase "Instant Healing is Regen's best Tier-9" has unambiguous generally accepted meaning. But even discounting that, if I were to ask players to name the tier 8 power in Energy Blast and Energy Manipulation, I'm reasonably sure the overwhelming majority would be naming Explosive Blast and Boost Range, not Nova and Boost Range.

Furthermore, during the Defiance 2.0 discussions, the three powers you can use while mezzed were most often referred to as the "tier 1 and 2 primary powers and tier 1 secondary power" and not the "three tier 1 blaster powers." This was true by overwhelming margin, even though the second phrase would have been shorter. Its obvious most players are not inclined to describe powers in that way.

Just for fun, I decide to search for the word "tier" among all of the threads I have saved from the forums 2006 and earlier, and interestingly I found *zero* instances of people referring to powers by "tier" except for tier 9s. I found several instances of people referring to inspirations by tier.

Random sampling of relatively recent posts shows the term "tier" when used to refer to powers to most often refer to "tier-9" powers; the first two powers in primaries or secondaries are most often referred to as "tier 1 and 2" and much less often referred to as "the two tier 1s;" and in context are often used specifically to refer to order where no other terminology exists (tier 6 invention bonuses, tier 2 inspirations, tier 3 mastermind pets). It is only very rarely used to denote level-unlocking.

The most common usage of the word tier by overwhelming margin is to denote the place in the order of a list, where the list has well-accepted definition in context (the "tier 3 pets" for masterminds for example are a generally accepted synonym for the tier 8 mastermind primary power entities). The presumption should be that the phrase "the tier 3 power of the flight pool" refers to Fly, given what the majority consensus meaning of the word "tier" would be in almost every other context.

(The most likely way to naturally reference all four powers of a power pool would seem to be to refer to "All powers in the Flight pool" rather than "tier 1, 2, 3, and 4 powers in the Flight pool.")

[/ QUOTE ]
All this confirms what I suspected...

We are using the word "tier" wrong.

[/ QUOTE ]

And have been for a very long time. Its a Nemesis plot.

[ QUOTE ]
So....which is "tier 1"....Hurdle or Sprint? Hover or Air Superiority? Hasten or Flurry?

[/ QUOTE ]

Technically: Sprint, Hover, and Flurry.


[ QUOTE ]
The word "tier" does imply the lvl you can take it. A "lower tier" or "higher tier" anything is not something with the exact same requirements. In this case...lvl 6....you can take either of the tier 1 powers in a pool. You certainly don't have to do anything extra to earn what you are referring to as "tier 2". (And we still don't know which power is "tier 2")

This was just badly worded for what they mean.

[/ QUOTE ]

Actually, the term "tier" has never had that meaning generally accepted. Players have consistently referred to both the final primary power and final secondary power as a "tier 9" power, which ignores level availability. In fact, the phrase "tier-9" itself has been used often enough that it has a special meaning: the phrase "Instant Healing is Regen's best Tier-9" has unambiguous generally accepted meaning. But even discounting that, if I were to ask players to name the tier 8 power in Energy Blast and Energy Manipulation, I'm reasonably sure the overwhelming majority would be naming Explosive Blast and Boost Range, not Nova and Boost Range.

Furthermore, during the Defiance 2.0 discussions, the three powers you can use while mezzed were most often referred to as the "tier 1 and 2 primary powers and tier 1 secondary power" and not the "three tier 1 blaster powers." This was true by overwhelming margin, even though the second phrase would have been shorter. Its obvious most players are not inclined to describe powers in that way.

Just for fun, I decide to search for the word "tier" among all of the threads I have saved from the forums 2006 and earlier, and interestingly I found *zero* instances of people referring to powers by "tier" except for tier 9s. I found several instances of people referring to inspirations by tier.

Random sampling of relatively recent posts shows the term "tier" when used to refer to powers to most often refer to "tier-9" powers; the first two powers in primaries or secondaries are most often referred to as "tier 1 and 2" and much less often referred to as "the two tier 1s;" and in context are often used specifically to refer to order where no other terminology exists (tier 6 invention bonuses, tier 2 inspirations, tier 3 mastermind pets). It is only very rarely used to denote level-unlocking.

The most common usage of the word tier by overwhelming margin is to denote the place in the order of a list, where the list has well-accepted definition in context (the "tier 3 pets" for masterminds for example are a generally accepted synonym for the tier 8 mastermind primary power entities). The presumption should be that the phrase "the tier 3 power of the flight pool" refers to Fly, given what the majority consensus meaning of the word "tier" would be in almost every other context.

(The most likely way to naturally reference all four powers of a power pool would seem to be to refer to "All powers in the Flight pool" rather than "tier 1, 2, 3, and 4 powers in the Flight pool.")

[ QUOTE ]
[ QUOTE ]
[u]57 Months[u]

Abiding Badge: 50% discount on all tailor sessions: Start out your new characters in style!


[/ QUOTE ]

As stated by numerous people (myself included) this vet reward seems a bit cheap. Fifty percent off at the tailor after 57 months, after you've earned numerous free tailoring sessions (not to mention the free ones we get occasionnaly) is pretty lack luster, not to mention near pointless.

Something that is close to this and would be greatly appreaciated, would be a facemaker/icon employee base detail, so we could change costumes in our bases. Or maybe an option to change costumes wherever we are.

[/ QUOTE ]

There is one escape hatch here. The devs could have datamined how many free costume tokens the "average" long-term player burns through, and how much they spend on costume changes, and determined that the 50% discount actually *would* benefit a significant percentage of the players nearing eligibility for the badge. Its really difficult to extrapolate how other players are or are not using these things.

Before veteran rewards were introduced, I changed costumes on my main perhaps fifty times playing around in Icon, paying for each and every one of them. I do that a lot less now, and have never actually exhausted the free costume tokens on my characters now that I have them. But who knows how many long term players never stopped being clothes horses.

[ QUOTE ]
In addition to their track record of actually giving a darn (in general) what their customers think, I'm a voice in a lot smaller crowd here than in the rest of the world. Out there, it'd be ludicrous to think that I could even make myself *heard* by those who control things, totally apart from their willingness to listen. Here, though, it's not nearly so impossible.

BABs Back Alley Brawler BAB Castle Posi Positron Sunstorm Blue Steel Pohsyb Ghost Widow War Witch

There, I just made nearly certain that at least one dev will likely see this post. There's no way I could pull that off in real life.

[/ QUOTE ]

Unless you're a figment of my imagination, you did just pull that off in real life.

[ QUOTE ]
I explained why pretty well like two posts up. It's less a matter of 'hey here's a nice thing for players' and more a matter of 'the longer it continues the more the resources to make them are wasted on an ever-shrinking segment of the population, which will eventually reach a point where it'd make more sense to make things everyone can enjoy because the people who can benefit from them is disproportionate to the effort to add them'.

[/ QUOTE ]

I would have to object to the word "wasted" as used here. Connotation without demonstration. If its a genuine waste of resources, it should not be done regardless of the number of people its wasted on.

[ QUOTE ]
Okay, thanks for clarifying now.

So you ARE classifying powers into tiers by their numerical order.

Okay, I can live with that.

[/ QUOTE ]

Actually, its probably too strong of a statement to say that the devs "classify" powers into tiers conceptually. The word "tier" is just a convenient way to refer to the different powers in a set: it isn't intended to imply much beyond numerical order.

(The powers system doesn't have any real sense of "tier" - powers have Requirements which are essentially prerequsities. The primary, secondary, and pool powers all have minimum level requirements which can be adjusted by the powers designers. They don't assign "tiers" to them as such.)

[ QUOTE ]
Robes, skirts, and other shoot that goes beyond the knee looks like trash. I have tried to make a long skirt but it just doesn’t work out to my high standards of fine quality. If I think it looks bad that means you; the players, will loathe it even more.

[/ QUOTE ]

Jay: "Matt, Brian, I swear the long skirts still look ugly: the tools just don't let us make nice-looking long skirts."

Brian: "Well, if you can't make them longer, I guess you'll have to make them shorter. Much shorter. Selling an expansion pack full of mini-skirts won't be a problem, will it?"

Positron: "No problem. I'll have BaB get started on that trampoline emote right away."

[ QUOTE ]
[ QUOTE ]

another person, like everyone at MS, that doesn't understand the commercials? The commercials aren't about users, like MSes "I'm a PC" junk. The commercials are just people representing the computer, its the computer that's talking to you, not the person using the computer. They show "PC" as a persona of the commonly thought of business type of look... they say nothing about the actual users.

[/ QUOTE ]

Actually, MS'es "I'm a PC" ad's show that like their users, theres a wide variety of PC's of all shapes, sizes, and flavors, and can't be summed as a single image.

[/ QUOTE ]

The Mac commercials (like most Apple product commercials) attempt to send the message that the cool kids run Macs, and the stodgy people run Windows.

Microsoft's response to this seems to be to say that far from stodgy, many Windows users are actually downright strange.


Strictly from an advertising perspective, Microsoft's "I'm a PC" ad campaign is, to put it mildly, completely inexplicable.

[ QUOTE ]
Cool! So this means you're now working on the Amiga version, right?

Right???

That's ok, I can wait...

[/ QUOTE ]

If NCSoft wants to impress me, they can get started on an iPhone port.

[QR]

Just a quick note: some of the latest changes I promised I haven't had a chance to make and upload yet: I haven't forgotten about them, but I've been heavily tied up with work. Usually, work affords me lots of time to keep up with the forums. At the moment, the reverse has been true. Hopefully, I'll have time to return to this (and other things) soon.

On the subject of threads, except for when I'm time-crunched I try to keep up with all the damage mitigation related ones, or at least the ones that don't go completely over the cliff into absurdity. I used to be able to say I read practically all of them, but for the last six months I've been slightly more selective due to time constraints.

[ QUOTE ]
[ QUOTE ]
Of course, the reason its a spreadsheet and not just a table of numbers is because I'm assuming that most of the people interested in such a thing would not hesitate to modify the numbers to reflect their own analysis assumptions.

[/ QUOTE ]

This may be true for some people who like to dig in and explore a bit, but I wouldn't be surprised in the least if some download it and take what's presented at face value. More dangerous is those same people trying to propagate it as fact.

There's not much (if anything) you can do to prevent that, of course.

[edit: Yeah, I know, that's a little cynical.]

[/ QUOTE ]

I considered not releasing this version at all, because as I mentioned I really haven't had the time to carefully proof it for errors, and this version has dramatic changes from the previous version (which had some minor errors to be sure) which were almost guaranteed to generate large goofs.

Because people asked, and because I figured more eyeballs would quickly correct any errors faster, I elected to release with warnings. Generally speaking, peer review is the fastest way to generate an error-free (or nearly so) version of things like this, and so far I haven't been disappointed there.


Now, separate from that, even if the numbers and formulas in the sheet were precisely correct, it *still* can be abused in a lot of ways. Implicit in all damage mitigation calculations is a basic assumption: the calculations consider all reasonably objective and mathematically analyzable factors, and in a way that its reasonable to assume that all other factors are either relatively equal, or very obviously set aside.

We presume, for example, that people know that Electric Armor's true value is its calculated passive damage mitigation *plus* whatever mitigation that endurance drain is providing, which means its some degree higher than calculated. We presume that while quick recovery offers no direct damage mitigation benefit, its nonetheless a very strong qualitative strength of any powerset that contains it, separate from calculated damage mitigation.

The spreadsheet doesn't say which sets are "better." It attempts to quantify what the relative value is of the things it counts. Is that useful? Well, in head to head comparisons, it very often is. If I decide to compare the relative performance of Invuln and Willpower, I can say that its very likely that if Willpower has higher calculated performance than Invuln, that its very likely that the non-mitigative benefit of quick recovery is probably going to have a much greater benefit that the tohit buff in Invincibility. That's a qualitative evaluation in and of itself, but its not difficult to defend. The computed numbers reduce the size of the playing field that qualitative judgement must play in.


One last thing: if I were a game designer (technically, I'm not sure I can make that negative hypothetical statement anymore) I would recognize that my computational analysis tools had limits, and therefore I would have to be cogniscent of what those limits were. But given that, I would strive to ensure that what I *could* quantify was reasonably balanced, so that the remaining parts I couldn't quantify could at least be controlled. Whether the devs actually do that, I still consider it a useful point of reference to judge how well they designed and balanced the different powersets.

In other words, suppose I was going to make a new powerset called "shields" and it was going to be primarily defensive in nature, but it was going to have some interesting powers that were not going to have easy to compute benefits. I would still want to *know* what the difference in performance was between a comparable powerset, say SR, and what I *calculate* for this hypothetical "shields" powerset, so I knew how much gap in performance I was dealing with. I could then at least have a *target* for how powerful these new gizmo powers could and should be.

It would be useful to know if "shields" was 50% of the strength of SR, or 75%, or 90% - or even 125% - to inform my intuition as to whether the unquantifiable parts of the powerset were strong enough without being overpowered. So even when you can't quantify everything, its still useful to quantify what you can.


But that's a subtle point not everyone fully appreciates. Just because the numbers are accurate, doesn't make them complete. But just because the numbers are not complete, doesn't make them unreliable either. The numbers said Willpower was going to be quite powerful, and it turned out to be exactly that. They also said Shields would be significantly weaker than peers, separate from its offensive abilities, and that turned out to be on the mark as well. With sufficient analysis care, the numbers tend to be dead on bullseyes when predicting relative performance.

The best I can do is state the above, so that for every person that quotes my calculations, someone else can quote my disclaimers in context.

[ QUOTE ]
Just noticed...

The summary table shows the values for nonpositional Psi, not the relative composite values.

[/ QUOTE ]

I noticed that as well, while repositioning things. Also, while trying to see what a chart of those numbers might look like (I'm going to probably have an "experimental" chart in the second tab of the workbook just for giggles). Should be uploaded sometime late tonight.

The reason that sort of error keeps coming up as I move things around has to do with the fact that the VLOOKUP functions correctly update cell references when rows and columns move, but do not update offset values commensurately. A danger of using lookup tables in general.

[ QUOTE ]
I need a larger monitor...

[/ QUOTE ]

Yeah, even on my 24" monitor, its a bit ridiculous.


[ QUOTE ]
Kheldian Nova forms are missing the 15% Resistance to Energy/Negative.

[/ QUOTE ]

Will fix this and upload new version when I get a chance (probably late this evening).


[ QUOTE ]
For the cells with options (<power> On/Off, #target select), the actual selection button shows up in the cell to the right of the cell you are choosing an option for.

[/ QUOTE ]

Yeah, that was a problem in the original spreadsheet, and I put a buffer column into the sheet to prevent that from being a problem. Then I reintroduced the problem when I compacted the options selectors into multiple columns. What I think I'm going to do is move the "sandbox" column to column E, and then move the window pane lock to column E, so left-right scrolling will keep the sandbox at the left, and with it guarantee that the pulldowns whose controls are visible in that column (in this case, Health, Tough, and Shield Allies) are always visible. Its the quickest hack that I think will have the lowest probability of disrupting anything.

[ QUOTE ]
Something else to keep in mind... look at the slotting for Dark Regen (cells U145 and U149). It's assuming 2 heal SOs and 2 rech SOs. That leaves 2 slots for acc and end reduc - which is very light on both. I think a more standard slotting for Dark Regen would be 2 acc/end/rech, dropping the heal enhancement entirely... at least until IOs.

Also, don't forget to change the level factor for WP. WP is stronger against even cons than up level foes because the purple patch starts to diminish RttC's tohit debuff. (Which, I might add, Arcana's spreadsheet assumes is fully slotted for tohit debuff. I don't think I've ever seen a build with RttC's regen and tohit debuff at the ED softcap.)

[/ QUOTE ]

Some values are admittedly judgement calls. In many cases, I simply applied what I considered the highest credible (non-invention) slotting values. Since even common IOs can push the slotting (even with generous endurance reduction) higher than those values, I thought it wasn't too extravagant. And one concession to complexity here is that all assumptions revolve around level 50 comparisons, where things like slot count and power availability aren't issues. Its definitely not a completely fair way to compare powersets anywhere lower than that. So its more of a mitigation potential comparison than a direct mitigation comparison.

I didn't put a lot of thought into what value to slot RTTC tohit debuff with, to be honest.

Of course, the reason its a spreadsheet and not just a table of numbers is because I'm assuming that most of the people interested in such a thing would not hesitate to modify the numbers to reflect their own analysis assumptions.

[ QUOTE ]
[ QUOTE ]
Damage Mitigation Spreadsheet

[/ QUOTE ]

But, but, but, where's the mitigation for Knockback listed???

[/ QUOTE ]

When I figure out how to add fear, stun, and endurance drain into a mitigation spreadsheet in a relatively non-arbitrary way, knockback will be next on my list.

[ QUOTE ]
Two problems with Shield:

1) You updated True Grit's MaxHP buff (7.5% -> 10%) for base Shield, but you didn't also increase that to 10% for the OwtS category. Speaking of which...

2) You didn't include OwtS's enhanceable 20% +MaxHP.

Misc Problem:

*) You haven't updated Stalker's base hp. It is no longer ~1017, now it's 1204.8.

Inquiry:

*) Right now, when the scalars are set to Stalkers, it adds Hide to VEATs and Kheldians. Intended, or oversight?

[/ QUOTE ]

Fixed the two shield issues and the stalker health cap.

Hide is iffy, since the original intent of the sheet was to show what would happen if you ported a powerset to a different archetype (its originally a proliferation analyzer, not just a comparison tool). I'll think about that one, although it is trivial for anyone to knock Hide out of the Kheldian and VEAT columns if they think that's invalid.

Corrected version uploaded to the same link (the file is still called a4a-latest.zip, although the actual spreadsheet in the zip file usually has a different name as I make changes, in this case, its I13b5).

[ QUOTE ]
It may or may not be worth noting the new level factor pulldown breaks Open Office. (It changes D3, D4, and all the damage cells E193->AV243) to a red #N/A. I don't think OO likes the +X notation. If I change cells S269 to S276 from +X to just X, it works just fine.

Haven't got the time to fiddle with it too much, but it looks nice so far.

[/ QUOTE ]

Hmm, I'll try to see if I can figure out what's going on there. I should really test it under OO, but I hadn't gotten to that yet. Just a note that a couple more minor glitches were discovered last night, and I uploaded an updated version about eight hours ago or so.

Also, someone asked me to put the chart back that graphed the survival of the different archetypes. Problem is, I don't recall actually making such a chart. I might have played with one and uploaded it a while ago but none of my saved versions has that chart. If anyone else actually has a version with a chart, let me know. In any case, the next uploaded version will probably have a chart of some kind either way, since its a nice idea and doesn't cost a lot in complexity (I'll put it on a different worksheet), but I'm wondering how I could have forgotten something like that in the first place.

Note: someone spotted a bug with the Diminishing Returns calculations for Resistances, which I've fixed (the link is still the same), and I also accidentally moved the survival chart (the table from the far right) to a funny place: its now relocated to the top right of the spreadsheet.

Also, for those that want the simpler version, I've uploaded the older v5 of the spreadsheet (which predates Shields, Diminishing Returns, and all my wild restructuring) as:

http://www.peregate.com/arcanaville/files/a4a-v5.zip


Also, I forgot to mention that the updated spreadsheet has I13 versions of Invuln and Energy Aura, on top of the new Shields powerset.

Hopefully, not too many other glitches in there.

Edit: well, not totally clean yet: another off-by-one error for the psionic defense row. Corrected version uploaded

The latest version of my "Every melee mitigation set for every melee archetytpe" spreadsheet is now uploaded to the peregate ftp site (thanks again for the hosting there) and available for download with the following link:

http://www.peregate.com/arcanaville/...a4a-latest.zip

I will try to use this guide thread to post updates and such to the spreadsheet, but first a couple of warnings:

1. Real Life (tm) has intruded quite a bit for me recently, and I'm unable to spend as much time as I would like analyzing CoH numbers (lots of end of year crunch things, many of them requiring travel). So I've been stalled trying to update the spreadsheet as much as I would like to. As a result, it might have typos or other spreadsheet errors, although I've tried to ensure it doesn't have too many really bone-headed goofs. However, I would appreciate it if anyone that finds a problem lets me know, so I can correct the spreadsheet for a future version.

2. I was trying to see how much stuff I could jam into it. I think this is the limit before it implodes into a black hole or starts to call Cenobites. If its too complex for some, I apologize for that. I'm currently thinking of a way to present the information and all of its options better. Better might not be Excel any more. But if you think I went overboard, you're probably right.

3. I've restructured the spreadsheet so that things like computational and lookup tables are at the bottom, not the top anymore. When there were just a few, it made sense for them to be at the top, where it was easy to tweak the numbers. Now, there's just too many: you're *only* looking at tables and not actual powersets if they stay on the top.

4. Reminder: spreadsheet might not work correctly if you open it read-only. It warns about that due to the way I created the spreadsheet, but you probably want to open it read-write so you can play with it.


And now, some info on the new features:

1. I've added Shields. I *think* the Shields numbers are correct, based on (relatively) recent forum discussions, but of course it seems everything about I13 is fluctuating quite a bit.

2. I've added support for diminshing returns in the spreadsheet. There's a pulldown that turns DR calculations off and on, for Strength, Cur, and Res attributes. I *think* that works correctly, and I *think* I have the latest DR parameters in the spreadsheet. But this required a lot of structure changes to the spreadsheet, and this is probably the area I have the highest chance of messing up somewhere.

3. There's also support for a "PvPmode" pulldown that at the moment, mostly turns on the PvP resistances per archetype. It does *NOT* specifically incorporate Elusivity calculations yet. I specifically and deliberately kept "PvPmode" and "Diminishing Returns" separate, even though at the moment DR only occurs in PvP. This is NOT because I have any knowledge of DR being ported to PvE: everything I know currently says that isn't going to happen for the foreseeable future. I did it mostly to allow myself to better see what DR was doing to the numbers separately from any other effect, just for my own benefit.

4. There are two ally pulldowns: one for Kheldians and one for Shields. The Kheldian one increases the number of team mates that buff Kheldian resistance, and the Shields one is mostly for its own ally-tapping power, and can be set separately.

5. There is an experimental "Defense Debuff" parameter, where you can see what happens when the archetypes are exposed to defense debuffs or a particular value. Instead of a pulldown, there is a fill in the blank for the global defense debuff value. Set to zero to turn off. Each archetype also has a value for defense debuff resistance, which is based on the *maximum* debuff resistance they could theoretically have. I consider this experimental for a number of reasons, not the least of which is the point that differing values for defense can *avoid* non-autohitting debuffs, which means this is an interesting data point, but not a directly fair across the board comparison. But it can help inform judgement.

6. There is a better implementation of the purple patch scaling, so it properly scales both player effects on foes downward, and foe attack effects on the player upward, with increasing level. There is still no rank scaler, sorry (meaning, powers that affect different ranks differently aren't supported yet: think warshades). Use the appropriate pulldown, and the two separate values will update themselves automatically (don't type numbers in there unless you have a specific reason to do so).

The original thread seems to have been purged, and I've been asked to repost this, so I'm reposting in the Guides section so it doesn't get purged again. This is a copy of the original post: I haven't edited it in any way (so if the original had typos or minor errors, this one might as well - sorry, don't have enough time to proof it better at the moment).

Although I will say that since this article was first published, a number of posters have used these basic calculations to attempt to predict their damage output under a variety of circumstances where its possible to measure actual damage output reasonably accurately. So far as I'm aware, the time calculation model presented here seems to be consistent with all of those tests to within a high degree of accuracy. So I believe its safe to say that the model has been independently confirmed by multiple posters.

I'm also told that this model is increasingly being referred to as "ArcanaTime." Kind of like Bullet Time, but with more math I suppose. Nevertheless, I preserved the original title of the post, since I think its more descriptive. I also decided against calling it "Guide to X" for the same reason.

Also: Power Slice still be slow.


-----[Guide follows below]-----

How long does this attack chain take:

Nimble Slash -> Ablating Strike -> Power Slice -> One Thousand Cuts

Simple question, right? Nope. The answer to this question has *major* repercussions for anyone attempting to quantify how much damage any powerset can do. I've been looking at aspects of this one question in a sense for over a year now, and I've been focused on a specific aspect of it that no one has ever really investigated in any detail until now (I doubt even the original or current dev team has thought about it much). Its a bit complicated, so I'm going to start at the beginning, and hopefully get to the end before too long.

The cast times for those powers are:

Nimble Slash: 1.03s
Ablating Strike: 1.03s
Power Slice: 1.03s
One Thousand Cuts: 3.3s

So naturally that chain should take 1.03 + 1.03 + 1.03 + 3.3 = 6.39 seconds, right?

Actually, if you time it, you'll probably get something closer to 7.39 seconds. But that's just lag, isn't is?

If you mean network lag, its not. But first, how do you measure the duration of that attack chain as precisely as possible? The methodology I've used for years now is to use demorecords. When you demorecord a sequence of events, the demorecord file has (in a differential form) timing information that says when each event happens, and it has millisecond precision. Its actually possible to record a sequence and know it took exactly 7392 milliseconds, if you know how to read the demorecord files.

But are demorecord files accurate? Suppose they only record when the *client* sees something happen? If that were the case, then all that millisecond precision would be somewhat worthless, because network lag would cause different events to be delayed by different amounts, and make the measurements unreliable.

As it turns out, demorecord timings appear to encapsulate when the *server* thinks something should happen. If you record the same events from two different computers, logged in to two different characters, the demorecord timings tend to be identical (they are sometimes off by one millisecond for some events, which might be round-off error). This is true even if the two computers are connected to two different networks, with two different paths to the game servers, and with two different amounts of network lag. So the demorecord timing information appears to be reliable *and* a window into what the *server* sees and does. If the demorecord says a sequence of events takes 7392 milliseconds, that is exactly how long it takes according to the game.

Even so, network lag can still cause problems. When I push a button, it takes some time for that event to get sent to the servers. There is a difference between when I do something, and when the servers *know* I did something. That could still cause a delay between when an attack *should* go off, and when it actually *does* go off.

That delay can be eliminated with attack queueing. If you queue an attack (tell the server to fire it, while you are still executing a different attack) that message gets sent to the server *immediately*. Even if it takes 300 milliseconds to get to the servers from your computer, as long as you send it 300ms before the attack *could* fire, that command will be waiting on the servers for the moment when the attack can actually be fired. Queueing attacks (if you do it fast enough) eliminates network lag. The server basically has a queue of attacks, and fires them off as fast as possible. So if you queue that attack chain above, the amount of time it takes should be the *fastest* that the game servers can possible execute them, which is another way of saying that's how long that attack chain theoretically takes.

Is an attack chain the sum of its cast times? For years now I've measured attack chains using the demorecord method and queued attacks. I do it so that I can measure what I call the "attack time" of an attack: the amount of time it takes up in an attack chain. I've always assumed in the past that this was a way to measure the cast time of the power, plus or minus a certain margin of error. It turns out that this method never seems to get any closer than about 180ms (0.18s) from the "published" cast times. Why is that?

As it turns out, there are *two* things that have to happen before you can fire off an attack. One: the cast time for the previous attack must have expired. Basically, when you cast an attack, you have to wait the cast time before you can use another attack. Two: the Rooted time of the animation of the attack must also be completed.

When an attack is executed, it causes you to perform an animation - a sequence of moves that visually represent the motions of the attack. Most attack animations are flagged with a special flag called CANTMOVE. This basically means that while that animation is playing, the player cannot perform any character movement, and cannot activate any other powers. It basically locks you out of doing anything until the animation of the attack finishes.

This is important. If a power has a cast time of one second, but it plays a rooted animation that lasts for two seconds, then for two seconds you can't attack again. You basically have to obey whichever one is [u]higher[u].

BackAlleyBrawler has been working to clean up a lot of discrepancies between cast times and rooted times, because if they are different, the cast time will be misleading to players (especially now that the Real Numbers system displays cast time). There's no trivially easy way to display "Rooted Time" so the players will have no idea their attack is actually slower than it is documented to be.

Some attacks still have discrepancies, though (the vast majority of the one's I've identified have been fixed by BaB). One of the powers that *hasn't* been fixed yet is actually Power Slice. Back in beta I measured PS to be about 1.4 seconds in duration, plus or minus. However, its documented cast time was actually 1.03 seconds. That's *far* outside my margin of error: there is no way for my method to be off by 0.4 seconds, ever.

However, I'm not measuring cast time: I'm actually always measuring the *higher* of cast time or rooted time. Clearly, the rooted time of the power must be higher than the cast time, and that was what caused by I11beta measurements to be "off." In fact, Power Slice's animation roots the player for exactly 41 frames of animation, or about 1.37 seconds, and that's what my I11beta measurement was actually measuring: the *true* time that attack "takes."

However, the rooted times for all the other attacks are equal or less than the cast time, so only Power Slice actually takes longer to animate (and root the player) than its cast time takes to expire. The attack chain should then execute in:

1.03s + 1.03s + 1.37s + 3.3s = 6.73 seconds. That's still quite far from 7.39 seconds, and still way outside of my margin of error.

Time to back up a bit. I didn't *actually* measure PS to be 1.4s. I actually made an educated guess that it was 1.4s, based on my actual measurements. I actually measured PS to be closer to about 1.6 seconds long. But I applied a correction factor. I also measured the "attack time" of brawl during my measurements. Its my reference measurement: Brawl (back then) had a 0.67 cast time, and I could use that to calilbrate my measurements for other systematic errors. Based on my measurements of Brawl, my I11beta measurements appeared to have about 175ms of "extra time" in them. I therefore corrected all my measurements downward by about 175ms to calibrate them to Brawl. My 1.6s PS became about 1.4s as a result.

Where was this 175ms "error" coming from? That has been a long standing question of mine, going back over three years in fact (ever since I invented the measurement technique). I finally decided to determine once and for all what this error was, and whether it was something that was special to me and my setup, or something more fundamental.

My typical lag during measurements is about 220ms according to /netgraph. There's no way it could be responsible for a 175ms delay between attacks. Moreover, if I'm queueing the attacks, network lag shouldn't factor in at all (tests confirm that if you queue an attack, that message is sent immediately, and no further signal from the client is required to execute the attack: it'll go off even if you disconnect). So why was I measuring attacks to take 175ms longer than they should have been taking?


I had a suspicion that what I was seeing had something to do with the game server processing loops. It doesn't matter if something is "supposed" to happen exactly 1030ms later: the server can't literally execute an attack when its supposed to, because it can only fire attacks off at some maximum speed. Most game systems (and real time and pseudo-real time systems like game servers) use a processing loop that is executed so many times per second, each time checking to see if something is supposed to "happen." In a complex system, there might be many different execution loops going on. The time interval from the start of one loop to the start of the next loop is often referred to as the processing quantum or the tick interval. I was guessing that even if I had a queued attack, it could only fire when the next tick interval came up.

But 175ms seemed to be quite a long time for the tick interval to be, and its an odd number. If I'm seeing 175ms, its more likely the clock quantum was something like 250ms (one quarter of a second), and that seemed *way* too long.

As it turns out, based on conversations with the devs, two things are causing my rather longish measurement for the clock quantum. First, my guess that powers could only fire aligned to a server "combat clock" were correct. However, what I *didn't* anticipate was another feature of the combat engine. The game doesn't "check" to see if all the conditions needed to fire an attack existed on the fly: that would take too long when making attack decisions. Instead, every combat clock, the game checks to see if the character is in the "Ready to Shoot" state (that's just what I call it). If it is, it executes the queued attack. If its not, it doesn't. *After* that, the game engine checks all characters to see if they meet all the conditions necessary to be allowed to fire an attack: if so, its *then* flagged "Ready to Shoot."

See the problem? When an attack is running, the character is not in the correct state to fire another attack. It has to wait. When the attack finishes, and the (rooted) animation is over, and the cast time is over, its *still* not ready to shoot. It has to be *flagged* to be ready. But by then its too late to fire during that clock tick. It has to wait for the *next* clock tick to actually fire.


This is the anatomy of an attack sequence:

Ready --> Activate --> Animate/CastTime --> Completed --> Flagged Completed --> Activate Next Attack

From the moment the power is Activated, an *integer number* of clock ticks must happen before it can be flagged completed, and then *one more* has to happen before the next power can activate. So its not just what the power's cast time is, or even its rooted time, that determines the powers' "attack time." Its *real attack time* is actually always going to be:

[RoundUp(CastTime / ClockInterval) + 1] * ClockInterval

In other words, it will take a whole number of clock ticks, rounded upward, plus one.

So what's the clock interval. The answer is: I'm not 100% certain. I *believe* its about 132ms. Where does that number come from? Two sources: its a reasonable fit for all of my measurements, and it agrees with what I've been told about the game engine, which is this (and this is only necessarily true for attack processing: other things might run on different clocks): the game is designed to *simultaneously* process one combat loop every 125ms, but *also* not to do anything until the next *animation* clock (and once again, that's what I'm calling it, not what its actually called, since I don't know what its called).

There's a 30 tick per second clock that is used to sync up certain game events, and its probably specifically intended to sync the server with the game client. So after the combat clock ticks 125ms, the 30clock has only ticked 3.8 times: it has to wait until 30clock tick #4, which happens at about 132ms-133ms (33 * 4 = 132, 33.33 * 4 = 133.32). So the game engine only checks on the status of attacks about every 132ms.

That means a power that has a cast time of 1.03 seconds - 1030ms - takes 1030/132 = 7.8 combat clock ticks to execute. The game won't *know* that attack is "done" until tick #8 (8*132 = 1056ms = 1.056s). It won't be able to execute the next attack in the queue until tick #9 (9*132 = 1188ms = 1.188s). So a power with a cast time of 1.03 seconds (and a rooted time of about the same value) will actually "burn up" 1.188seconds of time, not 1.03 seconds of time, in any attack chain. That's the *minimum* amoutn of time that attack will burn up: nothing you do can make it go faster. Even if you patched your computer directly to the game servers to eliminate all possible lag, and kicked everyone else off that server so its full processing power was focused only on you, Nimble Slash is *never* running any faster.

So long as you queue your attacks and the server isn't overloaded, its never running *slower* than that either. Network lag is totally irrelevant as long as you queue attacks. So this time - 1.188 seconds - is actually the best estimate for the attack's "true" duration.

Nimble Slash and Ablating Strike actually both take 1188ms according to this theory. Power Slice takes 1584ms. OTC takes 3432ms. Add them up, and you get 7392ms, or about 7.4 seconds. And that turns out to be very close to the actual measured time for that chain (in fact, I tend to measure that chain to be about 7420ms on average, plus or minus 100ms).

So far, I've tested the theory against Dual Blades, Martial Arts, and Energy Blast, plus some other assorted attacks. The theory matches measurement usually to within 30ms, and often to within 20ms (less than one visual frame of animation). That's pretty good: I'm currently examining the question of whether there is another source of systematic error that can account for even *that* discrepancy, or if its simply an artifact of averaging dozens instead of thousands of attack chains to average out the jitter intrinsic to all of these measurements (when the server decides to do something every 132ms, that doesn't mean *everything* will be done instantly: it could happen anywhere within that 132ms window, which causes "jitter" in the measurements that can be partially averaged out).


What does this mean? Well, it means everything actually takes longer than we think it does, by an average of about 198ms, plus or minus (for complex reasons, its actually slightly lower than that). And that value isn't constant: it depends on the actual cast time (and rooted) time of the individual power: the value can be anywhere from about 132 to 232ms (that's nearly a quarter of a second). And most importantly, this will affect different sets differently. I say "affect" but of course, all powers and powersets have been living under these conditions since the very beginning of time. What I mean are the on-paper calculations of how much damage a powerset does. Faster attack chains will be hurt more than slower ones. Low cast time powers will be hit proportionately harder than high cast time powers.


If you are a DPS fanatic, it also means a few other things. It means whenever you are not queueing attacks, you are taking a substantial penalty in damage over time. Just the act of switching targets when one dies and re-activating the attack (instead of switching targets *before* it dies and queueing the next attack, assuming it dies) costs more in damage over time than the difference between the best and worst single target attack sets in any archetype. And it means ironically very short cast time attacks (i.e. 0.83 seconds) aren't necessarily as good as they appear, because its surprisingly difficult to keep such attacks queued ahead of time. They are not bad, but difficult to *make work* as fast as they could be.


If BaB makes a change to an animation, sometimes that change will have no impact on DPS at all, because it won't affect the actual DPA of the attack in true terms. Sometimes it will have a higher impact than you might expect. It really depends.


And finally, it means one should always be careful about trusting paper calculations. They are only as good as the input numbers to them. I myself am a strong proponent of good analysis, and even good analysis can be incomplete due the availability of the facts. But I also believe all numbers and all anaysis should be questioned. We're given cast times now, and lots of other numerical information about our powers. That information is presumed to be "authoritative" and so there is a greater acceptance of calculations based on those numbers. But the way the game processes those numbers can sometimes be more complex than it first seems. There's no substitute for testing things carefully.

That doesn't mean I believe anecdotes are stronger than analysis: anecdotes can be poisoned by all sorts of observer problems to a higher degree than paper calculations can be. But I am saying that in spite of the access to raw data we have now, and maybe even because of it, rigorous testing is more important now than its ever been. Especially since much more faith is placed on numerical calculations now than it ever has been in the past.


Basically, fast is never as fast as it looks on paper. At least not without this modification to attack time.

[ QUOTE ]
No offense since I'm sure Arcana and Castle put a TON of work into this whole system...
But the Initial Results of some Tests seems to indicate that the game was actually MORE BALANCED and less "binary" before they ever bothered with this mess.

Where you guys might be seeing a "Soft Curve".... I'm clearly seeing an abrupt Hard-Cap that is both prejudiced and discriminatory against many builds and Archetypes in general who never deserved such levels of "Nerftitude". ...atleast not in PvP anyway.

In other words...
It looks like we traded in the mean old boss we used to have for an even meaner older boss

[/ QUOTE ]

1. I had no input into the diminishing returns formula.

2. It would not have been my first choice.

3. Yes, there are some issues with debuffs - although some of those issues are related to the issue of what the original intent of foe debuffs are supposed to be. For example, players typically equate tohit debuffs with defense, and presume that anyone that possesses tohit debuffs "obviously" is intended to have their protection no differently in principle than someone with defense buffs. But that might not be true. It *is* true, however, that the current diminishing returns system has little flexibility to distinguish any difference between buffs and debuffs, even when the intent *is* for them to operate differently.

4. Mitigation powers are generally being given Diminishing Returns factors that are "soft-cappy" in nature, to account for the fact that their value accelerates as they get stronger. However, things like Damage buffs aren't (last I checked) set to values that are soft-cappy, and are gentler in degredation (and actually, with some tweaking, it works perhaps better than ED does in that regard).

5. Given the way the Diminishing Returns system is currently designed, proper PvP balance will have to be a meet in the middle affair, with powersets that are affected more strongly than desired being bumped upward in power strength to their desired (relative) strength. This was always going to be mandatory anyway. However, that doesn't mean that everyone will *agree* with where powersets ultimately end up. That's going to be an inevitable source of unresolvable debate.

[ QUOTE ]
[ QUOTE ]
[ QUOTE ]
Arcanaville, thanks for all that information.

Would it be possible to see what one of these curves actually looks like as an example? It would certainly help me.

[/ QUOTE ]

I'm working on something that normal humans might understand, but its a bit tricky because the DR curves change characteristics somewhat depending on what A and B are. In general, the DR curves start heading upward at some close to linear slope, but then at some characteristic point they start to level out. Depending on the A/B parameters, it sometimes continues ascending upward at increasingly slower rates, and with other A/B parameters it more closely resembles hitting a "soft" ceiling. It'll probably need pictures to illustrate more fully. My time to make them is a bit limited, but I should have some this week unless someone else trumps me in that regard (I wrote this mostly for the quants to get started cranking numbers, and they're equally likely to attempt to write explanations for what's going on in there before I get around to it).

[/ QUOTE ]

Okay, I had a friend of mine whip this up. It should allow you to input an A and B, and then hit Refresh to graph Arcana's formula given that A and B. Mouseover for the specific numbers.

[/ QUOTE ]

I forgot to add a correction I originally posted in the closed beta post: surround the ATAN() function with ABS: i.e. ABS(ATAN(stuff)). The function is symmetric about the origin.

[ QUOTE ]
How do you get all this information all the time? Do you do some illegitimate things and should be banned? You are very suspicious and I have never trusted you. Clear your name, now, woman!

I fail to see why the devs would let you into the closed beta.....

[/ QUOTE ]

I'm sorry. I should be punished. Everyone, I have stolen from my developers. Please, purge me. I'm ashamed of myself. I should be arrested. I should be purged. I should be flogged. I shouldn't walk among good people. I'm a swine, a wretch; I don't deserve to live like others.

[ QUOTE ]
Arcanaville, thanks for all that information.

Would it be possible to see what one of these curves actually looks like as an example? It would certainly help me.

[/ QUOTE ]

I'm working on something that normal humans might understand, but its a bit tricky because the DR curves change characteristics somewhat depending on what A and B are. In general, the DR curves start heading upward at some close to linear slope, but then at some characteristic point they start to level out. Depending on the A/B parameters, it sometimes continues ascending upward at increasingly slower rates, and with other A/B parameters it more closely resembles hitting a "soft" ceiling. It'll probably need pictures to illustrate more fully. My time to make them is a bit limited, but I should have some this week unless someone else trumps me in that regard (I wrote this mostly for the quants to get started cranking numbers, and they're equally likely to attempt to write explanations for what's going on in there before I get around to it).

I'm reposting this from the closed beta forums. I haven't checked the open build yet, so my rule of thumb numbers for the diminishing returns parameters for different archetypes might be off: treat as educated guesses until I (or someone else) posts more accurate tables (which I will try to do this weekend if I have time: pretty busy recently. But at least on these forums I have functioning "code" tags for tables).

Warning: if you're not a quant, if you're not knowledgeable in how the game works, if you do not know what Aspects and Attributes are, and don't want to know, just wait for a planner to do the math for you.

Guide follows below:


Guide to Diminishing Returns

The formula for diminishing returns in PvP is:

[u]FinalValue = OriginalValue * (1 - ATAN(A * OriginalValue) * 2/pi * B)[u]

Where ATAN(x) is the ArcTangent of x.

(Note: this is not the dev formula exactly, its expression has been slightly simplified from the original).

However, this requires significant explanation. Here are the rules for diminishing returns.

1. (At the moment) Diminishing Returns only affects players when in PvP zones (including the Arena).

2. Diminishing Returns affects Attribmods.

3. Diminishing Returns only affects Attribmods that affect Res, Cur, and Str Aspects of Attributes.

4. Diminishing Returns affects totals only.

5. The A and B parameters are set per archetype, per attribute, and per aspect.


These rules probably demand some clarification, although Rule #1 is pretty self evident. Its somewhat beyond the scope of this document to describe the inner workings of the game engine in detail, so suffice to say that each Attribute has a Cur (or Current) value, which represents basically what its "value" is. If your Smashing_Attack Cur is 0.2, that means you currently have 20% smashing defense. The Res value attached to each attribute is a measure of how much this thing will resist attempts to change *any aspect* of that attribute. So if Smashing_Attack Res is 0.3, that means this thing will resist 30% of any attempt to change Smashing_Attack Cur, or Smashing_Attack Res, or Smashing_Attack Str. *Any* aspect change will be resisted, unless the change is the result of an unresistable attribmod. Smashing_Attack Str or Strength represents how much to amplify any attribmod (power effect) that this thing casts that affects Smashing_Attack. So if this thing has 1.4 Smashing_Attack Str, that means if this thing casts a 10% Smashing_Attack Cur buff upon itself, that buff would be increased to 1.4 * 10% = 14%.

Real world example: SR scrapper has Focused Fighting, slotted with +0.56 defense enhancement.

Focused Fighting has a 0.13875 Melee_Attack Cur buff (it also has the scaling resistances and other attribmods which we will ignore for now). The slotted enhancements have a total buff of +0.56 Melee_Attack Str (they also have +0.56 Ranged_Attack, +0.56 AoE_Attack, +0.56 Smashing_Attack - you get the idea. Since Focused Fighting doesn't do anything to those attributes, those strength buffs don't do anything to the power, as they have nothing to strengthen). This means as far as Focused Fighting is concerned, the player's Melee_Attack Str is 1.56 (the base strength values for all attributes is 1.0). So when the player runs Focused Fighting, it casts a buff on the player of 0.13875 (13.875%) to the player's Melee_Attack Cur. However, that is strengthened to 1.56 * 0.13875 = 0.21645, or 21.645%. The player's Melee_Attack Cur is now 0.21645.

Now, what the Diminishing Returns rules above say is this: Diminishing Returns only affects Attribmods, which means basically *effects*. It does not affect the base value of anything. For our purposes, that's buffs, debuffs, and other effects like damage (which is basically a health debuff). In our example, the buff from the defense enhancements would be reduced by diminishing returns, and then the net buff from Focused Fighting would be reduced by diminishing returns afterwards.

Suppose that for Melee_Attack Str A = 0.33 and B = 0.8; for Melee_Attack Cur A = 1.2 and B = 1.0. This is now what would happen:

First, the strength buff from enhancements of +0.56 would be reduced by diminishing returns (not the total Strength of 1.56: just the 0.56 buff). DR(0.56) when A = 0.33 and B = 0.8 is ~ 0.51. So the actual Melee_Attack Str is 1.51, not 1.56, due to enhancements.

That means the Melee_Attack (Cur) buff (prior to diminishing returns) is 0.13875 * 1.51 = 0.2095, or about 20.95%. Then, because that is a Cur buff itself, *that* is reduced by diminishing returns. DR(0.2095) when A = 1.2 and B = 1.0 is 0.1767, or 17.67%.

Therefore, without diminishing returns, 13.875% with +0.56 enhancement is 21.645% defense. With diminishing returns (in this example), its 17.67%.


Now, what are A and B? Unfortunately, its actually theoretically possible for A and B to be completely different for every attribute, for any of the three aspects covered by diminishing returns, and for every archetype. That's 14 different archetypes, about 71 different attributes, and three different aspects each with a pair of parameters: 5964 values. At the moment, that's a bit difficult for me to post. But while they can all be different in theory, they aren't actually in practice in most cases. Here are what appear to be the current rules for those values:

1. The default values for A and B are 0.33 and 0.8, respectively, for all Str and Res aspects unless otherwise noted.
2. The default values for A and B are 1.0 and 0.0, respectively, for all Cur aspects unless otherwise noted (note: B = 0.0 means no diminishing returns)
3. Damage Res is 1.2/1.0 for all damage res types possessed by players (i.e. smashing, lethal, fire, cold, etc).
3a. Special case #1: Tanker Damage Res is 0.8/1.0
3b. Special case #2: Scrapper/Brute/Stalker Damage Res is 0.6/1.0
3c. Special case #3: VEATs and HEATs are 0.9/1.0
3d. Special case #4: Mastermind Res is 1.8/1.0
4. Heal Str is 0.33/0.8. Heal Res is 1.0/0
5. Endurance Cur is 0.01/0.666
6. Tohit Cur is 2.0/1.0. Tohit Str is 0.33/0.8
7. Attack/Defense types Cur are currently 3.0/1.0
8. Movement Cur is 0.15/0.55 for all movement attributes (RunSpeed, FlySpeed, SpeedJumping, JumpHeight)
9. Stealth and perception Cur are 0.33/0.0
10. Recovery Cur is 0.33/0.33
11. Regen Cur is 0.06/1.0
12. All Mez Cur are 0.33/0.8. This includes knockback/knockup
13. Recharge, EnduranceDiscount, and InterruptTime Cur are 0.33/0.8
14. Hitpoints (meaning +health buffs): Cur is 1.0/0.0, and Str is 0.33/0.8

Disclaimer: these values are subject to change. Also, I have a google docs spreadsheet that has all of the values and a calculator function for every archetype and every attribute/aspect. It dates from a while ago but the only values that appear to have changed from that build to now are ones that affect teleport, intangible, untouchable, and onlyaffectsself attributes. I will try to update the sheet when I can. Also note the sheet has a minor bug: its missing an Absolute function in it, so it only works correctly for positive numbers. That's no biggie, because DR is symmetric. Just enter positive numbers instead of negative numbers and you'll get the right result. This will be fixed in an update.


Now, last thing: as mentioned in the rules, its totals that count, not powers or even individual attribmods. So if you have one power granting a 10% defense buff slotted with +0.56 enhancements, and another power granting 5% defense with no enhancements, DR will kick in and reduce the slotting, and then that buff will be reduced to some value lower than 15.6% defense, and then that will be added to the 5% from the other power, *and then* the grand total defense buff (Cur) will be subject to DR.

In other words: DR(5% + 10% * (1 + DR(0.56)))

[u]NOT[u]

DR(5%) + DR(10% * (1 + DR(0.56)))

Suppose I also had Dodge, also slotted similarly. Well, in that case Dodge's enhancements would also be reduced to +0.51, and its buff would then be 5.625% * 1.51 = 8.49%. But then, the *total* Melee_Attack defense buff would be added up: 8.49% + 20.95% = 29.44%. Then *that* would be subjected to DR: DR(0.2944) = 0.2308, or 23.08%.

[u]Again: you do *not* apply DR to Focused Fighting and Dodge and then add. You add, then apply DR.[u]




Diminishing Returns FAQ

Q1: Does DR occur before, after, or simultaneously with ED (Enhancement Diversification)?
A1: As far as I know, ED happens first and is applied to enhancement bonuses, and then DR occurs afterward. For that matter, as far as I know, all effects on enhanements, such as exemplar effects, also happen first, before that Strength is looked at by Diminishing Returns.

Q2: What happens if I have +0.95 damage slotting, and I cast a power like Build Up (+100% damage)? What happens?
A2: DR happens on totals, not individual effects. So for that specific power the total strength bonus for damage is +1.95, and DR would be applied to that number for that power.
(Technically, DR would be applied to each damage attribute strength modifier separately, but at the moment all DR parameters for all damage types are identical, and likely to remain that way. It is *theoretically* possible for Fire damage to have a stronger DR curve than Ice damage, say, but I doubt that the devs are likely to do that).

Q3: What's not affected by Diminishing Returns?
A3: Any buff or effect that is not a Str(ength) buff or debuff, a Cur(rent) buff or debuff, or a Res(istance) buff or debuff would not be affected by Diminishing Returns. For example, Heals that Heal an Abs(olute) value of health are unaffected by Diminishing Returns. However, note that Heal Str(ength) buffs *are* affected. This means if you use slotted Reconstruction, the *slotting* is affected by DR, but the *total points healed* is not. As far as I know, all player heals are Abs heals. Other things that are Abs modifiers are things like Damage (from attacks). As a rule, if it does a very specific (and large) number of points of something, its probably not under DR. If it does percentages, it is (but that can be tricky: people "know" reconstruction as healing "25% base heal" but its actually an Abs that heals a specific number of points that just *happens* to be 25% of the health bar. The fact that recon does not scale upwards with +health is the giveaway its an Abs and not a Cur-like percentage buff, which would always heal a fixed percentage of a *bar* regardless of the size of the bar).

Q4: What do those A/B numbers mean? Is there any way to know "about" what they say?
A4: Not without doing the math. That Diminishing Returns equation actually has more complex behavior than it might seem from its expression. However, there are a couple of rules of thumb.

* If B = 0.0, that Aspect is unaffected by Diminishing Returns (regardless of what A is).
* The larger A is, the faster the DR curve will "level off" and reach a soft cap of some kind.
* The larger B is, the lower the soft cap will be.

If A=1.0 and B=1.0, the DR curve reaches 0.5 when the original value is 1.0, and then levels off around 0.63. Increase A to 2.0, and the DR curve reaches 0.25 when the original value reaches 0.5, and then levels off around 0.31. Notice that doubling A shrunk the curve roughly in half.

Q5: Why so complicated? Why not just one curve for everything, and everyone?
A5: Mainly because it wouldn't work. Different attributes have different ranges of values: we don't see +400% MaxHealth, but we do see +400% damage. Some things have small values and some large values, and some things have small ranges and some things have larger ranges. It would be difficult to make a one-size-fits-all diminishing returns curve that worked on +2000% regeneration buffs in a desirable way and also +25% defense buffs. That basically requires different kinds of attributes to have potentially different kinds of DR attributes in some cases. As to why different archetypes have different DR values, actually they *could* but currently *don't* except for just a few cases, which point to why that possibility exists: part of the intent of the DR system is to help balance PvP, and the devs want the option to tweak DR curves to allow different archetypes to reach different DR "softcaps" (although the term is being used here very loosely: many DR attributes don't "cap" in the same way ED does: it would probably be better to call them "softslopes") in different ways. As an example (which doesn't actually necessarily match the current numbers) you might want to make it easier for Tankers to quickly gain intermediate levels of resistance, but then you might not want them to continue to stack up much higher than that. You might want the tanker curve to be gentler at first, but then sharply level off near the top, relative to other archetypes. The system provides for that possibility (but its a possibility the devs are currently using very sparingly and still experimentally).


[ed: I'm adding a question I've been asked a lot in closed beta]

Q6: Does Diminishing Returns affect buffs and debuffs separately?
A6: No. As far as the game is concerned, buffs and debuffs are the same thing, just different sign. You add up buffs and debuffs together before applying Diminishing Returns. So if you have a +25% defense buff on you, and a -15% defense debuff on you, your net defense buff is +10%, and Diminishing Returns will then reduce that ten percent downward. It *does not* hit the +25% and -15% separately and then add up. Ever.



To reiterate: this is the *current* equation for Diminishing Returns, and the current values for the DR parameters as of the v18.20081015.0 build on test. Every single test build has had some differences in the DR parameters, and I believe they are still being tweaked (there are certain areas where the way it works creates problems, such as in the area of perception, so there's still a lot of work the devs have to do to address all the collateral issues). I'm currently trying to figure out a way to better communicate what the DR parameters are without spamming the forum with gigantic tables (and I'm not sure if the "code" tags are working yet either).

Castle has reviewed this (more or less) so I believe its accurate, but any errors are mine alone.