[1.19] Custom registry not producing delegates

[percivalalb]

I'm running into a unexpected issue when trying to fetch delegates (`Holder.Reference` using `IForgeRegistry#getDelegate`).

For built in registries (like BLOCK) they seem to return a `Holder` for inbuilt and modded entries but as far as I can tell for custom registries always return an empty optional.

I've arugmented the ExampleMod to showcase the issue:

https://gist.github.com/percivalalb/9fe204c131d242af6709ef68f5b789b4

Is this a bug, incorrect usage or is there something additional I need to do for custom registries?

[warjort]

Can you explain why you need this?

Vanilla's Holder objects are a way to reference objects that don't exist yet, e.g. a value that will be placed in a registry later by datapack loading, or resolving circular references.

Forge has this mechanism in the RegistryObject.

RegistryObject<T> extends Supplier<T>

e.g. if you want to an Item to reference a potion effect (which are registered after Items) you do something like (untested pseudo code):

public MyItem(Properties props, Supplier<MobEffect> potion) {
    super(props);
    // remember how to get the potion (not registered yet)
    this.potion = potion;
}

public void usePotion() {
    // Retrieve the potion at runtime (will exist)
    this.potion().get().doStuff();
}

RegistryObject<MobEffect> MY_POTION = ...;
// Pass the "supplier" to the constructor
RegistryObject<Item> MY_ITEM = ITEMS.register("my_item", () -> new MyItem(props, MY_POTION));

 

[percivalalb]

Hi warjort thanks. My usecase is for a Map key that provides easy access to the key (ResourceLocation) & registered object (Item/Block/EntityType..).

Prior to 1.19 I used forge's `IRegistryDelegate` as keys in a long living Maps, as they stored a reference to the actual object as well as the resource location of that object in the registry. Using the delegate as a key was better as the equality of two registry items could be compared through the delegates using equals and you wouldn't need to store underlying object which could change and causing memory leaks. I'm not up to speed but perhaps this isn't want I need anymore. Using the resource location as a key and doing a look up in the relevant registry may be the way forward..