[MECHANICS] Attack Speed, Recovery Time, Reload Time

[MaxQuest]

So my thinking is that the way the modifiers are being combined, and with the inversion, what Obsidian is approximating is that all of these adjustments are to a rate of how quickly or slowly you move through attack frames.

Yeap. We can say so.

 

The example is simple with most positive cases: 5/(1 + sum(x)). +100% action speed really means we are increasing how many attack frames we process in the same time frame by +100%, so 5/(1 + 1) is how we represent that (we now have 2.5s recovery, or double speed advancing through attack frames). This is the same as dex and gunner from POE1.

Yeap. Thinking about speeding up attack frames is a bit complicating the view.

But we can express so too.

 

For net maluses, we can't just do 5/(1-x), because when we say you have +100% increased recovery, we are not saying that you take infinitely long to recover from an attack. Instead what we are saying is that +100% increased recovery means we have +100% delay between attack frames.

Yeap.

 

MaxQuest, you've shown that for a -25% modifier, Obsidian is storing .75 as the coefficient. So OK, in your example with the car, it makes sense because .75 would literally mean -25% actions for any given unit of time. However, it is clear that in other places Obsidian do care about things being modified as an effect on time (e.g. instead of slowing down by 25%, you extend the time it takes by 25%); thanks to your spreadsheet and the .bundle file, we see that arbalest ia a .75 coefficient, but warbow overdraw is a 1/1.5 coefficient. The former directly reduces how many actions you should take by 25% (which translates to a +33% degradation in your recovery time), whereas the latter is formulated directly as a degradation of your recovery time (a coefficient of .66 or -33% action speed).

Yeap.

 

That above distinction between how certain coefficients are computed just leads to a murkiness that is frustrating and requires a lot of care to pay attention to exactly what tool-tips are saying (and hoping that Obsidian was precise with their wording on each tooltip).

Yeap.

Although must note: afaik the displayed tooltip effect is generated automatically and thus is showing the corresponding type statuseffect.gamedatabundle:

 

 

TL;DR: bonuses to your action speed are equally weighted to maluses to your recovery time. bonuses to your recovery time are equally weighted to maluses to your action speed. On the other hand, bonuses to your action speed are outweighed by maluses to your action speed, and maluses to your recovery time are outweighed by bonuses to your recovery time. UGH

Yeap. Have represented that in the "examples" table in post above.

 

Frankly, Obsidian should just re-normalize all the numbers they use to be same "unit", so we don't have to keep track of what affects "time" or "speed" or whatnot. Then we can just add up all the numbers (like pillars 1). This is unnecessarily confusing.

Hah, that's exactly what I did for the calculator.

I am storing all as "speed coefficients". E.g:

 

