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

Standardize the two kinds of "blocking" in event callbacks #361

Open
Ruin0x11 opened this issue Sep 16, 2021 · 0 comments
Open

Standardize the two kinds of "blocking" in event callbacks #361

Ruin0x11 opened this issue Sep 16, 2021 · 0 comments
Labels
refactoring This requires refactoring existing code standardization Concerns conventions that should be strongly followed in mods

Comments

@Ruin0x11
Copy link
Owner

Ruin0x11 commented Sep 16, 2021

Many event callbacks intend to block the execution of callbacks further down in the chain, for example to override what happens when an item is picked up. The problem is that there is no standardized way in the event interface of doing this, so every instance of this kind of control flow handling in the current codebase is hacked on in various incompatible ways.

One thing that is important to consider is if the blocking feature should consider skipping over specific event callback IDs, or if it should always block everything that follows that callback. Having more granularity would increase complexity, but allow for better control over incompatible callbacks added by multiple mods.

There is another kind of "blocking" that is part of some events, to be handled by the callsite that triggers the event. Those are for things like preventing a character from taking their turn if they are afflicted with a status effect like paralysis. Usually, they set a turn result on the callback's result parameter that is checked at the callsite, and the caller returns early if it is present. Once again, these are not standardized at all, and should follow a single, consistent convention.

@Ruin0x11 Ruin0x11 added standardization Concerns conventions that should be strongly followed in mods refactoring This requires refactoring existing code labels Sep 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactoring This requires refactoring existing code standardization Concerns conventions that should be strongly followed in mods
Projects
None yet
Development

No branches or pull requests

1 participant