Paper Plugin Future Planning

[Owen1212055]

This is created to help forward possible more conversation and ideas that may be prompted under the whole new "paper plugin" umbrella.
With the paper plugin PR released, this allows us to ensure that we are able to remain compatible with previous spigot plugins.

These types of plugins are currently experimental, all API regarding it is subject to change.
Currently, paper plugins won't be offered with much new API, as those are still in the works.

This allows us to prompt for conversation for possible future new features:

### General TODO
- [ ] #8789
- [ ] Better link integration (https://github.com/PaperMC/Paper/pull/8108#issuecomment-1419208091)
- [ ] #8108
- [ ] #8235
- [ ] #8865
- [ ] #8920

[Andre601]

My suggestion is a more direct support for bstats, so that plugin devs won't have to shade and relocate it into their plugin.

[Brokkonaut]

What I would like to have is a change in the plugin loading system, so when a plugin cannot be loaded or enabled for any reason the server should not start at all. reason: a plugin that cannot be enabled is always a severe misconfiguration of the server and can easily cause additional damage if the server starts anyway.

[Andre601]

Something else that imo could deserve a rework is the api-version option.
Feels for me a bit annoying that you can only define a single API version rather than multiple ones (Given that your plugin isn't using stuff depending on one version).

Having the server yell that "Plugin X is made with an older version" or something like that because the dev keeps the api version low for backwards compat is a bit annoying...

So maybe make it a list? Or allow some format similar to mods where you f.e. can have >=1.19 defined?

[electronicboy]

The notion of defining an API version is pointless

a) The entire system as it stands is practically just a boolean check for if it's defined or not, there is no branching there

b) Why should we determine what API versions the server determines as compatible? When you look at stuff like vault eco, the entire notion of API compatibility is stupid (especially defined by the server), given that they don't even really touch anything inside of bukkit outside of the services API stuff

c) The entire system is highly redundant, while maybe having some "built against" might be nice for future hacks, there is no usage for it outside of hacks, I'm not sure that the new system even really cares about that?

[Andre601]

The notion of defining an API version is pointless

a) The entire system as it stands is practically just a boolean check for if it's defined or not, there is no branching there

b) Why should we determine what API versions the server determines as compatible? When you look at stuff like vault eco, the entire notion of API compatibility is stupid (especially defined by the server), given that they don't even really touch anything inside of bukkit outside of the services API stuff

c) The entire system is highly redundant, while maybe having some "built against" might be nice for future hacks, there is no usage for it outside of hacks, I'm not sure that the new system even really cares about that?

Well, then either remove it, or perhaps make it kinda the oposite way of how it works?
Like allow a plugin dev to tell the server "Hey, this plugin is not supporting version(s) X(, Y, Z), so don't load it on those".
I feel like this could be a good idea to consider as a plugin may use features only present in more recent releases (or the oposite that a feature was removed and the plugin no longer works on those).

Right now this would obviously be pointless as that check wouldn't work on older Paper releases (Unless people would retroactively patch this into their 1.8 forks :P) obviously, but for the future could it be an interesting thing to have as not everyone has any clue how to obtain the current server version and check it against their supported versions...

[Andre601]

Something else that just came to mind: What about a change to the authors option to allow adding a personal link, description, etc?

Like f.e.

authors:
  - name: MainAuthor
    description: Core maintainer of the plugin
    website: https://example.com
  - name: SomeTranslator
    description: Provides translations

That info could then be included in /version <plugin> through hover text for the listed authors...

I think that could be useful in giving people proper credit for what they do instead of just being names in a list only.

[Akiranya]

I hope paper-plugins.yml can support the commands entries just like in the plugin.yml 🚀

it would make the migration to paper-plugin.yml easier

[Machine-Maker]

paper-plugin.yml is still very much in the experimental phase. I don't think we are expecting everyone to move to it now. commands will never be a part of it however. Commands will be registered at runtime using an upcoming brig API or currently you can manually extend Command/PluginIdentifiableCommand in a class and register your commands to the commandmap yourself.

[Andre601]

currently you can manually extend Command/PluginIdentifiableCommand in a class and register your commands to the commandmap yourself.

How would this look like in terms of code? 🤔

[Phoenix616]

commands` will never be a part of it however. Commands will be registered at runtime using an upcoming brig API or currently you can manually extend Command/PluginIdentifiableCommand in a class and register your commands to the commandmap yourself.

Please add the ability to output all commands, usages and permissions in a human readable and obvious way then. Definining commands via the plugin.yml has the major benefit that users can just open the jar with any zip program and check the plugin.yml for the commands and permissions a plugin has. (And yes, I know a good chunk of people that do that, it's not just me)

Of course this breaks down in more complex setups and parts of it can already one by other plugins (e.g. easily getting all permissions with LuckPerms) but having an inbuilt way to get such info (potentially even on a sub command/command argument basis) would be pretty nice.

[electronicboy]

The big issue is "how do we do that"

The entire reason that we don't wanna expose commands inside of the new system is that they'd be tied to bukkits dated command system which has far outstayed its welcome; I guess we could aim to have plugins provide some form of meta when they ask to register a command, but, idk how we'd expose that to users

[maestro-denery]

So, my suggestions are:

1. LevelStem API, WorldCreator API enhancements / a new API for the world creation. CraftServer#createWorld(WorldCreator) method does a lot of stuff internally which isn't configurable, especially the World.Environment enum which is internally converted to the LevelStem, which contains Holder<DimensionType>, which is configurable by datapacks and is synchronized with the client, I think we can use EnumCreators from my PR there as well, but tbh I think it's better to make a new API provided by a PluginProviderContext so created dimensions are created alongside datapack ones, and there will be configurable dimension types and more functionality.
2. Tags API for the Registry API. For now my PR doesn't have Tag support, mainly because it's an another ton of work to do and generally is not as important as other stuff. I think when the Brigadier API is done or any other API which supports reloaded content I can do the Tag support.
3. FeatureFlags API. It's a bit controversial, feature flags are stored in the WorldDataConfiguration -> LevelSettings -> PrimaryLevelData -> ServerLevel. It means they're per world, all checks based on them are made using the ServerLevel#enabledFeatures(), but it refers to the main PrimaryLevelData stored in the MinecraftServer, we can make this method return enabled feature of its own PrimaryLevelData, make ClientboundUpdateEnabledFeaturesPacket send to the clients when they cross dimensions, (client handler doesn't have any restrictions on sending it multiple times) so we can have per world feature flags and an API to create worlds with them / configure them for already existing worlds.