Delay between attacks is much less than 1.8
skbeh opened this issue ยท 5 comments
Information
- Server Version: Dionysus@5548e473708c8ed447446d9107db1e0000e31673
- OldCombatMechanics version: 1.11.0
- Server Log File:
will be filled later :(
- OldCombatMechanics config file: Same as default
Problem Description
To Reproduce
Steps to reproduce the behavior:
- Use an auto clicker to change CPS to about more than 20.
- Attack a player using sword with jump and move to make the hit critical.
Expected Behaviour
The damage rate and knockback is same as normal CPS (about 8).
Actual Behaviour
The player is knockbacked much more and the damage rate is much faster.
When using the latest dev build (3880ef0) of BukkitOldCombatMechanics, there is almost no delay between hits.
Ignore the knockback for now, that would be a completely different issue. I need a debug log to know what is going on. Unfortunately "feel" doesn't help with coding, at least according to the extensive testing I have performed, the damage calculations are working fine.
I am still having this issue on my server. The CPS limits defined in attack-frequency in config.yml are not respected. It appears that the invulnerability animation is fixed, as is the knockback, but the damage accumulation from jitter clicking or auto clicking over the CPS limit goes through anyway. How do I get the log that you need?
@NotAlexNoyle The attack-frequency
does not set hard limits, because you can still be overdamaged by an attack of a higher value than the previous one while immune. You need to enable debug
mode at the bottom of the config and get the log in the chat from the attacker and defender's perspectives - which shows exactly how they were damaged and why.
@skbeh I have done some extra testing, including automated testing with multiple attacks within a very short timeframe. I see nothing to indicate the attack damage is not working as intended. If you do not think that is the case, please provide some logs and perhaps a video so I can help.
@kernitus Please reopen this. See #665 (comment).