var EFFECTS = [
  GenEffect(EFFECT_CATEGORIES.affectsAllPhases, 1.20, "Bloodlust", EFFECT_WR.any), 
  GenEffect(EFFECT_CATEGORIES.affectsAllPhases, 1.25, "Frenzy", EFFECT_WR.any, null, SUPPRESING_CATEGORIES.attackSpeedMult1),
  GenEffect(EFFECT_CATEGORIES.affectsAllPhases, 1.20, "Coral Snuff", EFFECT_WR.any, null, SUPPRESING_CATEGORIES.attackSpeedMult1),
  GenEffect(EFFECT_CATEGORIES.affectsAllPhases, 0.75, "Modal: Arbalests", EFFECT_WR.ranged, "Arbalest"), // Overbearing Shot
  GenEffect(EFFECT_CATEGORIES.affectsAllPhases, 0.75, "Modal: Crossbows", EFFECT_WR.ranged, "Crossbow"), // Interrupting Shot
  GenEffect(EFFECT_CATEGORIES.affectsAllPhases, 1.25, "Potion of Deftness", EFFECT_WR.any, null, SUPPRESING_CATEGORIES.attackSpeedMult1, null, false, 0.05),
  GenEffect(EFFECT_CATEGORIES.affectsAllPhases, 1.50, "Potion of Relentless Striking", EFFECT_WR.any, null, SUPPRESING_CATEGORIES.attackSpeedMult1, null, false, 0.01),        
  GenEffect(EFFECT_CATEGORIES.affectsAllPhases, 1.20, "Swift Strikes", EFFECT_WR.any, null, SUPPRESING_CATEGORIES.attackSpeedMult1),
  GenEffect(EFFECT_CATEGORIES.affectsAllPhases, 1.40, "Their Champion Chant", EFFECT_WR.any, null, SUPPRESING_CATEGORIES.attackSpeedMult1),
  
  GenEffect(EFFECT_CATEGORIES.affectsRecoveryAndReload, 1/1.5, "Modal: Battle Axes", EFFECT_WR.melee, "Battle Axe"), // Bleeding Cut
  GenEffect(EFFECT_CATEGORIES.affectsRecoveryAndReload, 2.00, "Modal: Hunting Bow", EFFECT_WR.ranged, "Hunting Bow"), // Rapid Shot
  GenEffect(EFFECT_CATEGORIES.affectsRecoveryAndReload, 1/1.5, "Modal: Quarterstaves", EFFECT_WR.melee, "Quarterstaff"), // Defensive Strike
  GenEffect(EFFECT_CATEGORIES.affectsRecoveryAndReload, 1/1.5, "Modal: Rapiers", EFFECT_WR.melee, "Rapier"), // Vulnerable Thrust        
  GenEffect(EFFECT_CATEGORIES.affectsRecoveryAndReload, 1/1.5, "Modal: Sabres", EFFECT_WR.melee, "Sabre"), // Windmill Slash
  GenEffect(EFFECT_CATEGORIES.affectsRecoveryAndReload, 1/1.5, "Modal: War Bows", EFFECT_WR.ranged, "War Bow"), // Overdraw
  GenEffect(EFFECT_CATEGORIES.affectsRecoveryAndReload, 1/1.5, "Modal: War Hammers", EFFECT_WR.melee, "War Hammer"), // Piercing Blows
  GenEffect(EFFECT_CATEGORIES.affectsRecoveryAndReload, 1.25, "Sure-Handed Chant", EFFECT_WR.ranged, null, null, null, true),
  GenEffect(EFFECT_CATEGORIES.affectsRecoveryAndReload, 1/0.80, "Two-Weapon Style", EFFECT_WR.any, null, null, TWO_WEAPON_STYLE_ID),        
  GenEffect(EFFECT_CATEGORIES.affectsRecoveryAndReload, 1/0.15, "Stealth", EFFECT_WR.any),        
  
  GenEffect(EFFECT_CATEGORIES.affectsReload, 1.25, "Shootist (Acina's Tricorn)", EFFECT_WR.ranged, null),
  GenEffect(EFFECT_CATEGORIES.affectsReload, 2.00, "Modal: Pistols", EFFECT_WR.ranged, "Pistol", SUPPRESING_CATEGORIES.reloadSpeedCoef1),
  GenEffect(EFFECT_CATEGORIES.affectsReload, 1.25, "Sure-Handed Chant", EFFECT_WR.ranged, null, SUPPRESING_CATEGORIES.reloadSpeedCoef1, null, true),
  GenEffect(EFFECT_CATEGORIES.affectsReload, 1.25, "Gunner", EFFECT_WR.ranged, null)
];

 

 

Although, I do partially understand why Obsidian went with storing some coefficients in respect to [speed] and another ones in respect to [time]. In JS I can easily write "1/1.5" and leave it at that. In JSON they would have to write "0.6666666666" and make sure they are rounding stuff, in order to not get tooltips writing something like "Warbow modal: increases your recovery time by 49.99999999%".

 

So, one of my original points still stands though. Unless I'm misunderstanding what you mean by "double-inversion", double-inversion is not what makes things bad, because when the double-inversion is applied[...]

I have added to the end of above post, why I don't like double inversion of maluses.

[Madscientist]

Some more things:

 

- Everything that is called "action speed" influences attack, recovery and reload duration.

- Everything with "time" is called "+/- recovery time" or "+/- reload time" and it influences only this value

 

Now comes the problem of stacking:

- There are talents that lets you cast faster. Do the talents "+X% action speed for spells" and "+X% action speed for spells of type Y" (summon creature, summon weapon, . . . ) stack?

I guess it effects attack and recovery of spells. I also guess "spell" means every active ability that can be learned by a class who also has a casting speed talent ( except soul annihilation of soul blades).

