Specifically:
* ClientCompletionKey -> CommandTreeNodeType
* ClientSuggestionProvider -> CommandCompletionProvider
The previous terminology was a hangover to when I originally designed the system and from numerous issues and chats on Discord, it's clear that... well, it's not clear what they are. Along with making sure we're consistent with using "completion" instead of "suggestion", it makes sense to revisit this and make sure the names are sensible (and the Javadocs are clearer)
I have not renamed "ClientCompletionType" because that's for use with parameterized commands and for what it does, it's a reasonable name (while I'm open to that being renamed, it's less important here)
Being the previous methods were poorly named and implemented on world coordinates, when
they ought to be clearer about chunk positions versus
block positions.
Signed-off-by: Gabriel Harris-Rouquette <gabizou@me.com>
This allows us to be somewhat future-proofed, but does
mean implementations may have to use a fork of Guice in
order to remain compatible with our Guava version and
API specification
Default placement is generally encouraged instead of 'ALL' as it may be triggering
other side effects (or not).
Signed-off-by: Gabriel Harris-Rouquette <gabizou@me.com>
This brings parity with what's considered "internal" vs. externally supported
in the API. Considering the uses of having "none" setting some of these flags
by default, they're safe to expose for various reasons.
Signed-off-by: Gabriel Harris-Rouquette <gabizou@me.com>
- Properly include source + JD jars in Gradle metadata
- Bump Caffeine to last Java 8-compatible version
- Remove noise from dependencies
- Update Javadoc links for current libraries
- Make Javadoc task fail when there are new errors introduced
- Bump licenser plugin version
* api: Introduce NotificationTickets
This revamps the previously meticulous brain-ache
NotifyNeighborBlockEvent into a more
streamlined event similar to ChangeBlock event. As
the batching system has proven useful, this can
safely expose directional suppliers
without explicitly relying on legacy logic of
"Always notify every neighbor on a target position"
Signed-off-by: Gabriel Harris-Rouquette <gabizou@me.com>
* we only dropped get prefixes
* Oops
Co-authored-by: ImMorpheus <ImMorpheus@users.noreply.github.com>
Some builders have also been renamed - dropping "set", favouring "add".
Fixes#2276 - so far that we're dropping "get" prefixes. We decided not to drop "set" prefixes.
Co-authored-by: Riley Park <riley.park@meino.net>