Snowcapped is a tool for worldgen developers to easily create overworld-like biome configurations. Datapacks exported have a biome_colors.json file in each namespace's root, which lists the colors used.

It'd be nice if any biomes that do not have a color assigned yet could default to the colors specified in this file. As of right now I have to manually convert the colors. I've written a script to quickly convert the format, but having it built into world preview would save me some time!

@caeruleusDraconis Heads up, the 1.20.5 tag unification PRs for NeoForge and Fabric are going to have c:hidden_from_displayers tag instead of c:hide_on_map to reduce confusion of what the tag is for

FabricMC/fabric#3310

neoforged/NeoForge#135

Hi, creator of Snowcapped here.

I've created the biome_colors.json format as well as a structure_icons.json file mainly for my online datapack map at https://map.jacobsjo.eu [Github Repo]. The export from Snowcapped is just for convenience in creating the biome_colors.json file as you can use a color-picker in Snowcapped.

I've looked at your DataFormats and they don't look too different. A couple questions though:

• why do you need to know if a biome is a cave biome or not?
• why do you need the display name specified seperately rather than relying on the language files where the display name can be set (possibly in multiple languages) anyways?

I think it would make sense to establish a standard for those files. I am also happy to change my format to facilitate things that you need, though there are also a few datapacks (for example Terraltih) that do have these file following my format.

To give some details on the format of these files as I use them currently.

The biome_colors.json is placed directly into the namespace folder and has the following format:

{
    "biome1": { "r": 250, "g": 145, "b": 248 }, // biome color for biome1 in same namespace as biome_colors.json
    "other_namespace:biome2": { "r": 52, "g": 120, "b": 162 }, //biome color for other_namespace:biome2
    //...
}

See here for the data provided for the vanilla biomes.

The structure_icons.json file is also placed directly into the namespace folder and has the following format:

{
    "structure1": {"item": "minecraft:dark_oak_planks"},   //display structure1 using the dark_oak_planks item
    "structure2": {"hidden": true},   //don't display structure2
    "other_namespace:structure3": {"item": "minecraft:carved_pumpkin"},

    //legacy format using simple strings also supported
    "structure4": "minecraft:nether_bricks",
    "structure5": "hidden",

    //...
}

See here for the data provided for vanilla structures. Instead of allowing separate icons, for now I am relying on vanilla items to be used as icons (when only dealing with datapacks you don't really have a place to add textures).

An equivalent to the cave flag for biomes. Could also possibly be an enum / string for a more general biome type.

Maybe a biome tag would work for that, maybe c:is_cave?

A showByDefault flag for structures so that very common structures (such as mineshafts) can be hidden by default. Your hidden flag would work here, if it is possible to also specify an icon / item in your format spec at the same time.

the hidden flag exists for 2 reasons:

1. Some structure types aren't supported by my map. since it is all reimplemented in typescript and some vanilla structure types are rather complicated and not worth the effort to reimplement. So those vanilla structures are hidden.
2. For datapacks to hide internal/technical structures. For example Terralith has (legacy) z_pointer structures to create explorer map leading to specific biomes. Since there is one for each biome Terralith wants to hide them from the map.

So it is really for structures that shouldn't be shown on the map at all. It doesn't quite match your use case. For showByDefault maybe again a tag would work.

So I would propose the following starting from my format:

• For both biomes and structures, allow a optional name field to provide a display name when the mod prefers to not use a language file or datapacks without matching resource packs.
• For biomes allow a color field in addition to r, g, b fields, so people can use whatever they prefer.
• For structures add the option to use a texture field to be used instead of item to directly provide a texture.
• For default structues and cave biomes you can define tags to use (I don't care about those)
• Maybe: Introduce a c:hidden_from_map structure tag instead of the hidden flag.

What do you think?

why do you need to know if a biome is a cave biome or not?

Because world-preview has a feature to highlight all cave biomes :)

why do you need the display name specified seperately rather than relying on the language files where the display name can be set (possibly in multiple languages) anyways?

I do use the the default translations if they are available / use the same mechanism as the vanilla biomes / structures. The name property is meant for mods / data packs that don't ship translations (such as Terralith).

So, this is more an option to add a display name if there is none available and the heuristic for transforming the resources keys is insufficient.

I think it would make sense to establish a standard for those files.

I agree and I would be happy to switch to your format (and deprecate / remove my own) if all the required information would be present in yours.

At a minimum I would need:

• An equivalent to the cave flag for biomes. Could also possibly be an enum / string for a more general biome type.
• A showByDefault flag for structures so that very common structures (such as mineshafts) can be hidden by default. Your hidden flag would work here, if it is possible to also specify an icon / item in your format spec at the same time.

Having a display name for both biomes and structures would be nice to have.

Sounds good to me (mostly).

For showByDefault maybe again a tag would work.

I would go with c:display_by_default then.

For biomes allow a color field in addition to r, g, b fields, so people can use whatever they prefer.

What happens if both a specified? I would only support one format (r, g, b) to avoid such edge cases. My color field is annoying to use anyway, since it is not a hex value and not many tools support a plain integer.

For default structues and cave biomes you can define tags to use (I don't care about those)

Would be nice if you could support them anyway in Snowcapped :)

Maybe: Introduce a c:hidden_from_map structure tag instead of the hidden flag.

I agree, this should be done for consistency.

Something else I missed is that the namespace is optional in your format. I would prefer if this could be deprecated / removed since this behavior seems to be unique to these files. The namespace seems to be always mandatory for all other datapack files as far as I can tell (though I am by no means an expert here).

Additionally, the new / updated format needs an official documentation (something similar to DataFormats.md at least). I couldn't find one easily in either of your GitHub repos.

I would go with c:display_by_default then.

Maybe c:display_on_map_by_default? Might be a bit verbose, but I think its important to specify that this is about (mini-)maps.

Would be nice if you could support them anyway in Snowcapped :)