- I guess all penalties stack ( low dex, weapon modal, armor, debuffs )

- I guess all passive bonusses and only the strongest active bonus is applied. ( e.g. frenzy and speed potion do not stack )

Now comes the problem to tell which effect is active and which one is passive, e.g. I am not sure if ila sure handed and frenzy would stack.

Are there effects that stack with itself? ( like barbariens bloodlust )

[thelee]

OK, I found the thread from PoE1. (They should pin it there, it was hard to find )

https://forums.obsidian.net/topic/86684-mechanics-the-big-attack-speed-conundrum/

Its very complicated, but I guess the main point is that

- Only dex influenced attack duration, all things that say " attack speed " influence only recovery

- Most factors that influenced recovery speed were multiplicative, so stacking bonusses gave increasing returns

 

Back to PoE2:

@Thelee: What do you mean by "normalize"?

I looked into wikipedia and there are many possible meanings, I am not sure what you mean.

In my physics institute it usually means: We did several measurements and made plots from it, we give an importent feature in every plot the value 1 (all values in a plot are divided by the value of this feature), then we put all plots on top of each other and we can compare the shape of this feature between the different measurements.

 

By "normalize" I mean that everything should be changed, at least to the player, to use the same unit. Right now a lot of the confusion is that some things refer to "speed" and other things refer to "time" which require a lot of care and math for players to understand how they impact and influence your recovery. If obsidian changed it all to be, e.g. "speed" then we could just add things up in our head and be done with it.

 

P.S. Together: [first malus inversion] and [second malus inversion], form what we do refer on this forum as [double inversion of maluses]. And the problem I see with it is:

- it's hard to compute the final_speed_coefficient in mind. You pretty much always need a calculator.

- if you have any malus, the end value you get is unnatural.

 

And by unnatural I mean: it has no physical representation.

To show this I'll extend the previous example with the car. Imagine that you are driving with a base speed of 100kmph:

- If you are asked to increase the speed by 25% and after that decrease by 25% in respect to the base value, you will end up with 100 + 25 - 25 = 100kmph {100 * [1 + (1.25 - 1) + (0.75 - 1)]}

- If you are asked to increase the speed by 25% and after that decrease by 25% in respect to the current value, you will end up with 100 * 1.25 * 0.75 = 93.75kmph

 

The first variant is: additive stacking.

The second variant is: multiplicative stacking.

 

While under the current system we would get:

step_1 = 0.25

step_2 = -0.33333

step_sum = -0.08333

final_speed_coef = 0.92307

and thus: 92.307..kmph

...and what is this value?

 

Imho, if we do apply all the coefficients in respect to the base value (and that's how it's done in the majority of the games, to avoid dps skyrocketing due to glass-cannons stacking multiple bonuses), a [bonus] and a [malus] of the same type and value should effectively cancel each other.

 

 

I think what i'm tripping up here is the technicality that it's not the double-inversion here that matters. It's that you're combining two numbers with the magnitude (25) but they're doing different things, hence why we get a non-obvious result where two 25s combine and give us a -8%. What I was trying to make clear in my earlier post is that double-inversion makes perfect sense if you're talking about adjusting how quickly or slowly a character is advancing through their action frames, which is what dex and gunner did back in pillars1. It is surprising that they have this double-inversion, but then have this alternate way of computing coefficients as well, which leads to very confusing outcomes. Anyway I think we agree that the current system makes less sense than alternatives.

 

 

Although, I do partially understand why Obsidian went with storing some coefficients in respect to [speed] and another ones in respect to [time]. In JS I can easily write "1/1.5" and leave it at that. In JSON they would have to write "0.6666666666" and make sure they are rounding stuff, in order to not get tooltips writing something like "Warbow modal: increases your recovery time by 49.99999999%".

 

 

 

This is a good point. Another thing I thought of was that, as a game designer, you may just want an ability that does "X" and not have to figure out the math it takes to accomplish "X" in your system. I.E. if you want to design a buff that halves your recovery time, you probably just want to fill in an input box in some tool that says "-50% time" instead of having to think a bit and put in "+100% speed" instead.

 

I just wish that regardless of what is done behind the scenes or in the .json file, obsidian just gave us a standard, unified, normalized unit (your "speed coefficient" that you talk about in your tool).

 

