spencer-melnick
commented
3 years ago Wow! This is just a confusing as it was the first time around!
I've found out you can adjust the montage replication threshold (the maximum time difference before the server replicated montage position will squash the client's montage position) via the console variable replay.MontageErrorThreshold, but that doesn't seem to be enough to fix everything.
I've been looking at 3 approaches for overall hit slowdown detection:
1) If I just do the hit slowdown on the server, other clients should see the effect correctly, but the player controlling the character won't see the effect until one RTT later, possibly once the animation has already finished.
2) If I let the player trigger the slowdown from their client (which could open up issues for cheating, but that should be a minor issue in my game), then the slowdown effect won't trigger on the server or other clients until at least a one way delay later, which has the end result of the clients also potentially not applying the effect until the animation is over or nearly over.
3) Have both the client and the server trigger the hit slowdown effect, and have the server roll back if the client mispredicts the effect. (Hopefully the effect is minor/cosmetic enough that a misprediction doesn't cause too much of a hitch for the player, but that's something I need to test later) According to comments in GameplayPrediction.h, it seems like it should be possible to do something like approach 3
*** Triggered Data Prediction ***
*
* Triggered Data is currently used to activate abilities. Essentially this all goes through the same code path as ActivateAbility. Rather than the ability being activated from input press, it is activated from
* another game code driven event. Clients are able to predictively execute these events which predictively activate abilities.
*
* There are some nuances to however, since the server will also run the code that triggers events. The server won't just wait to hear from the client. The server will keep a list of triggered abilities that have been
* activated from a predictive ability. When receiving a TryActivate from a triggered ability, the server will look to see if /he/ has already run this ability, and respond with that information.However:
* Triggered events do not explicitly replicate. E.g., if a triggered event only runs on the server, the client will never hear about it. This also prevents us from doing cross player/AI etc events. Support
* for this should eventually be added and it should follow the same pattern that GameplayEffect and GameplayCues follow (predict triggered event with a prediction key, ignore the RPC event if it has a prediction key).```
Improve networked hit detection
I'd like to allow the client to trigger hit events from their character (either for the purposes of hit slowdown, or actual damage!), and allow the server to only validate a "reasonable" result. This does open up possibilities for cheating, but should prevent any hitching due to hit slowdown or other effects being predicted on the client.