Fabric API

Fabric API

108M Downloads

[FAPI 0.65.2] FabricBuiltinRegistriesProvider freezes Library

quiqueck opened this issue ยท 3 comments

commented

I just noticed that using multiple DataGeneratorEntrypoints with FabricBuiltinRegistriesProvider will freeze the builtin registries.

I might do things in a way that are not intended, but I have a setup where one Mod (BetterNether) builds again a library Mod (BCLib). Both provide DataGenerator Entrypoints and both of them add data to the builtin biome registry like this:

@Override
public void onInitializeDataGenerator(FabricDataGenerator dataGenerator) {
    registerSomeBiomes();
    final FabricDataGenerator.Pack pack = dataGenerator.createPack();
    pack.addProvider(FabricBuiltinRegistriesProvider.forCurrentMod());
}

However, the first DataGenerator that is executed will call this code before the second one runs:

public CompletableFuture<?> run(DataWriter writer) {
DynamicRegistryManager dynamicRegistryManager = BuiltinRegistries.createBuiltinRegistryManager();

which in turn freezes the builtin registries.

When the second DataGenerator is called, it will throw an IllegalStateException due to the frozen registries.

Now I am not sure if this is against the intended use of the API. When I put the registerSomeBiomes-call into the regular ModInitializer.onInitialize everything works as expected, but then the Biomes are added to the builtin Registries during normal execution (i.e. the common entry point) as well. However, I figured that is no longer a thing a Mod should do, but instead rely on the DataPack-Data generated by the DataGenerator.

It would be great if you could find a brief moment to clarify wether or not it is intended to continue to add Biomes during ModInitializer.onInitialize

commented

You can register biomes in onInitialize. However, as you said it has no effect on actual worldgen (which uses JSON).

commented

@quiqueck Does that answer your question?

commented

Yep