Hello, I'm the art director of a mod development team that is having to add hundreds of mobs via biome tags. In developing for Fabric we've found that no major biome mods on Fabric are using any common biome tags yet, and looking over the common biome tag list being supplied by Fabric itself, it seems rather disorganized and formatted very differently from vanilla Minecraft's biome tags. Some tags are also redundant, and many important ones are missing. It's possible all of this may be part of the reason no mods are using them. I would propose some changes be made to the common biome tag system before I request any biome mods to make use of it.

First, I would suggest using vanilla Minecraft's biome tag name formatting of "is_forest" rather than "forest", since all mods are already following that for their own biome tags. This also includes changing all plurals to singular, so "nether_forests" would be "is_nether_forest". Other tags, "in_overworld", "in_nether", and "in_the_end" should be renamed to match their official tags as well, which are "is_overworld", "is_nether", and "is_end".

Second, the climate definitions of the Forge Biome Dictionary never made much sense, so I wouldn't copy it. Vanilla Minecraft already has its own clearly defined climate system based on biome temperature, which can be found in the Minecraft wiki listed as "cold," "snowy," "temperate," and "warm." These four tags are most useful for categorizing climate since they're based on the actual temperature values of the biomes, which have mechanic functions. This also eliminates the need for tags such as "dry" or "wet", since all "warm" biomes are exactly the same as "dry", and "wet" is identical to tags "is_jungle" and "is_swamp" combined. "snowy" would be moved to "is_climate_snowy" and updated to include all biomes in that climate list.

Next, I would remove the tags "flower_forest", "mesa", "mountain_slope", and "underground". These tags are redundant with other tags. Flower forests belong under the tag "floral" as the forest distinction is probably excessively specific. Badlands was the official rename of Mesa, so they're identical. Slopes are also probably excessively specific and the "snowy_slopes" biome is functionally pretty much the same as the "peaks" biomes aside from also being part of "is_climate_snowy". Underground is exactly the same as "is_cave".

Changes that should be made to existing tags are: A rename of "extreme_hills" to "is_hills", as Extreme Hills was officially removed a long time ago and replaced by a new series of biomes officially tagged "is_hills". "snowy_plains" could also be renamed to "is_tundra" to be more inclusive of other expansive flat snow biomes, which are functionally the same. "icy" could be renamed to "is_glacial" to be more clear. "aquatic_icy" could be renamed to "is_frozen" if you want a more distinct name as well. The "grove" biome should also probably be added to "is_taiga". It may also be worth considering adding "dark_forest" to "is_mushroom" since the biome has a high number of mushrooms.

Finally, a list of useful new tags to include that I can think of would be "is_bamboo" (containing bamboo_jungle), "is_deep_dark" (containing deep_dark), "is_freshwater" (containing #c:is_river and #c:is_swamp), "is_island" (containing mushroom_fields), "is_magical", "is_sky", "is_snowy_forest" (containing all snowy taiga biomes), "is_spooky" (perhaps containing dark_forest), and "is_volcanic". Additionally, tags for "is_frozen_ocean", "is_cold_ocean", "is_lukewarm_ocean", or "is_warm_ocean" could potentially be added if you wanted to allow defining oceans by climate as well, though is niche enough it may not be needed.

That concludes my list of suggested changes to update the common biome tags into something more standardized, better defined, less redundant, and more useful.

Also, last thing, In developing for Fabric we've found that no major biome mods on Fabric are using any common biome tags yet. This is false. Oh the Biomes you Go, Terralith, Terrestria, William Wyther Worldgen Overhaul all use c biome tags and they are the major biome mods.

If you know of mods that do not use the c biome tag, ping me and I’ll go make an issue report to them to use the tags like they should be using. I already reached out to several smaller mods to use the tags as well.

Now do note this, the biome tags are more for vanilla dimensions. If a mod makes a custom dimension but does not want overworld-like structures or mobs, they should not use the vanilla or c biome tags because those tags are used by structures and mobs often to add overworld-based mobs to overworld biomes. Users can add the custom dimension’s biomes to the c/vanilla biome tags if they do want to spawn stuff in the custom dimension. After all, it is much much easier to add a biome to a tag than it is to remove a biome from a tag. I gotten lots of complaints when my overworld-based structures used to spawn in twilight forest dimension because that mod was designed to not have anyone else’s structure or mob in the dimension. So twilightforest won’t use the c/vanilla biome tags for this reason and leave it to the user to opt in by datapack if they want.

I thought these names were created by the devs of hundreds of mods and data packs, not FAPI. Can FAPI rename them?

No. Do not rename and/or remove existing tags. You will break a lot of biome mods and datapacks that I already had to push to use the tags in the first place.

Furthermore, changing these tags now will make people use FAPI’s biome tags much less because it is now volatile and cannot be trusted to not have more sweeping changes in the future. It’ll lead to incompatibility as well since several mods and datapacks will be using the old c tags while other mods and checking for the new c tags when they view fapi.

I already contributed biome tags for Terralith and WWOO with their 160+ biomes and I rather not do that again. Only way I would see such a change even having a chance of being viable is whoever makes this PR goes out to all the currently biome datapacks and mods and contribute updated tags to them all at once to prevent incompatibility or resistance to change.

Thanks a lot TG for the clarification. As such, we will not be changing these tags.