-
-
Notifications
You must be signed in to change notification settings - Fork 60
CommandAPI super‐future roadmap
Stuff I wanted, but isn't being worked on right now. Not sorted in any particular order.
The CommandAPI has always been known to be incompatible with /reload. To improve /reload compatibility, we should remove CommandAPI references in NMS when disabling. The CommandAPI stores objects that have references to CommandAPI-specific code. When performing a /reload, that specific code may be unloaded (either directly from the classpath, or otherwise via zip files) which can cause operations to fail when commands are run. As an example:
- We register the command
/mybroadcast <message>[brigadier:string]- As a part of registration, we have a lambda (our executor) declared in our plugin's
.jarfile - As a part of registration, we create a node in the NMS command dispatcher which calls our executor
- As a part of registration, we have a lambda (our executor) declared in our plugin's
- We update our plugin
.jarfile (e.g. recompile and export directly to theplugins/folder - We run
/reload - We run
/mybroadcast hello. This may call the old lambda, where the NMS command dispatcher points to an old version of our plugin.jarfile, causing a zip file exception
If, as a part of onDisable() (or otherwise), we traverse the NMS command dispatcher and remove all of the commands registered by the CommandAPI - don't worry, they'll be re-registered on /reload anyway!
The CommandAPI repository already uses GitHub Pages to host its primary website (commandapi.jorel.dev) from the docs/ directory. Documentation written in docssrc is manually moved to the docs/ folder for a release. Documentation written on the dev/dev branch isn't readily viewable from the main CommandAPI homepage, but instead is available at commandapi-live-docs.jorel.dev, which I host myself on my personal webserver. This simply runs a live mdBook server (using mdbook serve), looks for a GitHub push webwook and then runs git pull. It would be better and more maintainable to have all of this in a GitHub Action that could post the dev/dev docs, but I don't know if we can do something like that given that we're already publishing documentation from a specific location (i.e. the docs/ directory)
Hard paper fork #414
The CommandAPI currently has lots of "if running on a paper server, then do this" code. It would be desirable for the CommandAPI to have its own paper plugin instead of having to support Spigot entirely.
In my mind, I envision that:
- BaseComponent arguments can be removed
- Using a bootstrapper, it may be possible to avoid double-loading datapacks. In theory, the CommandAPI can register its commands in the bootstrapper, so they exist when datapacks load for the first time, so they pass first time. The only downside is this wouldn't be compatible with datapack reloading (we'd still be double-loading datapacks when using
/datapack reload), but it would make startup a little bit cleaner.
Obviously, this is being worked on at the moment and is currently scheduled for 10.0.0.
Sponge support #333
Support for Sponge.
The Command Visualizer is a TypeScript side project that I was working on for the CommandAPI's plugin command conversion system. Conceptually, the idea would be that server owners can paste their CommandAPI's config.yml file directly into the system, it would parse the CommandAPI's command conversion and offer a user interface where server owners can test their commands right in the browser. Inspired by the MiniMessageViewer.
Work for this was started in CommandAPI/docssrc/commandvisualizer and a placeholder for this feature is present on the CommandAPI's homepage. I never finished working on this.
Fabric support #308
Support for Fabric. The end goals with this is adding support for "true" custom arguments, which are custom arguments with client-side argument implementations, so you can have client side parsing as well. This was experimentally implemented with the dev/regex-mod branch and the JorelAli/MinecraftRegexArgumentMod repository. (As a bit of playing around and a proof of concept, I wrote a custom argument that could send over a class file in a packet to run arbitrary Java on a client's machine. This is not recommended by any means, but if you wanted to look at the code, I committed it here)
Support for Forge. I know Forge is a bit less popular than Fabric at the moment, but Forge is still in active development and is keeping up-to-date with Minecraft releases.
BungeeCord support #67
It would be nice for the CommandAPI to support more proxy servers such as BungeeCord, but I don't know anything about BungeeCord.
The idea being if you wanted to use the CommandAPI for a 1.20 server, but not a <1.19 server, there is no point having a chungus .jar file with a bunch of 1.15 - 1.19 NMS code. We can happy yeet those classes out of existence and the CommandAPI will run fine (by linking just to say, 1.20).
It would be cool for the website to have a system whereby it can make a custom "user-specific stripped-down" version of the CommandAPI automatically and provide a custom download or something. Extending this to create a CommandAPI for a range of versions (e.g. 1.18 - 1.20) would be nice.
Unfortunately, I can't see how this would work outside of just a general plugin download (e.g. I can't see how this would work with shading the CommandAPI)