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). For example, if we have an Ability class we want to generate the datapack registry entries for, 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 (so in our case, it would have to be a ResourceKey<Ability>).

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(new Ability(...));
        //add things to generate here
    }
}

A thing to note is that you do not use builders. Instead, you add instances of the objects to serialize. Serialization is then handled by the associated Codec. The Codec is the one set during DataPackRegistryEvent.NewRegistry; see the Forge documentation if you have questions about that.

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. Most of the time, this set will only contain your own mod id.
• List.of(new MyAbilityProvider()) contains the different datapack registry providers. 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.