From 72c9a21bc2f642eade0ce74935086335229fe552 Mon Sep 17 00:00:00 2001 From: Drakmyth Date: Sun, 2 Jul 2017 10:50:15 -0700 Subject: [PATCH 1/5] Add supported RegistryEvent parameters to "Registering Things" --- docs/concepts/registries.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/concepts/registries.md b/docs/concepts/registries.md index d77ab399..a5459485 100644 --- a/docs/concepts/registries.md +++ b/docs/concepts/registries.md @@ -23,6 +23,8 @@ public void registerBlocks(RegistryEvent.Register 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` event has fired, all [`ObjectHolder`][ObjectHolder] annotations are refreshed, and after `Register` 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 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 From c31d14f1d0aa120bbc5d905098eca69b84f077f5 Mon Sep 17 00:00:00 2001 From: Drakmyth Date: Sun, 2 Jul 2017 10:53:47 -0700 Subject: [PATCH 2/5] Add important to "Loading Stages" directing modders to use RegistryEvents over Loading Stages --- docs/conventions/loadstages.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/docs/conventions/loadstages.md b/docs/conventions/loadstages.md index 96b8f000..8956fd0a 100644 --- a/docs/conventions/loadstages.md +++ b/docs/conventions/loadstages.md @@ -6,8 +6,13 @@ 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]. + ## Pre-Initialization Pre Init is the place to let the game know about all the blocks, items, etc that your mod provides. @@ -41,4 +46,6 @@ Common actions to preform in postInit are: ##Other Important Events * IMCEvent: Process received IMC Messages - * FMLServerStartingEvent: Register Commands \ No newline at end of file + * FMLServerStartingEvent: Register Commands + +[registering]: ../concepts/registries.md#registering-things From 3b7dd6ba8907af6459b64386f00e65496a09e9c1 Mon Sep 17 00:00:00 2001 From: Drakmyth Date: Sun, 2 Jul 2017 11:03:28 -0700 Subject: [PATCH 3/5] Added additional detail around *why* RegistryEvents should be preferred. --- docs/conventions/loadstages.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/conventions/loadstages.md b/docs/conventions/loadstages.md index 8956fd0a..f71ea8e6 100644 --- a/docs/conventions/loadstages.md +++ b/docs/conventions/loadstages.md @@ -12,6 +12,8 @@ Each of these stages occurs at a different point in the loading stage and thus w !!! 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). + RegistryEvents are fired after Pre-Initialization. ## Pre-Initialization From 328620aa993125a5538e80131c34f42fc85caff2 Mon Sep 17 00:00:00 2001 From: Drakmyth Date: Sun, 2 Jul 2017 23:28:26 -0700 Subject: [PATCH 4/5] Replaced incorrect 'Entity' with 'EntityEntry' --- docs/concepts/registries.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/registries.md b/docs/concepts/registries.md index a5459485..2c67d23d 100644 --- a/docs/concepts/registries.md +++ b/docs/concepts/registries.md @@ -23,7 +23,7 @@ public void registerBlocks(RegistryEvent.Register 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` event has fired, all [`ObjectHolder`][ObjectHolder] annotations are refreshed, and after `Register` 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` +`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. From c2dd4bb5297c7644f7cc10ebaf82ae7a82c12cff Mon Sep 17 00:00:00 2001 From: Drakmyth Date: Sun, 2 Jul 2017 23:28:37 -0700 Subject: [PATCH 5/5] Fixed typo --- docs/conventions/loadstages.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/conventions/loadstages.md b/docs/conventions/loadstages.md index f71ea8e6..2ded7169 100644 --- a/docs/conventions/loadstages.md +++ b/docs/conventions/loadstages.md @@ -12,7 +12,7 @@ Each of these stages occurs at a different point in the loading stage and thus w !!! 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). + 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