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.

[Andre601]

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...

I'm still in favour of adding some kind of way for a plugin dev to either define supported or unsupported server versions for their plugin. Maybe even extend this to dependency declarations?

It would allow an easier way of telling the user that plugin X doesn't work on server version Y or with plugin version Z, as those versions may lack required API methods a dev either has to make complicated workarounds for (i.e. NMS access) or not use at all.

For plugins that don't declare these versions should it just assume you accept any versions.

And if doable, allow declarations like >=1.19 to tell the server your plugin supports versions bigger or equal to 1.19.

Yes, yes, right now there is no use because it's legit only one version (Plugin dependencies on the other hand would have a bigger use out of this already), but it's better to build for the future and have it.

[Phoenix616]

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

Simply having it part of some command like /help <pluginname> could help a lot. That could just output information based on the possible brigadier argument combinations.

[MelonHell]

Wow, looks very interesting! the main question that worries me, will the connection of libraries be somehow improved?

Problem example:
I have a plugin that is written in Kotlin, if I load Kotlin through libraries in plugin.yml or pack it in jar, then when I try to interact with another Kotlin plugin, I will get a LinkageError

Current Solution:
Create a plugin containing Kotlin, for example let's call it KotlinPlugin and my first and second plugin should be dependent on KotlinPlugin

Solution I want:
Ability to specify libraries in paper-plugin.yml (ideally not just from mavenCentral) and have their classes shared between plugins that use them

[Andre601]

I mentioned a possible solution for reload, which is having an event plugins can listen to, to then decide what to do with that.
That way, it's open to the plugin to decide what it wants to do on a reload and the command stays imo relatively safe, no?

[MelonHell]

reloading is not exactly a mechanism supported by mojang, as such, it's not something that can be nicely exposed outside of the limited contexts that vanilla allows.

Reloading random plugins is not supported by the plugin manager, because you can't just safely unload random plugins at runtime, you'd need to effectively tear down the entire dependendents tree, which just creates cause for more unpredictable behavior. This is not something that java itself supports nicely in the context of these environments, nor is it something we really desire to waste our time on. Not to mention: The entire point of reloading is that it reloads all data, that means that you need to clear the servers state and properly call into the bootstrapers of plugins to actually load data, something which doing on running plugins is probably going to create more issues than it solves.

maybe I'm developing plugins wrong somehow, but I always use /plugman reload instead of hotswap during development, since hotswap is very limited

now I have to restart the server literally every 5-10 minutes, which takes 5 minutes and discourages motivation

[electronicboy]

you can use the jetbrains runtime + hotswap agent to drastically improve the hotswapping capabilities

[MelonHell]

I mentioned a possible solution for reload, which is having an event plugins can listen to, to then decide what to do with that.
That way, it's open to the plugin to decide what it wants to do on a reload and the command stays imo relatively safe, no?

this solution will not help, since it will not differ in any way from the custom /myplugin reload. we need to reload the entire jar file

[Andre601]

That's a you-problem honestly.
I for my part have no issues stoping my server, putting new jar in, delete old one and start server again.

Developing stuff can be time consuming and may not be easy, so why do you want a fundamentally broken system here?

[MelonHell]

this system does not prevent me from restarting the server in the same way, but when I know that my plugin does not break in any way from this "broken system" I can speed up development several times

[tal5]

this system does not prevent me from restarting the server in the same way, but when I know that my plugin does not break in any way from this "broken system" I can speed up development several times

But you don't know that, the whole point is that it breaks in entirely unexpected ways and causes weird issues, especially with newer plugin API (I.e. would it re-call PluginBootstrap#createPlugin? that might cause even more unexpected issues with bootstrap code executing at weird times)
I see no reason for Paper devs to put time into creating and maintaining a fundamentally broken system, especially not when there are alternatives such as hot reload/just restarting

[Andre601]

Additionally, this is - again - a you-problem.
Just because it would work for your plugin doesn't mean it wouldn't break other plugins 6 ways to sunday.

And don't give me the excuse about it being a config option or even env var for devs only.
People will find and use it because they can and because they are lazy.
It would break plugins, especially those more complex than others.

[MelonHell]

Additionally, this is - again - a you-problem.
Just because it would work for your plugin doesn't mean it wouldn't break other plugins 6 ways to sunday.

And don't give me the excuse about it being a config option or even env var for devs only.
People will find and use it because they can and because they are lazy.
It would break plugins, especially those more complex than others.

what's the problem with disabling this feature by default and putting it in the config with a huge warning?

[Malfrador]

Additionally it's probably straight up impossible to make this work with the upcoming registry modification API.
A plugin being reloaded would try to redo it's registry modifications. At that point, the registries will be frozen however because the server is already running.
And considering several registries are synched with the client, there is no way around that (other than disconnecting all players on reload, which effectively would be a restart lol).

And with more and more things being backed up by a registry this means that a pretty significant part of future plugins won't be able to be reloaded anyways, making a reload feature even less useful.

[shubham8550]

now that paper got its one plugin respository

it will be great if they can make MPM -minecraft plugin manager

it ill be great specially mpm update will save pain
and versioning will be better

[electronicboy]

There already is such software, no reason for us to create such a thing (nor is it relevant to this PR)

[Andre601]

What kind of thing? Never heard of that (And I get the feeling it would be a useless thing anyways)

[electronicboy]

Reloading plugins has never been a part of the API, nor is it even possibly to actually implement fully. If plugins want to half shim this mess into working, they can, but we're not going to add something that is unsuportable to the api. Afaik, a plugin or two has already updated for this, but, there's literally nothing we can do here.

…

On Wed, 5 Jul 2023, 11:17 ViaBackwards, ***@***.***> wrote: Reloading plugins is still a sorely missed feature during development, plugman reload used to take 2 seconds, whereas a full restart takes 20-30, I can't use intellij debugging because my test server is remote :/. I know you say its not "safe" on paper to reload plugins and I get that, but from real world testing in development the server has never had any issues except using stale classes, which just causes some data not to refresh, but when you are a developer you understand that, if you reload a plugin which another plugin depends on, to refresh the data you need to also reload the dependants, /plugman reloading 2 or 3 plugins is still 100x faster than restarting the server. — Reply to this email directly, view it on GitHub <#8859 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJMAZDE4ZI6SR7TLBKGWELXOU5LXANCNFSM6AAAAAAVAM2TKI> . You are receiving this because you commented.Message ID: ***@***.***>

[PukPukov]

That's a you-problem honestly.

I just wont use paper plugins, lol.