spencer-melnick
commented
4 years ago Try making hit slowdown into an event triggered ability, use a custom ability task to apply the slowdown curve.
Hopefully this will help allow hit events to be predicted, and can be used to easily reset the playback rate if they are reverted by the server
Fix the CanActivateAbility code so that it doesn't actually add the tags that will be triggered, but just overwrite the required tag check code
Fix the attack code so that locally predicted animation slowdowns don't cause desync between the client and server, resulting in weird animation hitches.
There are a couple of approaches to this, the simplest seemingly being preventing the server from overwriting the client's montage position unless the server montage is completely different from the client montage, or the server stops the montage and the client doesn't. I've tried setting montage position replication to only replicate the section, allowing for a coarse grain control and leaving specific position timings up to the client. Theoretically the tag extension windows would allow for some discrepancy between the server and client, but the server still appears to be "clobbering" the client montage position whenever a hit slowdown occurs.
This isn't a critical feature - I'd really like hit slowdown (and the system could be useful when it comes to predicting hit stun animations or effects), but it can be replaced with additive animations or bigger hit effects.
See https://github.com/spencer-melnick/Threshold/issues/6 for a bit more background.