Some more things:

 

- Everything that is called "action speed" influences attack, recovery and reload duration.

- Everything with "time" is called "+/- recovery time" or "+/- reload time" and it influences only this value

 

Now comes the problem of stacking:

- There are talents that lets you cast faster. Do the talents "+X% action speed for spells" and "+X% action speed for spells of type Y" (summon creature, summon weapon, . . . ) stack?

I guess it effects attack and recovery of spells. I also guess "spell" means every active ability that can be learned by a class who also has a casting speed talent ( except soul annihilation of soul blades).

- I guess all penalties stack ( low dex, weapon modal, armor, debuffs )

- I guess all passive bonusses and only the strongest active bonus is applied. ( e.g. frenzy and speed potion do not stack )

Now comes the problem to tell which effect is active and which one is passive, e.g. I am not sure if ila sure handed and frenzy would stack.

Are there effects that stack with itself? ( like barbariens bloodlust )

 

Stacking rules were complicated even in pillars, which had plenty of exceptions and bugs. Even with the rule in deadfire of "actives don't, passives do" (or is it the other way around? ARGH) I'm sure there's going to be lots of nonobvious, exceptional, and/or buggy cases. But I'm pretty sure effects won't stack with themselves.

Edited May 17, 2018 by thelee

[Boeroer]

The stacking rules used to be pretty consistent until they changed the stacking of phrases (Ancient Memory, Soft Winds). Now it's inconsistent like in PoE1 for balance's sake.

[Madscientist]

Thelee said:

"By "normalize" I mean that everything should be changed, at least to the player, to use the same unit. Right now a lot of the confusion is that some things refer to "speed" and other things refer to "time" which require a lot of care and math for players to understand how they impact and influence your recovery. If obsidian changed it all to be, e.g. "speed" then we could just add things up in our head and be done with it."

 

Well, the problem is that things that are called "action speed" influence all phases ( attack, casting, recovery, reload ) while things that that are called "time" only influence one of the phases ( usually recovery or reload ). In PoE1 they called everything "speed" but only dex influenced all phases, everything else worked only for recovery or reload. So the description was wrong. I assume the term "speed" implies that everything is speed up or slowed down. Because not all talents influence everything we have to "normalize" everything to time, because all effects change the duration of something. so we would get:

- Things that change time stay the same ( e.g. armor causes +X% recovery duration )

- Things that change speed are renamed from "+X% action speed" to "-X% duration of attack, casting, recovery and reload time)

Even if we normalize everything as "time" things would only be understandable if the system is completely additive, like the damage formula of PoE1. That means that +25% duration and -25%duration together results in base duration. If they use inversion we will still have the problem that the numbers will not make sense ( see damage were crit + blunted crit result in -8% damage )

 

Thelee said: "Anyway I think we agree that the current system makes less sense than alternatives."

 

OK, what alternatives do you think of?

[urosdot]

Did anyone see the dex tool tip... its shows way more + action speed like 10% more at list...? I dont get it, how was this passed on testing... its a core stat...

Edited May 17, 2018 by urosdot

[Madscientist]

OMG, the confusion between speed and time is even worse than I expected.

There are several bug reports were players believe that dex is not working as it should be.

https://forums.obsidian.net/topic/99072-attributes-dexterity-not-calculating-correctly/

 

Edit: short version of the problem:

- dex tooltip shows it increases recovery speed by 30%

- tooltip of an ability shows that the same dex value reduces recovery time by 23%.

- Both tooltips are correct but it takes some math to understand why.

 

So yes, I totally agree with Thelee that all numbers should be normalized in a way that all text in this game refers either to speed or duration, but not a mix of both.

Edited May 17, 2018 by Madscientist

[Sotnik]

OMG, the confusion between speed and time is even worse than I expected.

There are several bug reports were players believe that dex is not working as it should be.

https://forums.obsidian.net/topic/99072-attributes-dexterity-not-calculating-correctly/

 

Edit: short version of the problem:

- dex tooltip shows it increases recovery speed by 30%

- tooltip of an ability shows that the same dex value reduces recovery time by 23%.

- Both tooltips are correct but it takes some math to understand why.

 

