Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CooldownState::trigger can incorrectly(?) put something on cooldown #71

Closed
alanbaumgartner opened this issue Dec 15, 2024 · 1 comment · Fixed by #72
Closed

CooldownState::trigger can incorrectly(?) put something on cooldown #71

alanbaumgartner opened this issue Dec 15, 2024 · 1 comment · Fixed by #72
Labels
usability Make the APIs easier to use

Comments

@alanbaumgartner
Copy link
Contributor

Which feature is frustrating to use or confusing?

This can be paired with [`Cooldowns::ready`],
to check if the action can be used before triggering its cooldown,
or this can be used on its own,
reading the returned [`Result`] to determine if the ability was used.

Based on the docs, I expect that if this function returns an error indicating an ability was not used, it should not also trigger the non-global cooldown.
I also take the docs to mean, I can skip calling ready and use the result here.

Because this can be called without first calling CooldownState::ready, it may trigger the ability cooldown but then fail on the global cooldown.

Expectation

CooldownState::trigger does not trigger cooldowns if an ability was not used.

Proposal

I believe CooldownState::trigger should call CooldownState::ready itself, prior to attempting to trigger the ability and global cooldowns.

    pub fn trigger(&mut self, action: &A) -> Result<(), CannotUseAbility> {
        self.ready(action)?;

        if let Some(cooldown) = self.get_mut(action) {
            cooldown.trigger()?;
        }

        if let Some(global_cooldown) = self.global_cooldown.as_mut() {
            global_cooldown.trigger()?;
        }

        Ok(())
    }

I am willing to PR this if the above is agreeable 😄, I am also willing to take a stab at #36 and #51 if they are still applicable.

@alanbaumgartner alanbaumgartner added the usability Make the APIs easier to use label Dec 15, 2024
@alice-i-cecile
Copy link
Contributor

That sounds great. #51 is definitely applicable, and I think we can borrow from LWIM for #36.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
usability Make the APIs easier to use
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants