Documented available RegistryEvents #114
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Drakmyth
commented
Jul 2, 2017
docs/concepts/registries.md
Outdated
| @@ -23,6 +23,8 @@ public void registerBlocks(RegistryEvent.Register<Block> event) { | |||
|
|
|||
| The order in which `RegistryEvent.Register` events fire is arbitrary, with the exception that `Block` will *always* fire first, and `Item` will *always* fire second, right after `Block`. After the `Register<Block>` event has fired, all [`ObjectHolder`][ObjectHolder] annotations are refreshed, and after `Register<Item>` has fired they are refreshed again. They are refreshed for a third time after *all* of the other `Register` events have fired. | |||
|
|
|||
| `RegistryEvent`s are currently supported for the following types: `Block`, `Item`, `Potion`, `Biome`, `SoundEvent`, `PotionType`, `Enchantment`, `IRecipe`, `VillagerProfession`, `Entity` | |||
There was a problem hiding this comment.
I got this list by looking at net.minecraftforge.registries.GameData. I'm not 100% certain Entity is supported, but it seemed like that was the intent so I included it here. I don't have time to test it right now, but I intend to at some point over the next few days. If that is not accurate, it can certainly be removed.
There was a problem hiding this comment.
Using the raw <Entity> event does not seem to work, I believe you still need to go through the old methods.
There was a problem hiding this comment.
There is no Entity registry. There is a EntityEntry registry.
0f-0b
reviewed
Jul 3, 2017
docs/conventions/loadstages.md
Outdated
| !!! important | ||
|
|
||
| Many objects that were previously registered in loading stage event handlers (Blocks, Items, Recipes, etc.) should now be registered via [RegistryEvents][registering]. | ||
| This is to pave the way to being able to reload mods dyanamically at runtime, which can't be done using loading stages (as they are fired once upon application startup). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Given that it is now "recommended and HIGHLY encouraged" to use RegistryEvents over registering during loading events, I thought it might be helpful to list which objects can be registered using RegistryEvents. I also added a link to the Loading Stages page to encourage modders not to continue doing their registrations there. In response to #85, I also included a bit of information around why RegistryEvents should be preferred.
Not having an in-depth knowledge of the inner-workings or direction motivations of Forge itself, if anything I've added is incorrect I'm happy to make changes.