Skip to content
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

Documented available RegistryEvents #114

Merged
merged 5 commits into from Jul 23, 2017
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 2 additions & 0 deletions docs/concepts/registries.md
Expand Up @@ -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`, `EntityEntry`

There is another, older way of registering objects into registries, using `GameRegistry.register`. Anytime something suggests using this method, it should be replaced with an event handler for the appropriate registry event. This method simply finds the registry corresponding to an `IForgeRegistryEntry` with `IForgeRegistryEntry::getRegistryType`, and then registers the object to the registry. There is also a convenience overload that takes an `IForgeRegistryEntry` and a `ResourceLocation`, which is equivalent to calling `IForgeRegistryEntry::setRegistryName`, followed by a `GameRegistry.register` call.

Creating Registries
Expand Down
11 changes: 10 additions & 1 deletion docs/conventions/loadstages.md
Expand Up @@ -6,8 +6,15 @@ There are some other events that are important too, depending on what your mod d
Each of these stages occurs at a different point in the loading stage and thus what can be safely done in each stage varies.

!!! note

Loading stage events can only be used in your `@Mod` class, in methods marked with the `@EventHandler` annotation.

!!! 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 dynamically at runtime, which can't be done using loading stages (as they are fired once upon application startup).
RegistryEvents are fired after Pre-Initialization.

## Pre-Initialization

Pre Init is the place to let the game know about all the blocks, items, etc that your mod provides.
Expand Down Expand Up @@ -41,4 +48,6 @@ Common actions to preform in postInit are:
##Other Important Events

* IMCEvent: Process received IMC Messages
* FMLServerStartingEvent: Register Commands
* FMLServerStartingEvent: Register Commands

[registering]: ../concepts/registries.md#registering-things