Hello! I was test running my mod called Blame with a bunch of mods and it seemed to have found that NaturesAura does not register several ConfiguredFeatures. This can be an issue for mod compatibility as under certain conditions, unregistered ConfiguredFeatures can basically prevent other mod's registered ConfiguredFeatures from spawning if in the same generation stage.

By that I mean, if mod A adds an unregistered CF to the ore generation stage and the biome's codec reaches it first, it will choke and basically nuke mob B's registered CFs afterwards. Here's a case where BetterCaves forgot to register their CF and caused several CFs from Oh The Biomes You'll Go to stop spawning in the world: YUNG-GANG/YUNGs-Better-Caves#75

Here's a more detailed explanation of why this happens in the biome's codec:

Specifically, when you call .withConfiguration on a Feature, you create a ConfiguredFeature. This is what should be registered to the WorldgenRegisties at mod init (you can do it in FMLCommonSetupEvent so you have your config ready too if it is needed).

Anyway here's an example from my mod RepurposedStructures of me registering all my ConfiguredFeatures.
https://github.com/TelepathicGrunt/RepurposedStructures/blob/a4e3365e3867b8510952ebf658c415de6e412927/src/main/java/com/telepathicgrunt/repurposedstructures/RSConfiguredFeatures.java#L184-L185

I hope this helps!

From the log with Blame

****************** Blame Report 1.7.3 ******************

This is an experimental report. It is suppose to automatically read
the JSON of all the unregistered ConfiguredFeatures, ConfiguredStructures,
and ConfiguredCarvers. Then does its best to collect the terms that seem to
state whose mod the unregistered stuff belongs to.

Possible mods responsible for unregistered stuff:

naturesaura:aura_bloom
naturesaura:aura_cactus
naturesaura:aura_mushroom
naturesaura:crimson_aura_mushroom
naturesaura:warped_aura_mushroom

Looks like the latest release of nature's aura has unregistered confgiuredfeatures again (NaturesAura-33.4 on 1.16.4)

Here's what Blame found:

****************** Blame Report 1.9.2 ******************

This is an experimental report. It is suppose to automatically read
the JSON of all the unregistered ConfiguredFeatures, ConfiguredStructures,
and ConfiguredCarvers. Then does its best to collect the terms that seem to
state whose mod the unregistered stuff belongs to.

Possible mods responsible for unregistered stuff:

naturesaura:aura_bloom
naturesaura:aura_cactus
naturesaura:crimson_aura_mushroom
naturesaura:warped_aura_mushroom

Let me know if you need help!

As you can see in the commit, I register the features in the exact same way that you do (minus the actual names because my mappings are old), so I don't know what this is about.

I'll take a look later tonight and try to figure out what is going on. Sometimes it is due to misunderstandings like not realizing that the configuredfeature is the feature + config + the placement classes as well. It is confusing but every time a decorator is added on like .square() or .range(), it wraps the configuredfeature in a new one and returns that brand new configuredfeature. So a fully developed configuredfeature is actually several nested inside each other. But only the outermost one needs to be registered.

Another time, it was because someone was using suppliers for their configuredfeature which created a new instance every time .get() was called. that took me a while to figure out for that modder lmao. But yeah, don't fret, I'll figure it out later

I figured it out. Nothing was wrong with Blame (was worried for a second). It turned out the configuredfeatures were being registered under the wrong name and were registry replacing each other.

If you want to keep your current system, try
ReosurceLocation rl = ((DecoratedFeatureConfig)feature.config).feature.get().feature.getRegistryName();
instead and make sure it has the right name for each configuredfeature.

Hope this helps!

Hah, the old "getRegistryName() returns the literal name of the registry in vanilla registries" thing. The same is true for RegistryKey<World> and it is very confusing to everyone.

Huh, I didn't know you had to register these with the Forge event, with the biome AND with the vanilla registry. Why do you have to register features three times? Oh well.

Well, technically, a Feature and a ConfiguredFeature are two separate things. A Feature is part of what makes up a ConfiguredFeature

You register the Feature to the Forge Feature registry like you would with a block. It's the base component that holds the generation code.

Then you call .withConfiguration on it and give it a config. When you give a Feature a config, you create a ConfiguredFeature and can tack on placements as well. When the ConfiguredFeature is fully setup with placements as well, you register that to the vanilla worldgen registries as there is no Forge Registries for ConfiguredFeatures.

After that, then you add the registered ConfiguredFeature to the biomes with BiomeLoadEvent so that the biomes knows what they are suppose to generate.

To summarize:
Feature + config + 0 or more Placements = ConfiguredFeature.
Register ConfiguredFeature and then add it to biomes.

I hope this makes sense! Let me know if there's any part you're still confused on