/locate does not always locate the nearest structure

Does it happens in other worlds? Have you tried other villages(maybe the one where you are its not a valid village for some reason)

Loaded up a new world to try to reproduce the glitch, and I realized my steps to reproduce were not reliable. I did reproduce this bug using 2 valid ocean ruin structures that could be detected by commands, and I did /locate in various places and confirmed that /locate does not always locate the nearest structure unlike in 1.13.2. I edited this report accordingly, redid my steps to reproduce, and tested them, so now they should be completely reliable.

I reported the same bug MCPE-45526 for Bedrock Edition (and that bug has been confirmed). I found examples of /locate failing to find the nearest structure (a stronghold and two monuments) even when I was right on top of it. This bug isn't just in Java Edition.

Here's my steps of reproduction:

1. Use seed -5541185355023925660 and go to exactly
/tp -5831 66 -4607. You might find yourself inside a tree.

2. /locate Desert_Pyramid, it's 241m away.

3. Go 1m north. You should pass through a chunk border doing this.

4. /locate Desert_Pyramid, it's 1060m away!

The locate command doesn't locate the nearest structure because the locate command works on Anvil regions and it stops searching when a structure is found. The Anvil file format saves worlds in region files containing 512×512 blocks. The region is used as a base for generating structures, for example, there can be no more than one village per region, one temple, one ocean monument, one ruined nether portal, one desert well, one witch hut, etc. Other structures have different rules: they could be more common (shipwrecks and ocean ruins can occur multiple times per chunk) or rarer (woodland mansions).

The effect of regions can be seen when steps to reproduce posted by @Paint are analysed. The coordinates given are -5831 66 -4607. Mod 512, x and z are: 313, 1. When the player moves 1m north, the player is crossing a chunk boundary that is also on a region boundary. When crossing a region boundary in this way, the locate command would search a different region for the requested structure, but it searches only one region.

The effect of regions can be seen clearly when looking for ruined Nether portals in the 20w16a snapshot. These occur once per region in the Overworld, in most or all biomes. If one occurs near the edge of a region, crossing a region can cause a nearby ruined portal to be ignored while a farther one is found instead.

If greater accuracy is required, the locate command should be modified so it searches additional neighbouring regions as well as the current region. It should search an additional region on both sides. The command already searches multiple regions, such as when suitable locations for that structure are not nearby. It should add one extra search region on both sides even if the structure is found. This won't guarantee the closest structure will always be found (eg: the nearest edge of villages), but it will prevent obviously wrong results such as the one that Paint demonstrated.

Affects 1.19-pre1.

I recently noticed this bug myself in Minecraft 1.19. There were two woodland mansions close to spawn on my world, which I found both via the /locate command. With the second mansion I located with the command, I noticed that according to my coordinates, the first one I located was actually slightly less far away from my position than the second one I located, which was really confusing.

Can confirm in 1.20.5. Also duplicated by MC-271211.

This problem is due to early returns in two places. I’m using the official mapping for 1.21.2.

First, in ChunkGenerator#locateStructure, and second, in ChunkGenerator#locateRandomSpreadStructure. RandomSpreadStructurePlacement#getStartChunk performs a floor division, which causes searches to be aligned to a square grid with side length equal to the spacing. However, a structure located in a closer block on that grid doesn’t mean it is actually closer in distance — this leads to the first early return in locateStructure. In locateRandomSpreadStructure, it simply returns the first block on the grid that contains the desired structure, but it should actually search the entire edge.

The mechanism behind this bug (and its duplicates MC-248797, MC-239836) is visible in ChunkGenerator (Mojang mappings, 26.1.2, unchanged in 26.2). Three independent causes:

1. First hit wins inside a ring. getNearestGeneratedStructure for random-spread placements walks each Chebyshev ring of placement regions in x-then-z raster order and returns the first structure it finds. It never compares distances between members of the same ring, so the answer is the most north-west hit in the ring, not the nearest. This is the direct cause of the quadrant dependence reported in MC-248797.

2. The radius loop stops at the first radius that finds anything. In findNearestMapStructure, a hit at radius R returns immediately. A ring at radius R spans real distances from roughly (R-1) x spacing x 16 to 1.41 x (R+1) x spacing x 16 blocks, so ring R+1 regularly contains nearer structures than the one returned from ring R.

3. Radius is counted in each placement's own spacing. When a tag spans placements with different spacing values, "radius 3" is a different real distance for each placement, and the shared loop returns the first placement to hit. This is the tag case. The concentric-rings path (strongholds) does compare exhaustively by distance, so strongholds are not affected.

Reproduction, vanilla only, calculator only. Seed 20260821, default world gen, any version from 1.19 through 26.2 (verified on 26.1.2):

/execute positioned 8000 100 0 run locate structure minecraft:jungle_pyramid

Returns [4320, ~, -3024], reported as 4763 blocks away.

/execute positioned 12300 100 1400 run locate structure minecraft:jungle_pyramid

Returns [12336, ~, 1392], which proves that structure exists. Its distance from the first position (8000, 0) is sqrt(4336^2 + 1392^2) = 4554 blocks - 209 blocks nearer than the structure the command returned.

Second instance on the same seed: from positioned -5000 100 -5000 the command returns [-688, ~, -8928] (5833 blocks), while [-8144, ~, -144] (provable the same way from positioned -8100 100 -100) is 5785 blocks away.

Cause 1 alone has a one-line-scale fix: collect all hits in the current ring and return the minimum instead of the first. Causes 2 and 3 need the loop to continue until the next ring's minimum possible distance exceeds the best hit so far.

That fix shape is not hypothetical: I have it running as a Fabric mod that routes findNearestMapStructure through an exact-distance-order enumeration of the same placement candidates, verified with vanilla's own presence checks. At both positions above it returns the provably nearer structure while agreeing with vanilla's checks at every candidate. Source (also how these coordinates were found): https://github.com/RasmusKD/locate-more