So yes, I totally agree with Thelee that all numbers should be normalized in a way that all text in this game refers either to speed or duration, but not a mix of both.

And if you have both positive and negative speed modifiers, you will see the negative one higher than in the ability tooltip (I had -33 of the Arquebus modal instead of -25).

 

And now a question to the sages: is the recovery speed calculated upon the action or is it being recalculated all the time? If I shoot with an Arquebus and then use Swift Strikes, will I reload faster? If I attack and then get debuffed, will that affect the current recovery?

Edited May 19, 2018 by Sotnik

[thelee]

 

OMG, the confusion between speed and time is even worse than I expected.

There are several bug reports were players believe that dex is not working as it should be.

https://forums.obsidian.net/topic/99072-attributes-dexterity-not-calculating-correctly/

 

Edit: short version of the problem:

- dex tooltip shows it increases recovery speed by 30%

- tooltip of an ability shows that the same dex value reduces recovery time by 23%.

- Both tooltips are correct but it takes some math to understand why.

 

So yes, I totally agree with Thelee that all numbers should be normalized in a way that all text in this game refers either to speed or duration, but not a mix of both.

 

And if you have both positive and negative speed modifiers, you will see the negative one higher than in the ability tooltip (I had -33 of the Arquebus modal instead of -25).

I don't think this is true. This is why I am pushing the point to MaxQuest that in his OP his statement about double-inversion making maluses overpower bonuses is incorrect. In reality it is because some maluses are phrased in terms of "time" and some bonuses in terms of "speed." In the tooltip, the game is showing you the coefficient normalized for "time." So if arbalest has a -25% speed in the modal description, that actually translates into +33% recovery time penalty in the tooltip (note the distinction between "negative speed" and "positive time" here). It's the same thing mathematically. It has nothing to do with there being a mix of bonuses and maluses.

 

This ongoing confusion between speed and time (including my own until a few posts up) makes me think that this is a really huge systems blunder on Obsidian's part.

Edited May 19, 2018 by thelee

[thelee]

And now a question to the sages: is the recovery speed calculated upon the action or is it being recalculated all the time? If I shoot with an Arquebus and then use Swift Strikes, will I reload faster? If I attack and then get debuffed, will that affect the current recovery?

My assumption is that your recovery rate is computed continuously. This was the case in backer beta where I could have a character hit by Blind (-100% recovery penalty then) and they would take FOREVER to get their next action, instead of their current recovery finishing normally and *then* their next recovery being really slow.

[Sotnik]

 

 

OMG, the confusion between speed and time is even worse than I expected.

There are several bug reports were players believe that dex is not working as it should be.

https://forums.obsidian.net/topic/99072-attributes-dexterity-not-calculating-correctly/

 

Edit: short version of the problem:

- dex tooltip shows it increases recovery speed by 30%

- tooltip of an ability shows that the same dex value reduces recovery time by 23%.

- Both tooltips are correct but it takes some math to understand why.

 

So yes, I totally agree with Thelee that all numbers should be normalized in a way that all text in this game refers either to speed or duration, but not a mix of both.

And if you have both positive and negative speed modifiers, you will see the negative one higher than in the ability tooltip (I had -33 of the Arquebus modal instead of -25).

I don't think this is true. This is why I am pushing the point to MaxQuest that in his OP his statement about double-inversion making maluses overpower bonuses is incorrect. In reality it is because some maluses are phrased in terms of "time" and some bonuses in terms of "speed." In the tooltip, the game is showing you the coefficient normalized for "time." So if arbalest has a -25% speed in the modal description, that actually translates into +33% recovery time penalty in the tooltip (note the distinction between "negative speed" and "positive time" here). It's the same thing mathematically. It has nothing to do with there being a mix of bonuses and maluses.

 

This ongoing confusion between speed and time (including my own until a few posts up) makes me think that this is a really huge systems blunder on Obsidian's part.

 

Oh, seems like I have started to understand only now. It is hilarious: all the problems could be solved by replacing "action speed" with "action duration". This one of the most unintuitive mechanics and there is no tooltip for Speed at all .

 

Now another problem:

My char sheet tells me my reload speed is 1.7 seconds, however the actual reload speed does not drop below 3.1 seconds. Looks like there is an animation speed limitation or something else preventing me from reloading quicker.

