Jump to content

Welcome to Obsidian Forum Community
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. If you already have an account, login here - otherwise create an account for free today!
Photo

[MECHANICS] Attack Speed, Recovery Time, Reload Time

mechanics attack speed attack time recovery duration recovery time reload time

  • Please log in to reply
91 replies to this topic

#41
thelee

thelee

    (8) Warlock

  • Members
  • 1108 posts
  • Pillars of Eternity Silver Backer
  • Kickstarter Backer
  • Deadfire Silver Backer
  • Fig Backer

Thanks, MaxQuest. And holy large json file, Batman! TIL that vim will struggle to open a 14mb file with no line wrapping.

 

Frankly the information you provide is disappointing, mostly because it talks about a murkiness in the game when I thought Obsidian was trying to clear all that up from pillars.

 

Second, Obsidian takes all coefficient values in respect to the base value. And they do use 0.75 value for coefficients when they want to denote -25% speed. And tbh, I am not convinced yet that they should store 0.8 instead.

 

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. For all below cases I assume a 5s recovery:

 

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.

 

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. The way you do this is 5/(1/(1-x)). We take the negative bonus (-1) and we reverse the sign so we get 1/2. Then we invert that, so that instead of increasing how quickly we are going through attack frames, we are decreasing our speed through attack frames (hence, a double-inversion of a malus). So 5/(1(1-(-1))) = 10s, or half as many action in the same time frame. So I was predisposed to thinking of maluses in terms of this thinking, where a malus means degradation in your action/recovery time (instead of action/recovery speed).

 

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).

 

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).

 

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 to something that lengthens your recovery time (warbow overdraw), it is basically a negative additive modifier to most positive modifiers which affect speed. What makes things bad are maluses that are targeting your action speed directly (like arbalest overbearing) because by their very nature they overpower identical magnitude improvements also to your action speed. Interestingly, there's a flip side here: Sure-Handed Ila stores a 1/.8 coefficient, instead of a 1.2, because I guess it is targeting giving you 20% less recovery time (effectively a 25% improvement in your action speed), instead of improving your action speed by 20% (like potions of deftness do by 15% for coeff of 1.15), so Sure Handed, too, will overweight against maluses that merely degrade your recovery speed (like warbow overdraw or armor). Something similar happens with dual-wield (given that its coefficient is stored as 1/.7 and not 1.3). (So, dual-wielding an implement with Sure-Handed will outweigh the penalty for wearing heavy armor, even though the tool-tip penalty for heavy armor exceeds a naive* sum of the tooltip bonuses for dual-wielding and sure-handed).

 

* I use naive not to be insulting, but more in the math-y way of saying "possibly the obvious, but apparently incorrect" approach.

 

Personally, I think we should try to spit out a list of coefficients and normalize them, or at least be explicitly clear into how they are put into the equation, because there are clearly some maluses are no different from bonuses (warbow, rapier needle, armor) and some that are significantly overweighted (arbalest overbearing but there are also bonuses that are overweighted: sure handed, dual-wielding).

 

EDIT: i am also pretty busy the next couple of weeks, but I might take a stab at doing this when I have more time. Coefficients are just way too murky for my game-analytical needs as it stands.

EDIT2: i tried to clear up terminology. It's a little confusing because it's a bit asymmetric. 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


Edited by thelee, 15 May 2018 - 11:24 AM.

  • grausch likes this

#42
thelee

thelee

    (8) Warlock

  • Members
  • 1108 posts
  • Pillars of Eternity Silver Backer
  • Kickstarter Backer
  • Deadfire Silver Backer
  • Fig Backer

 

Boy that's confusing. IIRC, Swift Strikes is a increase of +20% action speed, right? But in that recovery speed tooltip it's listed as a -17% bonus. I mean, what the heck.

Swift Strikes grants +20% action [speed].
But when you mouseover the recovery time of weapon, the game tries to display how much did Swift Strike affect the [time].
It converts speed coefficient to time coefficient: 1/1.2 = 0.8333. So a +20% increase in speed, corresponds to a -16.(6)% decrease in time.

 

 

