[MC-36639] Zoomed out maps do not properly align.

When zooming out with a map, maps do not align properly to the grid and thus cannot be linked together in item frames to create large scale world maps. This may be due to maps now being created as player-centric rather than relative to the map grid.

To replicate this issue take two maps generate one at the default zoom, then use paper to craft a zoomed out version of the first map.

Go just past the edge of your now zoomed out first map and generate a second map at the default zoom. Craft a zoomed out version of your second map and observe that it is created with many areas overlapping on the two zoomed out maps.

The image shows the issue. The top two maps show the default zoom and the maps align properly. The bottom two show that when zoomed out maps do not align to the grid properly. The bottom two maps were generated as described above. As you can see there is overlap in the bottom two maps where there should not be.

Linked issues

relates to 1

MC-64909 New maps not centered on the player Resolved

Attachments

Comments 21

Ben W 2013-10-24T01:57:53Z

Maps align to the same grid on all zoom levels. A 1:1 scale map is 128 blocks across. So if you're at 1:2 zoom, you need to go 256 blocks away in order for the maps to align correctly.

Jeremy 2013-10-24T07:32:00Z

That's true, however, it still seems like a bug to me since without proper alignment at high zoom level players are forced to manually count blocks in order to get zoomed out maps to align. It seems like this is an unintended issue since this does not occur at the default zoom level.

At worst this could be reclassified as an improvement because this issue severely affects mapping of large areas.

Robert Kovach 2013-11-06T15:15:42Z

Because zoomed out maps do not behave as 1:1 maps, it appears to be a bug.

While it may be working as intended, it is very inconvenient to count blocks so the zoomed map is created at the proper location. What if the correct location to create a new zoomed map is in the middle of the ocean?

Also consider how long it physically takes to map a 2k x 2k map. These maps should automatically align to neighbors just like 1:1 maps.

Maps at each zoom level should be created on their own grids, so they snap together automatically.

Thanks for reading.

Torabi 2013-11-11T14:39:12Z

I do see one issue with making zoomed out maps conform to a grid: some adjacent 1:1 maps would merge into the same map when they are zoomed out. Currently, they can overlap, but as long as each one is centered on a different grid, they'll never converge, no matter how much they are zoomed out.

Robert Kovach 2013-11-12T00:52:13Z

adjacent 1:1 maps converging into the same zoomed out map is precisely what I see as the intended behavior, this is what would ensure zoomed out maps always align to each other

If I make a 1:1 map at center point 16,0, then move to 128, 64 and make another 1:1 map, I would expect that if both maps are zoomed out to 2k by 2k, that they would be identical maps that cover a range from 2048, 2048, to 0,0 with a center point of 1024, 1024.

11 more comments

Torabi 2013-11-14T15:06:42Z

Then you increase the risk of the player having two maps that display the same area, but do not function as copies of the same map – meaning that they will not share discovered terrain, or the location of other copies (green and white arrows).

Or, if the mapping system is changed to have it actually fold the maps together internally, so that they point to the same information, then all you've accomplished is a more expensive way of mapping out the world. Currently, a player can make two maps in two separate locations, and be pretty confident that they will gain some unique value from each one. There may be some overlap if they haven't efficiently calculated out where to center each one, but they won't have made two maps that display the exact same area unless they intended to.

Aligning maps to a grid assumes a certain amount of "magic", that the map or the character holding it somehow knows where the center point should be in order to conform to the grid. Originally, maps didn't conform to any grid at all, and were centered on the exact block you made them on. That requires the least amount of "magic", but was inconvenient, and so a compromise was made. However, what you're suggesting goes even further, with each map not only conforming to a simple grid, but a grid within a grid, knowing their relative position to other potential maps.

What you're suggesting takes some of the thought out of mapping, and whether that's a good or a bad thing is going to depend on your perspective. However, considering how maps are currently implemented, there's strong reason to believe the current mechanics are not a mistake, and that this is Works As Intended. You might have better luck with the suggestions subreddit or forum.

Robert Kovach 2013-11-14T17:12:27Z

All of your points are valid and reasonable, and I agree it is a matter of perspective. But let me outline a few counterpoints:

