You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Why this logic should be in the library, and not user game logic
Checks values are either fed through constructors, or the supplied unit. This becomes an issue when we want more control over the values inside, like changing cooldown timer, cost or chance.
Describe the solution you'd like
Either feeding some kind of state to the checks (either through unit or something separate), or doing manipulation through callbacks/other setup.
Describe alternatives you've considered, and why they don't work
Custom checks are not ideal since we'd need to store data about it directly in the unit, without any refactoring. Which is a bad solution.
Possible issues
Previous checks without mutable state will now most likely not be a thing, unless that mutable state is stored outside the checks and fed instead.
The text was updated successfully, but these errors were encountered:
Why this logic should be in the library, and not user game logic
Checks values are either fed through constructors, or the supplied unit. This becomes an issue when we want more control over the values inside, like changing cooldown timer, cost or chance.
Describe the solution you'd like
Either feeding some kind of state to the checks (either through unit or something separate), or doing manipulation through callbacks/other setup.
Describe alternatives you've considered, and why they don't work
Custom checks are not ideal since we'd need to store data about it directly in the unit, without any refactoring. Which is a bad solution.
Possible issues
Previous checks without mutable state will now most likely not be a thing, unless that mutable state is stored outside the checks and fed instead.
The text was updated successfully, but these errors were encountered: