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.
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
resultparameter 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.