During the 1.20.2 development, there was a need to setup custom registry support for both Fabric and Neoforge loaders to support the Upgrade system as well as address outstanding technical debt from when major objects were hardcoded to use enums. (#182)
Due to the Neoforge/Forge split along with registry refactors from Mojang that affected all mod loaders, there was a lack of a clear understanding on how to create a common interface for object registration that supports both Fabric and Neoforge/Forge.
The existing DeferredRegistry system was retrofitted to support it, but technical debt dating from the initial 1.19 days still remained.
Alot of code was undocumented, and there were multiple areas of confusion which affected addon mod development.
Current State:
The existing DeferredRegistry object is used to register objects to both vanilla registries (such as Blocks, Items) and custom registries (Upgrades, Controls, ConsoleThemes).
Whilst this design is simplistic and works well when we are only developing for TardisRefined, the lack of documentation becomes confusing for addon mods
Example 1: Addon Mod ABC wants to add two new Upgrade types to TardisRefined, they may not be aware that they need to use the correct ResourceKey<Registry>, and also register under new entries their namespace.
Additions:
Refactors the package of some registry classes to the registries package
Adds documentation to the existing registry classes
Adds convenience methods for common lookup operations, such as retrieving entries, keys, codecs etc. which call the correct underlying fields.
Background:
Current State:
Example 1: Addon Mod ABC wants to add two new Upgrade types to TardisRefined, they may not be aware that they need to use the correct ResourceKey<Registry>, and also register under new entries their namespace.
Additions: