Wolf Variant Biome Tags
catter1 opened this issue · 2 comments
Summary
I would like to see the creation of a set of biome tags for spawning the wolf variants. Something along the lines of #c:has_wolf_variant/<variant> for each wolf variant, and any future variants added by Vanilla or other mods.
Reasoning
With the current implementation, the biome(s) wolves can generate are currently hardcoded in the wolf_variant files. Three of the variants use biome tags (#minecraft:is_jungle, #minecraft:is_savanna, and #minecraft:is_badlands for the rusty, spotted, and striped variants, respectively), but the rest of the varaints only reference one biome. If another biome-adding mod/datapack wants to make the variants generate in their own biomes, they will have to override that file. This is an issue for compatibility reasons.
If they are implemented, a biome-adding mod/datapack would be able to add their biomes to the tags like normal. Then they would have the additional responsibility of overriding those wolf_variant files to reference the fabric tags instead of the hardcoded vanilla biome(s). Do keep in mind that I am speaking from the perspective of a datapack developer, who heavily relies on the tags.
Clarification
Important: This convention would not edit the actual wolf_variant files. That is what makes it a convention and not a behavior modification. It is up to each individual biome mod and datapack to implement the tag into the files. Obviously this is not ideal, but it is the best option we have for compatibility. There are downsides associated (i.e. what if a mod wants to change a Vanilla wolf texture), but this would not be at fault of Fabric/Neoforge/the convention, but rather an understanding.
Of course, if Mojang suddenly adds their own tags, that would solve this entire issue.
Application
Terralith and Regions Unexplored are popular mods that have agreed on using this tag convention. Both Terralith and Regions Unexplored will modify the wolf_variant files to reference the same #c:has_wolf_variant/<variant> tag, as well as add custom biomes to the tag. This allows both mods to add new biomes which can spawn wolf variants without completely overriding each other.
Semantics
The easy option is to say "just have separate fabric and neoforge tags for this". However, it has its own issues. For datapack developers that add their own biomes, what tag should they reference? The Fabric one, or the Neoforge one? One would have to choose which modloader to be compatible with.
Final Notes
As aforementioned, I am a datapack developer. It is very important for me and other datapack developers that some sort of tag is agreed upon. Otherwise - at least for datapacks - no one can add the Vanilla wolf variants to their own custom biomes without overriding the same work of another biome-adding datapack. Since we're on 1.20.5 pre-releases and Minecraft has not added tags themselves, having the c conventional tags seems like the best option we currently have.
This was discussed in a recent datapack convention discord meeting (Smithed) and I'd like to add a little bit of usage information that was discussed during the meeting.
this next paragraph has been added to the top post
Terralith and Regions Unexplored are popular worldgen mods that have agreed on using this tag convention. Both Terralith and Regions Unexplored will modify the wolf_variant files to reference the same #c:has_wolf_variant/<variant> tag, as well as add custom biomes to the tag. This allows both mods to add new biomes which can spawn wolf variants without completely overriding each other.
To reiterate, the idea is that a common tag convention is put in place so that if the wolf_variant files are changed they are done so in a consistent manner. The idea is not to impose the behavior change and forcefully change the wolf_variant files for everybody. Whether or not this tag convention passes in fabric doesn't change the fact that a common tag is necessary for compatibility. It would be odd to impose a common tag under the smithed namespace and ask mod creators to use it, so the c namespace feels like the best place to put this tag convention.