Hello! Someone was running my mod called Blame with a small modpack and it seemed to have found that Futurepack's ConfiguredFeatures are not registered. 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/584433a0745338802c84e9f498dc063c1f5505f8/src/main/java/com/telepathicgrunt/repurposedstructures/modinit/RSConfiguredStructures.java#L72-L74

I hope this helps!

From the log with Blame where it tried to figure out what unnamed configuredfeature is unregistered by parsing its json:

****************** 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:

futurepack:block_crystal_alutin
futurepack:block_crystal_neon
futurepack:crystal_bubble
futurepack:dungeon
futurepack:erse
futurepack:ore_bauxite
futurepack:ore_coal_m
futurepack:ore_copper
futurepack:ore_copper_m
futurepack:ore_magnetite
futurepack:ore_quartz_m
futurepack:ore_tin
futurepack:ore_zinc
futurepack:sand_alutin
futurepack:sand_neon

wait I also need to register the placement and everything else? Is that tool also detecting that? (Because I have literlay spend the last half year porting all of our custom world gen to the new system, which is horrible and super instable, and have not register a single thing because all of it is json). So if the tool also checks that it should mark tons of futurepack stuff.

Only new placement/feature classes that you made from scratch should be registered. If you are just using vanilla's feature classes or vanilla placements with different values (like .range(...) ), then those are fine. It's a bit hard for me to see what has to be done for this mod since Futurepack's internals is close source. But I can peer into the jar if you're alright with that. Though I suspect with futurepack, just the configuredfeature part is the issue.

Well having 4 custom dimensions I wrote alot of features & carvers from scratch. I hope Igot everything registered, can you check if this build still has unregistered worldgen fureates/carvers/placement... 21.0.8

you need to register configured features aswell ? why are there even jsons then, this makes this whole system kinda pointless...

If the configuredfeature is made by json, minecraft will register them automatically. The issue arises when mods try to make configuredfeatures in code but forget to register it. By not registering, the game turns the biome internally into json and then back into the biome object in order to populate the dynamic registry from the worldgen registry. However, upon the biome -> json conversion, that's where the codec responsible for the conversion would blow up if the list of configuredfeatures has both registered and unregistered ones mixed together.

The whole system is needed in order to make worldgen datapacks work. It's quite a rabbit hole lol. But by registering the configuredfeatures, it won't break other mods anymore (or vanilla too. Some people accidentally nuked vanilla features from biomes by mistake with unregistered stuff). Furthermore, registered configuredfeatures from mods can be reused in a worldgen datapack by users to add the stuff to other biomes too.

lmk if you need help with registering the configuredfeatures or figuring out why they are unregistered if you are already trying to register them.

in my case this boils down to having configs for ores or not, which is kinda dump for the end user. Becuase if I register them the configs are read to early and they will not work.

you can make the configuredfeatures with the configs just fine in FMLCommonSetupEvent like I do.

public void setup(final FMLCommonSetupEvent event)
{
	event.enqueueWork(() -> {
		//Moved the methods below into enqueue to make sure they dont cause issues during registration - andrew
		RSConfiguredFeatures.registerConfiguredFeatures();
		RSStructures.registerStructures();
		RSConfiguredStructures.registerStructureFeatures();
		RSStructureTagMap.setupTags();
	});
}

right so you can no longer change the config values at runtime/before world loading.

Ah yes. Well, sorta. It depends on what you are trying to do. If you are looking to do per-world configs for the ore placements, you can make your own placement class and have that read from your config during runtime (make sure to register the placement class too).

If you are doing ore size and stuff, making a custom ore feature (and registered too) that reads your config in its generate method could work too.

this way would allow ores configuredfeatures to get their changes instantly while in the world. It sounds like before, you were constructing the configuredfeatures in BiomeLoadingEvent with the configs which means people had to exit and re-enter the world for the effects to occur.

So there's two options right now. Either common config that applies to all worlds (easiest) or per-world config with custom placement/features (more time consuming to do)

Yep that solves it! The logs now show nothing about unregistered stuff. I did find some loot table issues with a structure but I'll open a separate report for that in a few mins once I get more info to help