Snowcapped is only a tool to create biome layouts, similar to the vanilla OverworldBiomeBuilder. So it only cares about biome ids and doesn't even read the biome files. Snowcapped is only part of this discussion as it has a color picker than can export biome colors.

But sure, maybe I'll use c:display[_on_map]_by_default and c:is_cave eventually for my online map.

Something else I missed is that the namespace is optional in your format. I would prefer if this could be deprecated / removed since this behavior seems to be unique to these files. The namespace seems to be always mandatory for all other datapack files as far as I can tell (though I am by no means an expert here).

Sure, that sounds reasonable. The Snowcapped export does include the namespace always anyways. With that maybe it then makes sense to define which namespace to put the file into, like maybe the c namespace. That would make overriding when multiple datapacks/mods define colors for the same biomes easier/less ambiguous. What do you think?

For context: I originally had it where the namespace couldn't be specified, always relying on the namespace of the file. The vanilla analogy to that is the sounds.json file in resource-packs, which is also a json file that is put directly into the namespace folder and which infers the namespace from the namespace from the file. I then added the option to specify a namespace so that datapacks would only need to include one file.

Additionally, the new / updated format needs an official documentation (something similar to DataFormats.md at least). I couldn't find one easily in either of your GitHub repos.

I'll work on a proper documentation soon.

Maybe c:display_on_map_by_default? Might be a bit verbose, but I think its important to specify that this is about (mini-)maps.

Sure, makes sense.

With that maybe it then makes sense to define which namespace to put the file into, like maybe the c namespace.

So, basically the color / structure resources would be in c/worldgen/biome_colors.json / c/worldgen/structure_icons.json instead? Or arbitrary files in a c/worldgen/biome_colors / c/worldgen/structure_icons directory (this is basically how I am currently handling it, but with arbitrary namespaces instead of "just" c)?

I am not an expert on data packs, so what would the expected behavior be when more then one data pack provides the same file (overwrite complete file / only duplicate keys)?

I am not an expert on data packs, so what would the expected behavior be when more then one data pack provides the same file (overwrite complete file / only duplicate keys)?

Thats sort of the issue with these files. Usually it would override the complete file. That is obviously not great for these files. The vanilla analog is the sounds.json file, that has a special case where it only overrides the duplicate keys. So I copied that behavior for the biome_colors.json file.

So as long as its is just a single file the overriding per key is well defined, one pack just overrides the color defined in the lower packs. The problem I see is if packs define a color for the same biome, but in different files (i.e. in different namespaces), or even worse if a single datapack defines 2 different colors for the same biome in different files.

That's why I would propose to simply have single place where to put the file, then the overriding is easy. I think it makes sense to put it in the worldgen subfolder, so c/worldgen/biome_colors.json and c/worldgen/structure_icons.json would be my choice.

I don't know how easy it is to get the overriding per key to work in a mod, I have the luxury of having implemented my own datapack loading, so haven't though much about the feasibility of this in a modded scenario. Maybe you should see if you can get that to work before we decide on a final format.

OK, I did some testing (poking around in the sound manager implementation), and using the c namespace is possible.

The problem I see is if packs define a color for the same biome, but in different files (i.e. in different namespaces), or even worse if a single datapack defines 2 different colors for the same biome in different files.