That makes sense for swift strikes, but I'm not crazy in thinking that that's not how dexterity is calculated, right? It should just be (1 + .03 * dex) as the coefficient? Which means the tool-tip is inconsistent in showing the effects on recovery rate and recovery time. (Wouldn't be the first time a pillars tooltip has been misleading)

 

EDIT: the dexterity in that tooltip is at level where a coefficient of (1+x) = 1.06 versus 1/(1-x)=1.06 round to the same thing, so there's nothing inconsistent about the tooltip, potentially.


Edited by thelee, 15 May 2018 - 10:14 AM.


#43
West

West

    (1) Prestidigitator

  • Members
  • 16 posts

Once we (you) get to this bottom of this, I think a thread in plain English explaining the ramifications of these discoveries would be greatly appreciated by those of us with low INT. 


  • MaxQuest likes this

#44
Madscientist

Madscientist

    (10) Necromancer

  • Members
  • 1438 posts
  • Deadfire Silver Backer
  • Fig Backer
  • Black Isle Bastard!

Once again thank you MaxQuest

 

The table you have posted can be very confusing.

Sometimes the effect refers to a time and sometimes it refers to a speed.

This means sometimes small numbers are good and big numbers are bad and sometimes its the other way round.

Before this post I thought I understand the basic formula in the first post.

Now I am confused which numbers to use as step when calculating the step sum.

 

And if I am confused by those calculations most other players will understand nothing at all.



#45
M4xw0lf

M4xw0lf

    (5) Thaumaturgist

  • Members
  • 486 posts
  • Pillars of Eternity Backer
  • Kickstarter Backer
  • Deadfire Backer
  • Fig Backer

So, I'm now easily reaching 2.6 or 2.4s recovery with WoteP, and I have not even found the Falcon helmet. Pale hide armor bonus at night + Frenzy + stacking bonus of WoteP.



#46
Sotnik

Sotnik

    (3) Conjurer

  • Members
  • 137 posts
  • Steam:76561198056541314

Thank you all. I am still confused by the fact that the same modifiers are sometimes left unchanged in the tooltip (30 from dual-wielding, Dex is inconsistent in this respect), but at least now I can calmly perceive all the speed issues as derivatives of the wise game rules.

 

Jokes aside (my gratitude was not a joke though), such mechanics are quite an important thing, aren't they? I wonder why they are not mentioned in the in-game Cyclopedia.



#47
thelee

thelee

    (8) Warlock

  • Members
  • 1108 posts
  • Pillars of Eternity Silver Backer
  • Kickstarter Backer
  • Deadfire Silver Backer
  • Fig Backer

And if I am confused by those calculations most other players will understand nothing at all.

 

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.


Edited by thelee, 15 May 2018 - 01:45 PM.


#48
Yosharian

Yosharian

    (8) Warlock

  • Members
  • 1181 posts
  • Pillars of Eternity Backer
  • Kickstarter Backer
  • Deadfire Backer
LOUD NOISES

#49
Madscientist

Madscientist

    (10) Necromancer

  • Members
  • 1438 posts
  • Deadfire Silver Backer
  • Fig Backer
  • Black Isle Bastard!

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

https://forums.obsid...peed-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.


Edited by Madscientist, 16 May 2018 - 12:56 AM.


#50
MaxQuest

MaxQuest

    Arch-Mage

  • Members
  • 2180 posts
  • Deadfire Backer
  • Fig Backer

Once again thank you MaxQuest
 
The table you have posted can be very confusing.
Sometimes the effect refers to a time and sometimes it refers to a speed.
This means sometimes small numbers are good and big numbers are bad and sometimes its the other way round.
Before this post I thought I understand the basic formula in the first post.
Now I am confused which numbers to use as step when calculating the step sum.

I feel you.

I have added the step_n values to that table:
Spoiler


And here is an example of how to calculate those values:

gAaBhgD.png

Also, let's say Obsidian wants to add some speed/time altering status effect to the game.
In this case they add a new effect, and set:
- [StatusEffectType] - which denotes: 1. if the value is applied to [speed] or [time]; 2. the corresponding phase (attack, recovery, reload; or action if for all combined)
- [baseValue] - which denotes the magnitude of the effect.
And this data is stored in game files.

 
Later on, when your character is performing an action, the game processes all these active effects.
And initializes so called [multipliers]. I usually refer to them as coefficients or simply [coef_n], because I find the term multiplier confusing since they do not stack multiplicatively.

> The value of [coef_n] equals to [baseValue] if the effect affects [speed].
> Or it equals to [1 / baseValue] if the effect affects [time].
I call this time->speed coefficient conversion.
Thelee refers to this as normalization.
While the game uses a boolean property called [inverted] for this. If it's true, it inverts the value.

We can express this as:
coef_n = type == 'speed' ? base_value : 1 / base_value
Now, for each [coef_n] the game computes a corresponding [step_n]. (note: step is also a term taken from game files)
step_n = coef_n >= 1 ? coef_n - 1 : 1 - 1 / coef_n
For bonuses, i.e. values higher than 1, it's pretty straightforward.
While maluses get inverted. I call this: [first malus inversion].

Furthermore all [step_n] are added together, and form [step_sum].
And this [step_sum] is used to calculate the final coefficient:
final_speed_coefficient = steps_sum >= 0 ? steps_sum + 1 : 1 / (1 - steps_sum)
If step_sum is positive, it's again, pretty straightforward.
While if it's negative, it's value gets inverted with a twist. I call this: [second malus inversion].

Having this coefficient, we can now calculate the actual duration of the related phase (recovery, reload, etc):
phase_duration = base_phase_duration / final_speed_coefficient
The higher the speed, the lower is the interval between attacks.

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.

Edited by MaxQuest, 16 May 2018 - 09:11 AM.

  • AndreaColombo, grausch, Madscientist and 2 others like this

#51
MaxQuest

MaxQuest

    Arch-Mage

  • Members
  • 2180 posts
  • Deadfire Backer
  • Fig Backer

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:
Spoiler

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:
Spoiler


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.
  • AndreaColombo, grausch, Madscientist and 1 other like this

#52
Madscientist

Madscientist

    (10) Necromancer

  • Members
  • 1438 posts
  • Deadfire Silver Backer
  • Fig Backer
  • Black Isle Bastard!

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 )



