Not self advertising, I just genuinely think you should take a look at this:
Waiting for the response of a specific attribute change isn’t enough. You could want new custom behavior and you would need to implement this kind of client ↔ server communication in other features. When you wait for a specific attribute, you’re assuming your whole game state functionality relies on a specific attribute, as if it would never change; when changing it or adding a new one with similar functionality, you’d need to change every single line of code that relies on them. Not only this, but it’d be pretty ugly and unecessarily long having 2 or more connections to specific AttributeChanged signals, or some if elseif elseif.
Having a combat game means you can change anything at any time and as you add content you eventually need to implement new custom behavior or add new custom states, and adapting the whole game manually to the new states is a pain. Although I personally use a more complex structure than just this module, it’s an essential for me, and I use it in simpler combat games I work on that aren’t that big to the point of needing my whole personal pack.
With this module at least, you can just fire CancelActions(character, {Stop = true}) or {BlockBreak = true} and connect to the action cancelled event in the given script and check if BlockBreak equals true or something similar.
Another thing is I don’t recommend doing the action purely in the client… I’ve talked about this in another post recently so I will just link it: