Fuzss
Fuzss
Yeah, an injected interface would be great for that. @cputnam-a11y What do you think would be a good signature for the callback? Maybe a single context object for the three...
Ah that's a good idea, there is `Vector3f` from JOML which is mutable.
Here is the mod I'm using this for: https://github.com/Fuzss/deleteworldstotrash
Edited my original description: The issue is also present on 1.21.8, so nothing new after all.
Yes, it works exactly the same as the other screen events, both on the api surface as well as the implementation.
> Looks like a reasonable approach. As Kevin suggested it might be a good idea to look at what #4620 was trying to as it can easily be done now...
Also I'd like to have something like an `Optional` for the return value, so that only when that is present the implementation actually sets the screen. I find that way...
> Im not sure about this, as the existing screen before/after init events provide a lot. As far as I can tell out of your use cases the only one...
Something along the lines of `ALLOW_OPEN` is what I had originally; the problem with that is that `Screen::removed` is called before the new screen is fully computed (vanilla has some...
The events should allow for forcing `ActionResult.PASS` / `ActionResult.PASS_TO_DEFAULT_BLOCK_ACTION` respectively when cancelling vanilla behavior. Ideally make the return value for the events `@Nullable`. This has long been an issue with...