The bug
In 1.18/1.19 structure generation was rewritten changing around IDs and more. The explorer_map function in loot tables doesn't seem to be updated with these changes, causing any structure ID input to not function. It instead only takes structure tags, but no # to signal it's a tag. (eg "village" is valid because of "#village".) This is inconsistent with every other place that references tags, as they either use the field key "tag" or precede the value with #.
This loot table should locate a desert village, and put it on a map, but just ends up providing an empty map instead, as there's no structure tag called "minecraft:village_desert".
{
"pools": [
{
"rolls": 1,
"entries": [
{
"type": "minecraft:item",
"name": "minecraft:map",
"functions": [
{
"function": "minecraft:exploration_map",
"destination": "minecraft:village_desert",
"decoration": "mansion",
"zoom": 1,
"skip_existing_chunks": false
}
]
}
]
}
]
}Expected is that either a # is required (like dimension types' infiniburn field), or the "destination" field follows the format used in other placed
"destination": "structure_id",
"destination": ["list", "of", "ids"],
"destination": "#structure_tag"
Original description
Custom structure support, added in 1.18.2, didnt update the function "explorer_map" "destination" field for loot tables. It relies on the old /locate system it seems because like that system it first of all, doesnt need a namespace, and second of all if you for example input "village" it will just select the nearest village, exactly like the old system. "/locate village" is outdated with the /locate command since it has been split up, into one command for each biome specific village.
If you input a structure that wasnt part of the old /locate system, the loot table will just give an unfilled, normal map.
Comments 7
I'd like to request this report to be rewritten:
Title: Loot tables' explorer_map function not functional with non-default destination input
Description:
In 1.18/1.19 structure generation was rewritten changing around IDs and more. The explorer_map function in loot tables doesn't seem to be updated with these changes, causing any structure ID input to not function. It instead only takes structure tags, but no # to signal it's a tag. (eg "village" is valid because of "#village")
This loot table should locate a desert village, and put it on a map, but just ends up providing an empty map instead.
{
"pools": [
{
"rolls": 1,
"entries": [
{
"type": "minecraft:item",
"name": "minecraft:map",
"functions": [
{
"function": "minecraft:exploration_map",
"destination": "minecraft:village_desert",
"decoration": "mansion",
"zoom": 1,
"skip_existing_chunks": false
}
]
}
]
}
]
}I’m so glad I found these reports! I finally got around to testing and you’re right! The “destination” must be a tag without a # (which seems to not follow how tags work elsewhere). But that’s not all I learned! I’ve found a workaround for targeting a specific structure not included in a vanilla tag! Create a custom tag in your datapack and include whatever structures you want in this new tag. Then, have the map look for the custom tag! I’ve now got a map that leads to the nearest ancient city!
(if it seems I’m excited, I am. When I first started looking into this, couldn’t get it to work, and saw these bug reports, I thought an idea I had for a datapack was basically impossible. However, this puts it back in the realm of possibilities! Even if it’s a bit more complex/tedious than expected.)
If this truly is intended design, I highly suggest changing the design; this is the only field in the entire game that requires using a tag, that doesn't signal it's a tag; the infiniburn field in dimension types also only accepts tags (the only other one), but requires the # indicating it isa tag. While not optimal, it is a lot more clear to the user that creates the file that it is a tag. Other fields either accept tags, an ID or list of IDs, in those cases the field changes format entirely, again, unlike here.
This is highly inconsistent with everything else. If it's intentional design, I seriously suggest changing the design.
Affects 1.20.2 and 23w42a.
Requesting ownership too, as reporter did nothing except make this report.
Sounds like the cause for MC-218156.