#53
thelee

thelee

    (8) Warlock

  • Members
  • 1108 posts
  • Pillars of Eternity Silver Backer
  • Kickstarter Backer
  • Deadfire Silver Backer
  • Fig Backer

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

https://forums.obsid...peed-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 by thelee, 16 May 2018 - 05:59 PM.


#54
Boeroer

Boeroer

    Arch-Mage

  • Members
  • 13934 posts
  • Location:Bucharest, Romania
  • Lords of the Eastern Reach Backer
  • Deadfire Backer
  • Fig Backer
  • Black Isle Bastard!
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.

#55
Madscientist

Madscientist

    (10) Necromancer

  • Members
  • 1438 posts
  • Deadfire Silver Backer
  • Fig Backer
  • Black Isle Bastard!

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?



#56
urosdot

urosdot

    (1) Prestidigitator

  • Members
  • 15 posts

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 by urosdot, 17 May 2018 - 12:21 AM.


#57
Madscientist

Madscientist

    (10) Necromancer

  • Members
  • 1438 posts
  • Deadfire Silver Backer
  • Fig Backer
  • Black Isle Bastard!

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.obsid...ting-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 by Madscientist, 17 May 2018 - 03:59 AM.

  • thelee likes this

#58
Sotnik

Sotnik

    (3) Conjurer

  • Members
  • 137 posts
  • Steam:76561198056541314

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.obsid...ting-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 by Sotnik, 18 May 2018 - 04:08 PM.


#59
thelee

thelee

    (8) Warlock

  • Members
  • 1108 posts
  • Pillars of Eternity Silver Backer
  • Kickstarter Backer
  • Deadfire Silver Backer
  • Fig Backer

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.obsid...ting-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 by thelee, 18 May 2018 - 04:57 PM.

  • Sotnik likes this

#60
thelee

thelee

    (8) Warlock

  • Members
  • 1108 posts
  • Pillars of Eternity Silver Backer
  • Kickstarter Backer
  • Deadfire Silver Backer
  • Fig Backer

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 likes this





Also tagged with one or more of these keywords: mechanics, attack speed, attack time, recovery duration, recovery time, reload time

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users