Yes, this is annoying to deal with... I will have the problem anyway, since I want to support your the old formats. So, I would say that this would be undefined behavior in this case...

I have implemented an initial version based on the discussion here. The new resources files can be found in https://github.com/caeruleusDraconis/world-preview/tree/1.20/src/main/resources/data/c

There is also a converter for automatically converting to the new format.

The only thing that currently isn't working is rendering the items on the map, because all the builtin minecraft item rendering logic directly renders to the screen, while world-preview renders everything to a texture first.

However, this is not a problem with the format itself, but with the use of items as icons...

So to recap that we are on the same page, the final format spec would be:

Biome colors:

One file per mod / datapack in c/worldgen/biome_colors.json:

{
  "minecraft:beach": {
    "r": 244,
    "g": 238,
    "b": 5
  },
  "minecraft:snowy_beach": {
    "r": 249,
    "g": 255,
    "b": 150,
    "name": "Snowy Beach" // Optional name field
  }
}

Additionally, c/tags/worldgen/biome/caves.json can be used to indicate that a biome is a cave biome. Vanilla example:

{
  "replace": false,
  "values": [
    "minecraft:dripstone_caves",
    "minecraft:lush_caves",
    "minecraft:deep_dark"
  ]
}

Structure icons

One file per mod / datapack in c/worldgen/structure_icons.json:

{
  "minecraft:ruined_portal": {
    // Texture icon for this structure
    "texture": "world_preview:textures/structure/ruined_portal.png"
  },
  "minecraft:ruined_portal_desert": {
    "texture": "world_preview:textures/structure/ruined_portal.png",
    "name": "Desert Ruined Portal" // Optional name field
  },
  "minecraft:stronghold": {
    // Specify an item instead of a texture
    "item": "minecraft:ender_eye"
  },
  "minecraft:stronghold": {
    // Specify a texture and an item fallback icon
    "texture": "world_preview:textures/structure/chest.png",
    "item": "minecraft:chest"
  },
}

Additionally, c/tags/worldgen/structure/display_on_map_by_default.json can be used to indicate that a structure should be visible by default on a (mini)map. Vanilla example:

{
  "replace": false,
  "values": [
    "minecraft:swamp_hut",
    "minecraft:ancient_city",
    "minecraft:jungle_pyramid",
    "minecraft:monument",
    "minecraft:mansion",
    "minecraft:pillager_outpost",
    "minecraft:trail_ruins",
    "minecraft:end_city",
    "minecraft:desert_pyramid",
    "minecraft:stronghold",
    "minecraft:igloo",
    "minecraft:fortress",
    "minecraft:bastion_remnant",
    "minecraft:village_plains",
    "minecraft:village_desert",
    "minecraft:village_savanna",
    "minecraft:village_snowy",
    "minecraft:village_taiga"
  ]
}

Ideally, there would then also be a c/tags/worldgen/structure/hide_on_map.json tag to indicate that a structure is a technical detail and should never be rendered.

Does this sound ok / what you had in mind?

That looks perfect! I'll work on implementing that into my tools very soon.

One useful addition might be to allow both a texture and item field for the same structure, so you can specify an item fallback then the texture isn't available (i.e. because it is in an optional resource pack)

Regaring the cave tag: It seems the convention is c:caves (see https://github.com/FabricMC/fabric/blob/1.19.2/fabric-convention-tags-v1/src/generated/resources/data/c/tags/worldgen/biome/caves.json) and forge:is_cave (https://github.com/MinecraftForge/MinecraftForge/blob/1.19.x/src/generated/resources/data/forge/tags/worldgen/biome/is_cave.json) so I guess you should use those.

One useful addition might be to allow both a texture and item

That's basically how I have implemented it already. I will update my previous comment to make things clearer.

Regaring the cave tag: It seems the convention is c:caves

Thanks for catching that. I have updated the my previous comment and the code to use the existing tags instead.

I have now implemented the changes into my datapack map, with the exception of texture field, as I don't have any resource-pack loading logic as of now, and ignoring the name fields as I have just displayed ids anyways. (The old format still works for comparability.)

Snowcapped is now also exporting into the new place, otherwise no changes were necessary.

Closing, since the new format changes are now released with version 1.1.0.

@jacobsjo Please let me know, once you have some official documentation for the new / updated data-format.

@caeruleusDraconis I now have written the documentaion at https://github.com/jacobsjo/mc-datapack-map/wiki/Biome-and-Structure-Metadata. If should give datapack/mod makers enough guidance to make their datpacks/mods compatible. Let me know if you have any complaints.