noahlykins
New member
YO I just learned something
All damage and health is calculated using floating point numbers, so there is decimal precision under the hood.
BUT there is something interesting about resistance:
Resistance is actually truncating the decimal in its calculation.
So for example: If Seven buys 4 spirit, his ball goes from 150dps -> 152dps (assuming 5 points in it)
BUT the issue is that is completely not true IF they have any resistance
, because the resistance calculation truncates the decimal and makes it wrong.
Its minor but it makes the 152dps work exactly like 150dps ONLY AGAINST 35% resistance because the 9.75dmg per tick will round down to 9, like for example a jungle camp. Note that is still the expected 152dps against someone without resistance.
The fix is simple: to not truncate damage after the resist calculation to an int but keep it a floating point. Likely in the code just turning a // to a /
Here is the python code I used to recreate the issue
*ps, another bug is Sevens ball only registers 49 ticks instead of the expected 50 because it ends too early
This isnt the biggest deal in the world in most cases: but this is barely making resistance too strong against Damage Over Time characters, where they can lose 5-10% damage over a rounding error
Easy Bug with Easy fix, thank you!
All damage and health is calculated using floating point numbers, so there is decimal precision under the hood.
BUT there is something interesting about resistance:
Resistance is actually truncating the decimal in its calculation.
So for example: If Seven buys 4 spirit, his ball goes from 150dps -> 152dps (assuming 5 points in it)
BUT the issue is that is completely not true IF they have any resistance
, because the resistance calculation truncates the decimal and makes it wrong.Its minor but it makes the 152dps work exactly like 150dps ONLY AGAINST 35% resistance because the 9.75dmg per tick will round down to 9, like for example a jungle camp. Note that is still the expected 152dps against someone without resistance.
The fix is simple: to not truncate damage after the resist calculation to an int but keep it a floating point. Likely in the code just turning a // to a /
Here is the python code I used to recreate the issue
Code:
# This calculation recreates the dmg of sevens using ability 1 on a tier2 camp, to prove im right
# I was in the sandbox with no items testing on the First Dummy (0 resist) vs the Tier3 Camp (0.35 resist)
dps = 150 # Sevens dps for ability 1 with 5 points in it
tps = 10 # Sevens 1 ability ticks per second
ticks = 49 # Sevens ticks over 5 seconds, BUT the last one doesn't register it ends too early
resist = 0.35 # Tier3 Camp resist
tick_dmg = (dps/tps)
print(f"{tick_dmg=}")
expected_tick_dmg = (dps/tps) / (1/(1-resist))
print(f"{expected_tick_dmg=} (added {resist} resistance)")
actual_tick_dmg = (dps/tps) // (1/(1-resist))
print(f"{actual_tick_dmg=} (added {resist} resistance)")
total_dmg = actual_tick_dmg * ticks
print(f"{total_dmg=}")*ps, another bug is Sevens ball only registers 49 ticks instead of the expected 50 because it ends too early
This isnt the biggest deal in the world in most cases: but this is barely making resistance too strong against Damage Over Time characters, where they can lose 5-10% damage over a rounding error
Easy Bug with Easy fix, thank you!
Last edited:
