Idofront
Idofront copied to clipboard
Shared logic for our plugins and Gradle buildscripts
It should just ignore whatever the non-first ones are Either comment them out or remove them entirely ```yaml subMenus: "armor": type: CYCLING button: .... modifiers: .... type: "MENU" ``` ```...
We're starting to want support for serializing items generated by other plugins. An extension system would help us keep the main module clean while letting us or other authors add...
Somehow scan the entire command tree on startup to learn about the arguments being used. This is mainly useful for autocomplete. We may need some files to provide descriptions for...
Currently not merge-able due to relying on a custom server fork published to maven-local until paper merges their PR
Currently some modules used in Geary like DI are written for Kotlin/Multiplatform. We should be adding as many build targets as possible to make these more useful to other projects,...
Support ranges without an upper bound with the following syntax: - `>20`, `>=20`, `
Currently it forces an optional argument to execute as another player, which might be unwanted for some commands. Some might also want to take a list of players, we should...
Since we inline the whole tree right now, hotswapping code changes doesn't actually reload them ingame. Investigate if not inlining the final executes blocks can help mitigate this, or if...
Currently it cannot get plugins via a superclass, which causes issues when plugins only expose an interface but not their exact impl. This interface might also not extend Plugin, so...
- [ ] Document versioning rules (we only want breaking changes every Minecraft update) - [ ] Add github action that validates binary compatiblity, preferably as automated as possible (kotlinx.binary-compatibility-validator...