Make onEnable always run before worlds load, remove onLoad
, remove load:
from plugin.yml
#6330
Labels
BC break
Breaks API compatibility
Category: API
Related to the plugin API
Opinions Wanted
Request for comments & opinions from the community
Type: Enhancement
Contributes features or other improvements to PocketMine-MP
Description
This is linked to the following issues: #3067
We want to get rid of
onLoad
, and makeonEnable
the defacto standard (or possibly the other way round).Right now, the only reason to use
onLoad
is if you want to useload: POSTWORLD
to haveonEnable
do things after the worlds are loaded within the same plugin. This is an uncommon case, and it's also clunky: you can't register event handlers or schedule tasks duringonLoad
. This case could be better served by adding an event, e.g.StartupWorldsLoadedEvent
, so that plugins can run theironEnable
before the worlds load and do logic at thePOSTWORLD
step.In short, your options for startup work are as follows:
POSTWORLD
(most plugins) - you can't register new generators, world providers etc in time for worlds to loadSTARTUP
- you can do some extra stuff pre-world, but you can't do anything to worldsPOSTWORLD
+onLoad
- you can do some pre-world stuff and all normal post-world stuff, but you can't listen for world loading events, plugin load events, etc -onLoad
also can't disable the pluginWith this proposal:
onEnable
would effectively always haveSTARTUP
order - you'd be able to do everything except interact with worldsStartupWorldsLoadedEvent
would allow you to do whatever extra postworld work you needonLoad
andonEnable
trying to get them to workThis also has the happy side effect of deleting a confusing
plugin.yml
directive, makingonEnable
behaviour more predictable (no need to look atplugin.yml
to see what you can and can't do), and removing some API cruft (no more getting confused betweenonLoad
andonEnable
).Alternative methods
We could just remove the restrictions from
onLoad
instead (and perhaps makeonEnable
always run atPOSTWORLD
). However, I think that this would make the intended purpose of these two hooks even more confusing, asonEnable
wouldn't live up to its name anymore.The text was updated successfully, but these errors were encountered: