Attack speed is changed from % to hit(s)/s. This change is going to help us clear out the Atlas Pauldron confusion where we thought it took out 65% attack speed from your % attack speed not the 65% on the overall % attack speed. Ex: 100%=1hit/s.
I feel attackspeed is fine the way it is.
Attack animations are not unified. That is more of a problem but your “fix” would change nothing about that…
He’s got a valid point there, actually. And it could also help with the different lengths of attack animations, if buying an attack speed item displayed how many attacks per second you have now, and how many you will have afterwards.
Currently, it is all but impossible to figure out how much good an attack speed item will do. Doubling your base attack speed ought to double your damage output - but how much attack speed increase in % do you need for that? 100%?
And if you want to double it again? Because that’d be 300% then, and it’s starting to get complicated to figure out where diminishing returns set in, even without an invisible cap on attack speed that different heroes reach at different percentages of attack speed increase. (And that’s an assumption, because there’s absolutely no way for me to figure it out via in-game means.)
With a cap of 2 attacks / second, you can simply display 2 a/s (now) -> 2 a/s (item bought). You will know it’s useless.
And yes, it is currently perfectly opaque how Atlas Pauldron relates to all that.
TL;DR: Good idea, in my eyes.
Hey, it’s just a normal idea of turning % attack speed to hit/s. By the way LOL does this and it helps clear out the confusion
Moderator note: I’ve edited a couple posts here to remove personal attacks and to keep things on-topic.
As for the idea, I’m not understanding why this is a necessary fix… Could you explain this more to me? Why is Atlas Pauldron unclear? And what’s the difference between “your % attack speed” and the “overall % attack speed”?
Say an enemy Saw has +40% attack speed. Atlas Pauldron “reduces Attack Speed by 50%”.
That can mean either:
(Base Attack Speed + 40%) - 50% = 90%
(Base Attack Speed + 40%) ÷ 2 = 70%
One simply can’t tell from the item description. Another fix would be to change that to “reduces attack speed by half”. That’s clear, but then you cannot easily change the value.
Again, it’s just a matter of clarity. If an item displays by how many attacks per second your current attack speed will be increased upon purchase (or even the overall value, say: Tornado Trigger, 0.8 a/s -> 1.0 a/s [2 a/s max] ) then you know exactly what the item does. It increases your damage output by 20%.
With the current system, if you have purchased Poisoned Shiv and Breaking point already, by how much is your damage output increased through added attack speed, if you also get Bonesaw? Because it isn’t whatever percentage is displayed, and requires you to solve an equation mid-game.
Is probably reffering to character base stats
Is a reference to base stats plus equipment stats
Changing to hit/s would be a nice implication for those who are new to the game and haven’t gained the knowledge that comes from the game. It would also make devoloping attack animations easier on the devs and designers. On the downside this fix could also end up eliminating stutterstep which many have spent a long time learning. All in all this change would simplyfi the game requiring less skill and expirience to become better; which is an obvious double edge sword
Ah, ok ok. I’m starting to understand it now, thank you!
I glossed over this the first time, but I catch what you meant now… and I agree, that would be a really intuitive and useful representation to have while shopping for items. It’s actually something I’ve always wanted in-game, regardless of whether or not SEMC converted to a “hits per second” metric. Some graphical representation (rather than just numbers) of how an item effects your stats would be great.
This is a good point. You’d either have to get rid of stutterstepping as a mechanic, or acknowledge that the “hits per second” is malleable by non-item means. You could do that graphically too, but it might require more even complexity and explanation than sticking with the current system.
I don’t really see stutterstepping as a factor in this. It is not represented by the current system in any way, and even if SEMC were to switch the displayed values to “attacks per second”, they could simply omit it as well.
The “X attacks per second” in the tooltips would refer to the completed animation.
Stutterstepping is not a fixed value either way, and can not really be accounted for. (As in: Different people will see different results due to their respective mechanics.)
It is a major factor, by changing the values allows the devs to see animation values and attack speed allowing them to tweak the animations to sync to the attack speed. By doing that would eliminate stutterstepping by making devs jobs easier to sync which would end up being the next thing asked for from the proposed fix.
That’s what I mean, actually. I don’t think stutterstepping needs to change with a new metric, just that if you simplify the metric so that people better understand attack speed, you’ll start to highlight discrepancies more (i.e., people noticing when attack speed isn’t behaving the way you expect it to “that’s not 2 hits per second, it’s 3! What gives?”). The graphic system will need to explain that discrepancy, which is possible, but maybe complicated. Perhaps it’s a tutorial on stutterstepping (which isn’t officially acknowledged in-game), or some other notation system.
Sorry, that’s a misunderstanding. I was not proposing a change of the values themselves, but rather how the same values are presented to the players.
The Devs already have access to this information, as they can see the underlying functions in the code.
Edit: I think my favourite draconic entity 'round here explained it better than I did.
Yes they do and don’t true value in display require true value in the code. Percentage can be done by commiting a value of 1hit/s to 100% in the code utimately requiring math to be done by the devs if said dev wanted the truevalue. By keeping it as percents in the code makes more work to adjust the animation values either a guess and check or actually doing caculations taking up more time they could do other things.