1. F3 should never be required to play Minecraft. F3 is for debugging purposes, and relying on the player coordinates is a form of "cheating".
2. even with F3 to count steps, it is still very difficult to create two 2k by 2k maps that snap together (i still somehow ended with a 32 block discrepency).
3. two maps that cover the same area but are not copies of each other doesn't seem like a problem to me. this will happen as each player creates and manages their own 1:1 maps.
4. When 1:1 maps snap together flawlessly, it is odd that two 2:2 maps will not snap together unless they are created with the proper centers. This inconsistency is working as intended, but is not easily understood.
5. Each map size would only conform to one grid. For every 2k by 2k region there is only 1 valid map, much like for every 128x128 blocks there is only 1 valid map.

Thanks for reading and your consideration.

Jeremy 2013-11-26T05:59:57Z

This issue still persists in 13w48a.

Jeremy 2013-12-07T07:13:31Z

Still an issue in the 1.7.3 Pre-release.

Ad Verhoeven 2013-12-16T02:19:32Z

this is a feature, you should indeed just count blocks by writing down the coordinates of the first map you made and then walk a lot

Deleted account 2014-02-28T11:52:43Z

Is this still a concern in the current Minecraft version 1.7.5 / Launcher version 1.3.9 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Jeremy 2014-03-01T09:20:08Z

Updated ticket. Affect versions include Minecraft 1.7.5 and all the 1.8 snapshots thus far.

Deleted account 2014-04-30T17:13:45Z

Is this still a concern in the current Minecraft version 14w18b / Launcher version 1.3.11 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Jeremy 2014-05-02T20:50:27Z

This is still an issue in 1.7.9 and launcher version 1.3.11.

Ad Verhoeven 2014-06-03T11:05:09Z

It is in fact still a feature. you should just look for the amount of blocks a player needs to walk in order to get the alignment right.

this means that it will be 128 * 2^(zoom) starting at zoom 0. keep z or x the same, and walk that distance over the other horizontal axis untill you have added exactly 128 * 2^(zoom)

The fact that the map is player centric is actually a good thing, since you can achieve whatever you wont. Creating giant maps will be more difficult, but you can have a huge map of the area surrounding your house/town/castle without having to build your entire castle on a special spot.

shufboyardee 2014-06-03T14:12:46Z

As Ad Verhoeven says, this isn't a bug. Maps keep their center regardless of scale. So, to align bigger maps, the centers of the maps just need to be further apart than if they were smaller maps. I've had no problem creating huge wall maps, it's just a matter of knowing where the map-centers are, for the scale you want.

Jeremy 2014-06-06T09:03:10Z

Upon reading the previous few user responses, I am now regarding this as an intended feature. If a mod could close this ticket it would be appreciated.

Tokes 2014-07-30T21:25:38Z

Wow not one of you pointed out the fact that they DON'T line up under any circumstance. There's missing pixels on each side on every zoom level past 0. Hidden under the graphics of the map boarder I think.

SuburbSomeone (lastname) 2014-08-09T00:45:12Z

I am appalled at Grum for changing this. This feature was intended and the "fix" is ruining maps. Come on, MC-64909 has 14 votes in about 10 days, and MC-36639 just 4 in over half a year. If that doesn't prove this feature was intended, I don't know what does. And also, Jeremy SPECIFICALLY ASKED for this report to be closed. I know it's tiring to do all these fixes, but just looking at the comments first can save you from fixing something that worked as intended. As the old saying goes, "If it ain't broke, don't fix it." Please, just change it back. If this makes it into 1.8, I expect widespread complaints. I might wait for 1.8.1 for my private Bukkit server just because of this (though the banners and prismarine will probably make me get a 1.8.0 Bukkit anyway).

Torabi 2014-08-09T01:36:26Z

Only the developers can decide what's intended. The number of votes on a particular issue is irrelevant. That said, I preferred the old behavior, because it was less magical, and allowed the player to decide the center point of the map. But the developers determined that it wasn't desirable, because aligning maps required careful calculation or the debug screen, which is not intended for player use.

SullyTheUnusual 2014-08-09T21:17:58Z

I prefer this method over the old method, with the one caveat that it would be nice to have maps centered on a location.

It would have been nice to know the functionality was changed, however. I was about to open a (yet another) bug report on the issue before I searched through and found this. Fixing a bug doesn't necessarily warrant mention in the release notes, unless it completely changes how a game mechanic works. Thumbs up for the changes, thumbs down for explaining them.