Datapack Registries

In 1.19.3+, the library also adds utilities for datapack registries, which are largely unrelated to the rest of the library. Since datapack registries heavily rely on Codecs and Holders, the datagen for them does as well.

Unlike regular datagen, datapack registry datagen uses one unified main provider, to which multiple sub-providers are attached. This is due to the way Holders work.

The provider

The one main difference to regular providers is the RegistryKey required. This RegistryKey corresponds to the datapack Registry in question (who could've thought). Reiterating on the Ability example used with custom datagen, our code would look something like this:

public abstract class AbilityProvider extends AbstractDatapackRegistryProvider<Ability> {
    public AbilityProvider(String namespace) {
        super(Ability.RESOURCE_KEY, namespace);
    }
    //potential helper methods here
}

Note that the generic type of the ResourceKey must match the generic type passed into the parent class.

And similar to before, the class is extended to add actual content:

public class MyAbilityProvider extends AbilityProvider {
    public MyAbilityProvider() {
        super("mymodid");
    }

    @Override
    public void generate() {
        //add things to generate here
    }
}

A thing to note is that you do not use builders. Instead, you directly instantiate the objects to serialize (e.g. new Ability(...)). Serialization is then handled by the associated Codec. Speaking of which, those need to be registered:

@SubscribeEvent
public static void registerDatapackRegistries(DataPackRegistryEvent.NewRegistry event) {
    event.dataPackRegistry(Ability.REGISTRY_KEY, Ability.CODEC, Ability.CODEC);
}

And then finally, we can register the provider. This is a little different than usually, though:

@SubscribeEvent
public static void gatherData(GatherDataEvent event) {
    event.getGenerator().getVanillaPack(event.includeServer()).addProvider(output -> new DatapackRegistryGenerator(
            output,
            event.getLookupProvider(),
            Set.of("mymodid"),
            List.of(new MyAbilityProvider())
    ));
}

Since this is a bit more complex, let's break it down:

• output is the lambda parameter provided by addProvider.
• event.getLookupProvider() is the lookup provider used to get Holders and other things.
• Set.of("mymodid") is a set of mod ids to include in the output. By default, the datapack registry provider would output everything, including the Minecraft data, so this set has been implemented to limit it to only the specified mod ids. Usually, this set will only contain your own mod id.
• List.of(new MyAbilityProvider()) is interesting. Since the internals of datapack registry generation are problematic at best, all datapack registry providers need to be added at once, using this list. In this case, the list contains only one provider, but if you add other providers, these will go into this list as well.