Edited May 19, 2018 by Sotnik

[Edolamberto]

 

 

 

OMG, the confusion between speed and time is even worse than I expected.

There are several bug reports were players believe that dex is not working as it should be.

https://forums.obsidian.net/topic/99072-attributes-dexterity-not-calculating-correctly/

 

Edit: short version of the problem:

- dex tooltip shows it increases recovery speed by 30%

- tooltip of an ability shows that the same dex value reduces recovery time by 23%.

- Both tooltips are correct but it takes some math to understand why.

 

So yes, I totally agree with Thelee that all numbers should be normalized in a way that all text in this game refers either to speed or duration, but not a mix of both.

And if you have both positive and negative speed modifiers, you will see the negative one higher than in the ability tooltip (I had -33 of the Arquebus modal instead of -25).

I don't think this is true. This is why I am pushing the point to MaxQuest that in his OP his statement about double-inversion making maluses overpower bonuses is incorrect. In reality it is because some maluses are phrased in terms of "time" and some bonuses in terms of "speed." In the tooltip, the game is showing you the coefficient normalized for "time." So if arbalest has a -25% speed in the modal description, that actually translates into +33% recovery time penalty in the tooltip (note the distinction between "negative speed" and "positive time" here). It's the same thing mathematically. It has nothing to do with there being a mix of bonuses and maluses.

 

This ongoing confusion between speed and time (including my own until a few posts up) makes me think that this is a really huge systems blunder on Obsidian's part.

Oh, seems like I have started to understand only now. It is hilarious: all the problems could be solved by replacing "action speed" with "action duration". This one of the most unintuitive mechanics and there is no tooltip for Speed at all .

 

Now another problem:

My char sheet tells me my reload speed is 1.7 seconds, however the actual reload speed does not drop below 3.1 seconds. Looks like there is an animation speed limitation or something else preventing me from reloading quicker.

it's a known bug unfortunately.. It happens with reload weapons only Edited May 23, 2018 by Edolamberto

[MaxQuest]

Now another problem:

My char sheet tells me my reload speed is 1.7 seconds, however the actual reload speed does not drop below 3.1 seconds. Looks like there is an animation speed limitation or something else preventing me from reloading quicker.

That's strange.

 

Just frapsed my attack + reload time with a Scordeo pistol, and counted the frames:

- got 24f (0.8s) for attack time, and

- 83f (2.766s) for reload time

 

While the tooltip was displaying 0.8s attack time and 1.0s reload time: image

 

 

As I understood, reloading animation (unlike recovery animation) is consisting of animation chunks that are played several times in a cycle, plus an additional animation of jitter at the end.

In case of pistols visually it looks like the character is taking bullets from his pocket and putting them into pistol's gunpoint; repeated n times. Each such chunk takes 57 frames (1.9s). And it looks like there can't be less than 1...

Edited May 23, 2018 by MaxQuest

[BlessedHeretic]

 

Now another problem:

My char sheet tells me my reload speed is 1.7 seconds, however the actual reload speed does not drop below 3.1 seconds. Looks like there is an animation speed limitation or something else preventing me from reloading quicker.

That's strange.

 

Just frapsed my attack + reload time with a Scordeo pistol, and counted the frames:

- got 24f (0.8s) for attack time, and

- 83f (2.766s) for reload time

 

While the tooltip was displaying 0.8s attack time and 1.0s reload time: image

 

 

As I understood, reloading animation (unlike recovery animation) is consisting of animation chunks that are played several times in a cycle, plus an additional animation of jitter at the end.

In case of pistols visually it looks like the character is taking bullets from his pocket and putting them into pistol's gunpoint; repeated n times. Each such chunk takes 57 frames (1.9s). And it looks like there can't be less than 1...

 

 

If this is true, the best fix would be to have a way to cut cycles early if the reload demands it and go straight into a shooting animation, might look a bit jank but at least builds would work.

 

However this still wouldn't make much sense, because if the whole animation takes 1.9s, we should have a 1.9s cap instead of 3.6s wouldn't we? Assuming of course you got your reload down to 1.9 and below anyway.

 

Here is hoping the Drunk DLC will have a fix for this as it's pretty pirate themed and dual wielding pistol is one of the most piratey things you can do.

[Boeroer]

