Synchronize damage feature potential issue with attack motion being lower than 432
Closed this issue · 3 comments
rAthena Hash
Client Date
2023-03-30
Server Mode
Renewal
Result
Well I may be wrong here, but I believe it would make more sense to change the sdelay value in battle_delay_damage instead. The value sent in clif_damage is the value that was retrieved from official packet parsing, so it is "always" accurate.
Relevant Log Output
No response
Expected Result
If you take the Picky mob (1049) for example, it has:
- AttackMotion: 288
- ClientAttackMotion: 240
Prior to this change, the damage would trigger at
- client_tick = (min(AttackMotion, 432) / 432) * ClientAttackMotion
- client_tick = (min(288, 432) / 432) * 240
- client_tick = 160 ms
Now with the change being applied in clif_damage, the sdelay becomes:
sdelay = min(288 * 432 / 240, 432) = 432 and this is what will be sent to the client.
The client will then display the damage at (min(432, 432) / 432) * 240 = 240 ms, which is incorrect as it should have been 160 ms. It will sync properly, but it's not when the damage on official would have had actually happened.
So something along the lines of:
if (battle_config.synchronize_damage && skill_id == 0 && src->type == BL_MOB) {
amotion = std::min(amotion * status_get_clientamotion(src) / DEFAULT_ANIMATION_SPEED, DEFAULT_ANIMATION_SPEED);
}
in battle_delay_damage. Well, unless I'm missing something; these tiny numbers are annoying to test.
How to Reproduce
Official Information
Modifications that may affect results
No response
Please keep in mind that this is a custom feature which is disabled by default, so it definitely doesn't simulate official behavior.
Officially for Picky you see the damage after 160ms, but it is applied after 288ms.
With the setting on, you see the damage after 240ms and it is applied after 240ms.
Ideally I would want it to be 288ms for both since I assume that was the original intention of the developer, but since I can't slow the animation down below 1x speed, 240ms is the slowest it can get without modifying the client.
That the client shows the damage earlier than coded into the client's act files for monsters with AttackMotion lower than 432 I would consider an official bug, because the developers clearly thought they should be sending AttackMotion in this field (and they do so officially), but the client instead interprets it as an animation speed modifier.
tl;dr - The goal is to show and apply the damage as close to AttackMotion as possible.
Ah, that makes sense then. I was more focussed on replicating the client behavior instead of the intended behavior. It's hard to know which one is correct or not in that case. Anyway, closing this then, thank you for clarifying!
Ah, that makes sense then. I was more focussed on replicating the client behavior instead of the intended behavior. It's hard to know which one is correct or not in that case. Anyway, closing this then, thank you for clarifying!
Ideally you'd need to go through the individual monsters and see which animation looks correct. For Grand Peco for example, the animation is actually broken if you send >=432 to the client, but looks very clean if you send 180.
But for most monsters the animation looks best if you send 432 to the client because that's how the act file was written.