What feature would improve this mod?

The main idea would be to either modify the tags minecraft:base_stone_overworld, minecraft:base_stone_nether, etc or/and add a similar tag system that stones (maybe ores) registered through this mod can automatically have.

Why would this feature be useful?

While this can be achieved using datapacks, this feature allows changes made in this mod's configs much easier to implement in features such as worldgen because it provides a centralized way of identifying a "stone".

For example, I am currently using OreTweaker (forge mod) to generate ores. My configuration decides what stones to replace by using the tags minecraft:base_stone_overworld, minecraft:base_stone_nether, etc for their respective dimension.

Is there any other relevant info about this feature request?

In forge, I think something like creating a TagsProvider and overriding add and andTag methods would be the way to implement this feature. I have no idea off the top of my head to implement this in Fabric.

Mod Compatibility

• This feature cannot be added through the config

ah I see, must of missed this. What are the new versions where this is implemented? Right now I am at 1.18.2 if that matters. With that, this basically closes this issue then.

1.18.2 is out of current development. This will be implemented in the next version of 1.19; I'll leave the issue open till then

An interesting idea. I'll probably implement this once I remove the older of my two world gen systems, that's a bit less reliable. Should be very easy to implement on forge or quilt; see how I do existing tags already. That's why DynAssetGen is for.

Hmm... the issue here is that this doesn't play nice with my stone type system. For instance, nether stones have no idea that they are related to the nether. You could define the stone types arbitrarily. I guess what I'll do is put the stones in an excavated_variants:nether_stones or excavated_variants:stone_stones (or whatever excavated_variants:<id>_stones) tag, and have that added to minecraft:base_stone_overworld by default.

I have been thinking about this too and I realized that the most useful option would be simply tagging stones by their types as per config file and forgetting about adding anything to the "default tags" (such as minecraft:base_stone_overworld as this can be done easily with the use of a datapack).

For example, a modification of the default config of sandstone, we have:

    {
      "block_id": "minecraft:sandstone",
      "types": [
        "stone",
        "beach"
      ],
      "id": "sandstone",
      "en_name": "Sandstone"
    },

If we tagged the stones by type, we have that sandstone has both the tags excavated_variants:stone_stone and excavated_variants:beach_stone.

The practical aspect of this is that a custom ore generation setup might target the minecraft:beach biome and replace ores with the excavated_variants:stone_stones tag or a parent tag with its values. An example of such a parent tag could be minecraft:base_stone_overworld where we append both the excavated_variants:beach_stone and excavated_variants:stone_stone in a datapack.

replace: false,
values: {
    #excavated_variants:beach_stone
    #excavated_variants:stone_stone
}

This is much easier to do than adding every single stone block from the provided stones's in the configs to the same minecraft:base_stone_overworld.json. It also provides the flexibility that most modpacks need.

I hope this makes sense. Is this something special about types in the config that I am not aware of? As I understand it, its arbitrary right (at least in the sense that its meant to just match the stones to existing ores)?

Yes, this was what I was saying. I've already got it implemented for the new version. Types are completely arbitrary, which is why I didn't want to add stuff to the default tags based on types.