Boo. They should speed up the animation then. Even if it looks kind of ridiculous.

[the streaker]

Ah this crap again? PoE 1 was such a pain in the ass to figure out attack speeds and modifiers, and a bunch of bugs to go along with it. The devs never even chimed in to clear up how things actually work. They haven't changed anything in PoE 2. Why not make a simple intuitive system and make it transparent so that people can get on with making character builds instead of counting frames and making spreadsheets? Sigh.

[Boeroer]

Don't say that! Sure they changed something: they made it worse...

[thelee]

Ah this crap again? PoE 1 was such a pain in the ass to figure out attack speeds and modifiers, and a bunch of bugs to go along with it. The devs never even chimed in to clear up how things actually work. They haven't changed anything in PoE 2. Why not make a simple intuitive system and make it transparent so that people can get on with making character builds instead of counting frames and making spreadsheets? Sigh.

 

PoE1 wouldn't have been so bad if they just had come up with a single, standard way to stack modifiers. Instead you have to keep track of which modifiers are in which group. It got pretty close though, because for the most part most modifiers in PoE1 were additive.

 

But then instead of getting simpler Deadfire is introducing this whole "time vs speed" nonsense.

 

I'm no game designer, but I truly don't understand why rules simplicity ends up getting sacrificed.

Edited May 29, 2018 by thelee

[Phenomenum]

Sorry if this question was already mentioned (i didn't find) but What the difference between Attack Speed and Action Speed? As i understand, Action Speed affects all attack phases (swing (shot, spell preparation), reload, recovery) and Attack Speed affects only first attack phase but not Reload and Recovery... Am i right?

[thelee]

Sorry if this question was already mentioned (i didn't find) but What the difference between Attack Speed and Action Speed? As i understand, Action Speed affects all attack phases (swing (shot, spell preparation), reload, recovery) and Attack Speed affects only first attack phase but not Reload and Recovery... Am i right?

 

What ability affects just attack speed? Most everything I can think of off the top of my head affects action speed.

[kmbogd]

@Phenomenum

 

You are right. That being said, I can't think off the top of my had of any feature that affects only the attack speed. Thus, you need something that affects the overall action speed of the character in order to see an impact on the attack speed.

[Phenomenum]

@Phenomenum

 

You are right. That being said, I can't think off the top of my had of any feature that affects only the attack speed. Thus, you need something that affects the overall action speed of the character in order to see an impact on the attack speed.

 

Some drink or Weapon modal ability - i don't remember exactly. Thank you for resolving my concerns)

Edited June 24, 2018 by Phenomenum

[MaxQuest]

Sorry if this question was already mentioned (i didn't find) but What the difference between Attack Speed and Action Speed? As i understand, Action Speed affects all attack phases (swing (shot, spell preparation), reload, recovery) and Attack Speed affects only first attack phase but not Reload and Recovery... Am i right?

Yeap) Just as kmbogd already mentioned.

And it can be visualised like this:

 

 

The effects whose tooltips mention +/-% Action Speed do affect all phases.

And if there was some effect that would affect only Attack phase, it's tooltip would likely write +/-% Attack Speed.

 

 

Have to note though that under the hood notations may be a little different compared to the tooltips.

For example [Food_captains_banquet_SE_ActionSpeed] effect has the StatusEffectType set to AttackSpeedMultiplier.

And internally AttackSpeedMultiplier affects attack animation duration and recovery/reload time.

 

What ability affects just attack speed?

None that I'm aware of)

 

---

P.S. Have tested Cutthroat Cosmo pet. It's effect is the same as Armored Grace, and they do stack additively.

Updated the calculator. The top post. And added weapon base values list.

[thelee]

 

P.S. Have tested Cutthroat Cosmo pet. It's effect is the same as Armored Grace, and they do stack additively.

Updated the calculator. The top post. And added weapon base values list.

 

 

Does this mean that light armor goes from a .83 coefficient to a 1.03 with both armored grace and cutthroat cosmo???

[MaxQuest]

Does this mean that light armor goes from a .83 coefficient to a 1.03 with both armored grace and cutthroat cosmo???

It gets capped at 1.00)

 

Armor penalty reduction effects can only reduce the penalty up to 0.

Edited June 25, 2018 by MaxQuest