-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Registry Modification API #8920
Conversation
a9bf51a
to
2f40827
Compare
2f40827
to
52f2089
Compare
8db100c
to
1edf434
Compare
patches/server/0964-Support-registry-mod-API-with-GameEvent.patch
Outdated
Show resolved
Hide resolved
patches/server/0964-Support-registry-mod-API-with-GameEvent.patch
Outdated
Show resolved
Hide resolved
4faadcf
to
41d255f
Compare
Updated for 1.19.4 and moved the vibration level to the builder so that it can be changed. Also added a test to make sure the match the map that was previously used. |
patches/server/0962-Support-registry-mod-API-with-GameEvent.patch
Outdated
Show resolved
Hide resolved
5ace877
to
19508f6
Compare
9b1ff9b
to
d0708a3
Compare
d0708a3
to
b9991c4
Compare
73ec071
to
ee324d6
Compare
For the GameEvent builder, I decided to not make the vibration level configurable there. They are really 2 different systems, the vibration stuff and game events. Not all game events are listened to for vibrations, so I think a better solution is to use the game event bukkit events to change the level of certain game events. I also reverted the change that changed all the static final fields in GameEvent to Reference because we are now going with code generation to generate a file full of keys for GameEvent for use with the registry mod api. |
18eebc2
to
c32bcc0
Compare
+/** | ||
+ * Register listeners to points in a registry's lifecycle. | ||
+ */ | ||
[email protected] | ||
[email protected] | ||
+public interface RegistryManager { | ||
+ | ||
+ /** | ||
+ * Register a listener which is called when an object is about | ||
+ * to be added to the specified registry. Useful for modifying | ||
+ * objects before they are added. | ||
+ * | ||
+ * @param registryKey the registry key | ||
+ * @param listener an instance of the listener | ||
+ * @param <T> object type | ||
+ * @param <B> object builder type | ||
+ */ | ||
+ <T extends Keyed, B extends RegistryBuilder<T>> void registerAdditionListener(@NotNull RegistryKey<T> registryKey, @NotNull RegistryAdditionListener<T, B> listener); | ||
+ | ||
+ /** | ||
+ * Register a listener which is called when a registry is about | ||
+ * to be frozen. Useful for adding new entries to registries | ||
+ * that support custom entries. | ||
+ * | ||
+ * @param registryKey the registry key | ||
+ * @param listener an instance of the listener | ||
+ * @param <T> object type | ||
+ * @param <B> object builder type | ||
+ */ | ||
+ <T extends Keyed, B extends RegistryBuilder<T>> void registerPreFreezeListener(@NotNull RegistryKey<T> registryKey, @NotNull RegistryPreFreezeListener<T, B> listener); | ||
+} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may just be me, but I find the usage of "register" in the context of registries despite being used for the listener system be a bit confusing.
Although it would deviate from PluginManger's registerEvent naming scheme.. I think it may be better to reduce confusion.
Maybe something like:
newRegisterListener
,newRegistrationListener
,onRegistration
onFinalization
,onPreFreeze
,onRegistryFinalization
I am not sure, the point is, I think that we should perhaps not use the term register here as it may be a bit confusing. Although, just seeing what others might think here.
1ff0675
to
38e3441
Compare
38e3441
to
6a9d061
Compare
e882fe4
to
0511ba4
Compare
🥳❔ |
d7fc4f7
to
6385241
Compare
7054949
to
df157b7
Compare
Merged into preliminary 1.21 registry dev branch |
Adds two new "events" that PluginBootstrap can register to which enable modification and addition to both built-in and data-driven registries. This opens up tons of new possibilities for plugins to customize things with API that was previously only possible with nms/reflection.
Data-Driven: Types which are loaded purely from datapacks (custom and vanilla)
Built-In: Loaded via source code, never read from a file
There are two events plugins can listen to, one is fired when an "entry" is about to be added to a registry, either a built-in or data-driven. This allows modification of the "entry" before it's registered. The second event is fired right before the registry is frozen (to prevent new additions). This is used to add completely new entries.
Demo
There are two "demonstration" apis added, one for ChatType and one for GameEvent. Just allows some very simply customization, more just to show how it works for both built-in and data-driven types.
TODO