Minecraftforge: [1.12] Allow (select) registries to operate before Blocks & Items

[dries007]

I'd like it if I could harness the power of registries for things a ends up registering blocks & items for.

I'm willing to write the PR, I believe it would require about 10~20 lines of code over 4 files (RegistryBuilder, RegistryManager, ForgeRegistry, and finally GameData). Most of these would just be passing the boolean down to the registry.

In GameData, I'd change fireRegistryEvents:

// Sorting unchanged

for (ResourceLocation rl : keys)
{
    if (!filter.test(rl)) continue;
    if (rl == BLOCKS || rl == ITEMS) continue;
    Registry reg = RegistryManager.ACTIVE.getRegistry(rl);
    if (!reg.preBlocks) continue;
    MinecraftForge.EVENT_BUS.post(reg.getRegisterEvent(rl));
}
ObjectHolderRegistry.INSTANCE.applyObjectHolders(); // inject the preBlocks registries

// Blocks & Items unchanged

for (ResourceLocation rl : keys)
{
    if (!filter.test(rl)) continue;
    if (rl == BLOCKS || rl == ITEMS) continue;
    Registry reg = RegistryManager.ACTIVE.getRegistry(rl);
    if (reg.preBlocks) continue;
    MinecraftForge.EVENT_BUS.post(reg.getRegisterEvent(rl));
}
ObjectHolderRegistry.INSTANCE.applyObjectHolders(); // inject everything else

The use case is as follows:

I'm updating TerraFirmaCraft to 1.12.2 and would like to make it easier to write addons that add functionality to the base mod. By letting an addon register for example rock types, it would not have to take care of registering close to 50 blocks and items and integrating them into worldgen and other systems. Same for ores, metals, alloys, tree types, etc.

The infrastructure is all there, I just can't harness it at the moment. It would be a shame to have to write a pile of boilerplate for something already there.

Thanks in advance.

[liach]

i agree. other registries can be predecessor of block or item registries. i think we can add a registry toposort to handle that

[LexManos]

No, it's bee decided that this isn't needed.
The addon mod should be the one responsible for registering its own blocks and items.
Or, the parent mod should have its blocks/items not need to have seperate registry entries. Which is simple enough with non-ticking TES.
Opening this up just opens up a can or dependency worms. Which can be solved in better ways.

[dries007]

Use a non ticking TE for worgen (the early kind) doesn't sound like a good idea to me, if it's even possible.

There are other ways of doing this, for example by making a custom API, it has nothing but disadvantages over this solution. Registries where designed exactly for this purpose right? Allowing easy mod compatibility. I don't see how this causes more dependency mess than any other hard dependency.

If you (or anyone) could point me to a workable better solution that would be greatly appreciated.

The current plan is using our own registry-like system, but again, that's reinventing the wheel.

[LexManos]

The other way is to make the child mod register its own blocks.
Do that.

[diesieben07]

The other way is to make the child mod register its own blocks.

Just a remark on why this is the way to go: 1.13's Flattening will make block IDs not matter (as much). There is no need to have the parent mod collect subtypes into one block ID by metadata. Just register a separate block per subtype.

[dries007]

It's _not_ about collecting blocks into metadata. The reason it to avoid a pile of duplicate code and allow us to handle the blocks like they are part of our own code. This is not the only reason a sorting system is desired though, since I found this some other usecases have come to mind, one of which being soundevents (they fire after blocks, but are required by blocks), the other potions & potiontypes.

Lex said only a proper sorting system will be accepted, and I don't know what the conditions for that are, and I don't think I have the will or time for this, so I'll leave it to someone else. Good luck to whomever picks it up.

[liach]

Now I think you can expose a method for addons or compats to call during block registry events for that purpose.

[diesieben07]

The reason it to avoid a pile of duplicate code

Your base mod can expose base block classes that the child mods can use. This is standard practice... And at this point this is not really a Forge issue but something for the Forums.