New maps not centered on the player

Confirmed. And if this is what is now intended as one above poster indicates I have wasted many hours mapping... All my maps are based of centering the initial one at 0,0, then the center of the next (at my 1:8 ratio) is 1024 blocks away. This was simple enough for people to handle.
I guess if this is intended it does make map making marginally faster without having to go the center for creating, but damn.. why was something official not said before hand... C'mon guys, changing something like this after 9 months...??? geez.

This is not working as intended. If it was, it would be said that a change has been made in one of the snapshots. Before this problem, when you create the map, it always stayed center (except for the 1st zoom I think). So if you created it in your base let's say, each zoom out kept your base in the center of the map. Now, your base moves to who knows where depending on the global coordinates as you zoom. You will never be able to map anything and keep center. That is ridiculous. This is bugged. PERIOD.

I can confirm for 14w31a. The centering is broken as of this snapshot. No matter what coordinates are used, the map will always start in the upper left hand corner. Creating a map in 14w30c at the exact same coordinates will yield a centered map.

It is busted. I align all of my maps using the debug coordinates, and it is only in this snapshot that I've witnessed such behavior.

Confirmed in 14w32a. It might be that this works as intended, but please reconsider this. Small servers might have everything worthwhile built around spawn, couple of kiloblocks away at most, so with a single map that was centered on spawn one could have most of the busy area covered.

This bug is a result from the "fixing" of this "bug" MC-36639

Only THAT wasn't a bug... The player made a zoom0 map first (rightclicking directly after crafting a map) instead of making a zoom 3 (rightclicking after crafting a map, then zooming out times)

Bug 36639 was never supposed to be confirmed by Grum.

Wiki article about it:

"Following the Pretty Scary Update, zoom-level 0 maps will not overlap—they are created with each center 128 blocks from each other center. Since the center-most map has an origin of 0,y,0, each zoom-level 0 map has an x-coordinate and z-coordinate which are each a multiple of 128. All maps created within 64 blocks of a particular pre-defined center will be identical.

Overlapping zoom-level 1 maps
Higher zoom-level maps can overlap one another because they can be crafted from zoom-level 0 maps that are centered only 128 blocks from each other. A zoom-level 1 map, for example, covers 256×256 blocks. So if you create a zoom-level 1 map from a zoom-level 0 map centered on (128,y,128)--which would cover a square bounded by the points (64,y,64)(192,y,64)(192,y,192)(64,y,192)the zoom-level 1 map will cover a square bounded by the points (0,y,0)(256,y,0)(256,y,256)(0,y,256). The zoom-level 0 map adjacent (to the east) would be centered at (256,y,128) and described by the four points (192,y,64)(320,y,64)(320,y,192)(192,y,192). A zoom-level 1 map crafted from this second zoom-level 0 map would be described by the points (128,y,0)(384,y,0)(384,y,256)(128,y,256). The left half of this second zoom-level 1 map will overlap the right half of the first zoom-level 1 map. The illustration on the right may help.

To keep zoom-level 1 maps from overlapping, ensure that each is built from a zoom-level zero with x- and z-coordinates that are multiples of 256. To keep zoom-level 2 maps from overlapping, build them from zoom-level 0 maps with x/z coordinates that are multiples of 512. Zoom-level 3 maps should only be crafted from zoom-level 0 maps centered on x/z coordinates that are multiples of 1024; and zoom-level 4 maps should be crafted from zoom-level 0 maps with x/z coordinates that are multiples of 2048.

Tip: Mark the center of maps by placing a sign labeled it with the map number, and light it up or mark it in some way so that it's easier to find again. Additionally, craft a duplicate map and place it in a frame at that spot. The map (or its duplicate) will display with a green pointer shown at the location of the item frame.

Tip: Surface lava pools make good landmarks as they show up as red dots on zoomed-out maps. The higher the zoom-level, however, the larger the pool must be before it shows up. You can, of course, make your own lava pool, just be sure it is open to the sky. To be safe, you can cover the lava pools with glass to keep players, mobs, and drops from falling in.
"

Not sure if these recent posts are building cases to say this is not a bug or perhaps its what Mojang intended. I can't see how it is intended or good behavior. I analyzed exactly what is happening.

When you fist create a map, the upper-left corner is set to the largest multiple of 64, less than your current coordinates. I believe that is how it always worked and I don't think this is bugged.

What is bugged is when you zoom the map. Since 14w31a, the upper-left corner stays FIXED as you zoom. So the result is a map zooming down and to the right by the number of blocks for the zoom (128 for the 1st zoom, 256 for the 2nd, etc...) but not zooming at all up or left. The map zooms out shifting down and to the right for each zoom.

What it used to do before this bug is zoom the same amount in all directions relative to the current upper-left corner. So the 1st zoom would result in a map range 64 blocks up, 64 down, 64 right and 64 left. The map zoomed out centered.

They really need to fix this. It doesn't matter where you start the map, it will always zoom out broken like this now.

Well, what's happening is that Grum fixed a bug (36639) but created this one in the process. We need to have both: proper aligning AND proper centering. This was the case in 30a, although a bit tedious. But now a part of the map functionality is gone. I don't think Grum intended for this to happen.

Confirmed.
Also, my report MC-66091 is a duplicate. Someone should get to that so we can unite our votes under one thread.

It's not in 14w32c/d, so it would be useful if you could change the versions affected LuMo25.

Maps are now aligned on a universal grid, so that maps at the same zoom level either overlap entirely, or don't overlap at all. This is to make it easier to map out a large area efficiently, particularly for use with item frames, without needing to use the debug screen to find coordinates. The debug screen is not intended for players to use.

The current behavior is indeed a result of the fix for MC-36639, and likely Works As Intended. However, it does prevent the player from choosing the center of their map, and hopefully some kind of compromise can be made that will preserve player choice, while also making maps easier to align.

That explanation makes no sense with the behavior I've experienced.

Creating a map at [5,6,7] will start out in the upper left corner just like how creating a map at [2045, 6, 2046] will start out in the upper left corner. It doesn't matter where the map is created, it will always start off-center. If it was done according to universal gridding, they'd still be off-center, but in different places. In all of my tests, it without fail starts in the upper-left corner, regardless of location.

And also, if the debug screen isn't intended for player use, I sincerely hope the devs add a way to record landmarks like cavern entrances with precision, because as is, that's the only way I can adequately catalog and record cavern locations. Adding a column of something to an entrance only merely tells me that something is there, it doesn't allow for going back to that location from long distances because the maps allow for no marking of such things. So I put down the coordinates in a text file and use them for future reference.

Alright, so I literally created a new world, used commands to give myself a blank map and paper, and without moving from my spawn point, created the map and zoomed it out. Still in upper-left-hand corner. If this was according to a universal gridding system, wouldn't it be centered at the world's spawn point, and if so, why is it not?

http://i.imgur.com/jEfdQLJ.png

Same world, literally at 0, 70, 0. Still in upper-left-hand corner. Again...if universal gridding, what arcane logic is being used for the starting point of this system?

http://i.imgur.com/008VksN.png

I created a map close to (441, 71, 31), and it's not in the upper-left corner, though it is close. I created another at (424, 72, -110), and it's close to the lower-left corner. It appears to me that maps touch at the origin (0, 0), rather than any map being centered on the origin. Try creating a map at 900 ~ -1000. That should create a map with the center close to the point of creation.

After thinking about it, this works EDIT: partially as intended, but IMO the center of all the maps should be (0, x, 0), not the spawn point as it appears to be located. This could help those who center their worlds at (0,x,0), which seems to be many people/servers, even if the average Joe might not ever use the debug screen. Unless, of course, you change the spawn to (0,x,0). But if the center of the map world is fixed to the original spawn a random point no matter what, then this should absolutely be changed.

As it is currently, maps never cross the coordinate axis. This strikes me as the cleanest implementation, though it does mean that the area around the origin, which the spawn point is usually located near, does not fit on any one map. But it does neatly divide the Minecraft world into quadrants, and makes calculating the location of each section of the grid relatively easy. Maps at max zoom cover 2048m×2048m, and you can easily determine where each map would be, relative to the origin. If one map was centered on the origin, then each map would be offset by 1024m from the origin. So 1024m out along an axis, you'd be at a new map segment, but the next one (and each after that) would be an additional 2048m out.

I'm still in favor of being able to create maps centered at any particular point, for aesthetic purposes. Perhaps there could be a crafting recipe to pin a map to a certain point?

@Torabi What you are saying is not holding true. After further testing I find what I posted above, where I say the upper-left corner stays fixed is not true either. I don't know what the behavior is. It seems almost random and random = broken. I also think we need to not consider the world origin, (0,0) unless somehow that is truly part of the calculation. You can make a map anywhere, even greater than 2048 blocks away from (0,0). What then? The rules should apply the same anywhere in the game world.

The only true steadfast rules I can still confirm are the following:
1) The upper-left corner of the map snaps to the closest multiple of 64 from where you created it.
2) Every subsequent zoom-out remains a multiple of 64. But ONLY 64. The map is not snapping to higher multiples as it zooms.

Rule 2 invalidates the concept of a global alignment. A full zoomed out map is 2048x2048 blocks. If the intent is to global align, then the upper-left corner at full zoom should be a multiple of 2048 right? Its not, its 64.

I'd like someone to try this test in their world. Here is what happened in mine:
Z0) I created a map at: (-1206, -770). The upper-left corner (UL) snapped to: (-1216, -832), closest multiple of 64. Divide these cords by 64 and its: (-19, -33)
Z1) Upper-left went to: (-1344, -822). Divide by 64: (-21, -33)
Z2) UL went to: (-1600, -1088), Div. by 64: (-25, -17)
Z3) UL went to: (-2112, -10878). Div by 64: (-33, -17)
Z4, final zoom): UL went to: (-2112, -2112), Div by 64: (-33, -33). Is 2112 even a multiple of the next zoom, 128? NO, its not.

What the heck is doing????????? It is going all over the place. Looking at easier number, the div-by-64, this is what it did:
(-19, -13)... (-21, -13)...(-25, -17)...(-33, -17)...(-33, -33)

Either the rules are so complicated they are stupid, or a better answer: It's bugged.

@Torabi, assuming this change in map behavior is intentional (as you describe), it represents a philosophical change in the concept of maps in Minecraft. One of the beauties of Minecraft is that every individual can play the game in a different way, suited to their own interests. For those who like to explore large areas and stitch maps together, the new behavior will be regarded as a good thing. It will substantially reduce the effort required to get separate maps to line up with each other. For the rest of us for whom maps are primarily about mapping the area around where we live, it forces us to choose a location for our domicile that has a particular orientation to the invisible coordinate system. (Keep in mind that the grid coordinates are only visible if you either have a mod installed or use the "diagnostic" HUD.)

I personally don't like the new philosophy, though I think I understand it and recognize that there are those who will like it. Maps no longer work in an intuitive fashion aligned with the "primitive" character of stone picks and shovels. Instead they act more like satellite images managed by NSA computers.

Has this new philosophy of maps been vetted against the Minecraft vision?

The original behaviour, from 14w30c and older, is consistent with the crafting recipe for zooming out maps, and is well understood by the community. I vote for reverting back to that, OR to change the recipe for zooming, to one map and three papers in a square, where the position of the papers in relation to the map indicate in what direction it should be zoomed out.

Adam, you are really overcomplicating things. It works the same as zoom 0 maps now. Zoom 0 maps are aligned to a grid, zoom 2, 3 and 4 are as well. If let's say your base is standing at the top left corner of the grid, and make e.g. a zoom 3 map there, the area covered will only show the top left corner.
If you would go to the middle of the grid and make a zoom 3 map there, the area covered will be the middle. Your base will still be in the top left corner if you would travel there with your map in hand.

@Arjan De Vries: I am not overcomplicating anything. Your comment made me go back and look again. It is doing EXACTLY what I posted. Do the test I posted and tell me what the behavior is. If it is different, post it.

What you are saying is not happening in any consistent, reliable way. I did another map starting at (0,0). The behavior there is a FIXED (-64, -64) upper-left corner. As you zoom it goes down and to the right. What grid-alignment is that other than 64? It stays at -64 and therefore fails the very next zoom-out multiple, 128. If what you are saying is true, shouldn't it be snapping to -128?

I don't really understand what your problem is with the numbers, but I'll try something:

-Opened a new world
-Created a zoom 0 map at 0,0,
-Went to the UL corner. UL is at -64, -64
-Zoomed out from here
-Zoom 1 UL is still at -64, -64
-Zoom 2 UL is still at -64, -64
-Same with zoom 3 and zoom 4...

The upper left corner of the zoom 0 map stays the upper left corner of a zoom 4 map.
If I were standing at coordinates 0,0, or 30, 50, and zoomed out from there I would still get the exact same zoom 4 map, if I would stand at -65, -65 however, I would get a totally different zoom 4 map, without any overlap, as it should be.
Try making a map wall of 4 zoom 1 or 2 maps, it's very easy now.

So no problem there. The main problem is that the old map generation is gone, where you stand will be the middle of the map. If you wanted to align four let's say zoom 3 maps in 14w30c, you had to do some calculating work to account for the overlapping of maps

Just deleted an old comment of mine that seems to have incorrect information.

30c and before had hard to do alligning on higher zoom levels and also had proper centering
Grum fixed MC-66091, which stated that alligning on higher zoom levels didn't work (it did, it was just harder to do, needing some calculating work with coördinates)
By fixing that "bug", the centering feature was sacrificed for easier alligning.

Too bad, but after reviewing things again it appears to be working as intended. So this report is just a suggestion for a revert or, like Torabi said, make a new crafting recipe.
So, yeah... working as intended after all.

I am trying as hard as I can to believe that it is working the way you and Torabi are saying. I cannot.

What I did in this last test is completely blow away my ".minecraft" folder. I downloaded 14w32d clean and created a brand new map. I then did my test again, the test I asked you to do and I am not reading that you did it.

Teleport to: (-1206, Y, -770). Y=whatever, who cares
Start zooming the map out. It did the EXACT same thing I posted, on this new world, clean build.

In your last post you gave me test numbers based on origin 0,0. I agree. It is consistent in how it zooms. Its FIXED upper-left. That is not my point and that problem.

Do my test, Arjan. Until you do, I cannot believe you. I challenge anyone to do my test and tell me what you get.

I don't really know what the problem is, still. I'll do your test.

Telported to your coordinates
,made a Z0 map
Went to the upperleft corner (your coordinates for UL are right)
Made a zoom 1 map. Yeah, the UL corner moved. The old UL corner of zoom 0, moved to the upper middle of the zoom 1 map.
And it will move at later zooms as well. probably (haven't tested)

Well, it does make perfect sense to me. I said the UL corner was at the same spot for coords 0,0 as your starting point.
Imagine a grid of zoom 1 maps. Each of the individual squares of the zoom 1 grid consists of 4 zoom 0 squares. So the UL corner of a zoom 0 map, may very well be the upper middle in a zoom 1 map (the upper middle is still the upper left corner of the upper RIGHT zoom 0 map).

Does this solve it for you or did I understand the problem wrong?

So in your test, did you get a zoom-1 upper-left coordinate of (-1344, -832)? I hope you did then it is at least doing the same thing as mine.

So I thought of a great idea. I graphed what this doing when I started at (-1216, -770). each square in the graph is 64x64 blocks. The axis coordinates are the values divided-by-64. Look at how it is zooming out all over the place. It zooms left, then up and left, then left again, then up. File attached, n1216_n832.jpg

Looking at your graph, you seem to be understanding the situation, so what is the problem? How the zooming works is dependant on in which zoom0 square you stand, there is nothing wrong with it. Look at your zoom0 square for example. In your zoom 1 square fit four zoom 0 squares. If you would stand in another zoom 0 square, you would get a different result (which you can predict by looking at your own graph.

It isn't random, it's just the way the grids corners/borders are set up by the developers. All predetermined.

I agree that this now works as intended, but you have to throw away all your pre-14w31a maps and start fresh or you're going to be really confused.

It would have been really nice to see a few sentences in the release notes explaining the changes, though.

If this is working as intended, what the hell is the logic? This is arcane and illogical, and is pretty much going to ensure that I will not be using maps in the future. How do they line up? How do they zoom out? Why is it that I can never find the center of a map and map out a world logically?

What human being starts a map from anywhere but its center? What human being moves the starting point of a map when the scale changes? It literally makes no practical or logical sense whatsoever.

I agree with SystemReady exactly. I could probably deal with a map that doesn't stay center each zoom, but now we have zooming that goes in different directions depending on the starting point? Its not consistent at all. The zooming is not even snapping to a larger grid. It seems random, zoom left, then up, then up-left. If this is intended and they go live with this, its going to get lit up.

It's not random. I don't like it, but it is not random. I explained it twice now. Are you just ignoring it?

Maybe I should extrapolate - it's not random in the sense of, say, a random number generator, it's random in that it is hilariously impractical and completely goes against what any ordinary person making a map would do.

It's like me doing a lab assignment in Geology that involves a map that covers the state of California at different zoom levels - except that the center points for each zoom is completely different. Any ordinary person would have problems wrapping their head around that implementation, even WITH the explanation. Why make an existing system more difficult?

It is consistent, if you understand how it works. Look at this diagram, and I'll try to explain: http://imgur.com/FZjlmQW

The A represents a zoomed out map area which contains 4 map areas number 1-4 that are not zoomed out. These areas are predetermined by the game (I'm not sure if it's based on the map's spawn point or a set location, haven't looked into that), maps will no longer center on the player. I'm guessing this is to make it easier for people to exchange maps of areas, and to reduce confusion about how to make adjoining maps. When you right-click with a blank map in your hand somewhere in region 3, it will create a map for that region of space, not one centered on you. Now when you zoom that map out one level, you will have a map showing A (all four smaller regions), and you'll be located in the lower left corner (if you're still in region 3 when you zoom it out).

If you haven't mapped the area, then you really don't know where you'll be in the zoomed out map. For example, if you had made a map in region 2 instead of 3, when zooming out you'd be shown in the upper right corner of the A region instead of lower left.

I do like the idea of maps centering on the point you create them, but I understand why they did it this way. It makes sense if you understand that the game has already mapped out the coordinates for each zoom level.

Making maps in a game is a completely different context than your lab assignment, and this way is less confusing and easier to use in my opinion.

But this comes back to the issue of universal gridding - if they're not centered on the initial world spawn and they're not centered on the zeroed coordinates of the coordinate system, what ARE they centered on? I can't make regions and provinces if I don't know what it is I'm mapping, or why I inexplicably can't get my base to be the center of a map.

And I found the old systems of maps hardly confusing. As long as you use one single center point for the entire system, it becomes trivial to make adjoining maps - just add or subtract 2048 from the appropriate coordinate and you have your new location.

To someone who is familiar with the debug screen and how the coordinate system works, yes, it's trivial. But if you want realism, like you pointed out in your lab assignment story, then how can your MC avatar know anything about coordinates without using a tool meant for debugging the game? Does he "see" the coordinate numbers floating in mid air as they're overlaid on your screen?

Are we seriously debating realism in a game where I can carry 32 logs half my size without breaking a sweat? lol

I don't care about realism, I care about practicality and consistency. The largest issues I have with this new system is that:

1.) No one has managed to tell me yet what this gridding system is centered on. As it is, it strikes me as arcane ("black box" - the parts that make it work are obfuscated) and an arbitrary change. If I knew what the center was, I could change my personal habits/algorithms easily and accordingly. But as is, all I know is is that it's not based on world spawn and it's not based on the zeroed coordinates of the world, which means that it is acting strangely in some fashion that will literally make mapping unusable for me.

2.) And because of 1.), it appears to be running on a new system that has no transparency whatsoever because it doesn't work on the existing information given to the player, which makes it more unpredictable and harder to figure out - which is generally something you DON'T want to aim for when you push changes to an existing system!

3.) The fact that you have to go to a really lengthy and still yet confusing explanation to explain this new system proves 2.).

4.) If the debug HUD is not meant to be used by players, why are there so many user commands that use coordinates that you could only get from that screen? tp, for instance, takes x, y, and z coordinates as parameters.

You were the one that made a real-world comparison, I was only returning the favor. Do you know and understand all the method calls, variables and code statements involved in eating food in MC? Probably not. But you know what happens when you eat food: Your hunger and saturation levels go up. Without the help of any coordinates, I know exactly what will happen if I wander off the edge of a map and make another map with the same zoom level: The edge that I left from will match up with the opposite edge on the new map. It's consistent, practical and doesn't require F3. I'll even go so far as to say it's intuitive. I'd be willing to bet that most players who never used the old map system would understand how it works.

The bottom line is that this is not a bug, it's intended behavior according to MC-36639. Why don't you submit a feature request to have a command implemented that changes the grid locations?

Arjan, MC-66091 was not fixed. It was a duplicate, and it was resolved because of my comment saying it was a duplicate, not because the bug was fixed. Anyway, I like the new system with the basis on a certain point, but that should be (0, y, 0), or maybe even the spawn point, not some arbitrary number. Coordinates aren't only for debugging; many map mods show coordinates and servers use them in mapping their world. Also, Systems' point 4). So the "debug screen only" point is quite weak. Seems that the new map centering system is glitched, not the maps themselves. As I said earlier, this could be fixed by making the center always (0, y, 0), or maybe even better, go back to the old system. Mappers who wished for this new change might complain that the maps do not interlock, but this could be offset by having an option to show the coordinates without any of the fps/version/java/etc info somewhere such as the inventory or on the screen itself. It seems a majority of users would rather use a coordinate-based system, though a world-grid based system is nice.

Sean, given the reaction to this change, it's pretty obvious a majority of people support the old method in comparison to the new one. Though perhaps some might only be complaining about the weird gridding, the old system is fine, and experienced mappers who are complaining have certainly used coordinates once in a while.

I agree. I was simply trying to point out that the new system is easier to learn and use, especially for newcomers to MC. If Mojang implemented a way to adjust the grid system, and an option to make a special version of a map that centers the old way, everything would be fine.

I have not heard a logical reliable explanation to how this zooming works. How can you start a map at (0,0) and it zoom consistently down and to the right, and then you start another map in a different place and see completely different zooming like I posted in the file n1216_n832 above. There is no logic to this. There is no way they have made the game easier, better and certainly more fun. Instead they have broken a great part of the game and most people are going hate this and no longer use maps.

Can someone explain to me why my test mapped like it did? From 0 to 1, the map grew down and the left. From 1 to 2, up and to the left. From 2 to 3, back down and to the left. From 3 to 4, up and to the right. I would actually at least understand consistency if it always did this. But it doesn't. The question:

WHAT ARE THE RULES THAT GOVERN HOW IT CHOOSES THE ZOOM DIRECTION?

The rule is, the maps are aligned on a predetermined grid, not centered on the player anymore. I don't understand why this is such a hard concept to understand, especially given all the clear and detailed explanations here.

Your maps didn't "grow" in a random direction, the zoom simply aligned the map to the predetermined grid the game made.

All I need to know is where the "center" of this system is. Knowing the coordinates of that center, I can use the 2048-unit rule to make a proper set of aligned, center bases in the maps...

I made three different test worlds, teleported to X0 Z0, created a map and zoomed it out fully to level 4. In each world, the upper left corner of this fully-zoomed-out map was at X-48 Z-48. This means the center for this zoomed-out map is X976 Z976. Is anyone experiencing different coordinates for the new map grids?

I got a centered map at X=976, Z=976! The initial zoom levels were way in the upper left corner for some reason, but the final zoom is perfectly centered~!

OK.... Sorry I didn't catch this sooner. The numbers are now lining up better on what the predetermined grid is supposed to do. My error is expecting the upper-left coordinates to be multiples of the zoom dimension. Even though, I used upper-left because it is easy to determine in the game (look for when the icon changes between arrow and circle), it is not the coordinates of the alignment. It is CENTER. You need to take the upper-left coordinate and add the zoom dimension divided by 2. Then you got center.

So we expect this thing to line up to center coordinates based on origin: (0,0) right??? That means these should be the predetermined alignments used by Minecraft:
Z0: ...-256, -128, 0, 128, 256...
Z1: ...-512, -256, 0, 256, 512...
Z2: -1024, -512, 0, 512, 1024...
Z3: -2048, -1024, 0, 1024, 2048...
Z4: -4096, -2048, 0, 2048, 4096...

HOWEVER, trying to apply this alignment to the test attached, FAILS. BADLY. It is easy to see with using the center numbers:

Start: (-1206, -770)
Z0: Center (C): (-1152, -768). Is a multiple of zoom dim, 128? yes. PASS
Z1: C: (-1216, -704), Multiple of 256. no. FAIL!!!!!
Z2: C: (-1344, -832). Multiple of 512. no. FAIL!!!!!
Z3: C: (-1600, -576). Multiple of 1024. no. FAIL!!!!!
Z4: C: (-1088, -1088). Multiple of 2048. no. FAIL!!!!

What is happening here guys??— ? Is the grid's origin not (0,0)? If not, why not????

I did 4 more tests this morning before posting this. All of them setting a starting point greater than 0 and they all lined up how I would expect. I am going now do tests with the starting point less than 0 and see what happens.

I FINALLY FIGURED IT OUT!!!! And I tell you what, it is consistent, and reliable and IT SUCKS. The assumption I made and to me, a common assumption is that alignment points as you zoom stay relative to each other, in that they keep a common origin. A logical assumption is 0,0. This is not true. Each zoom level has its own origin and alignments. These alignments are consistent regardless of where you create the map. And hence I can finally agree, THIS IS WORKING AS INTENDED.

Here are the working alignments for this new mapping logic:
Z0: ...-256, -128, 0, 128, 256, ... (multipler: 128)
Z1: ...-704, -448, -192, 64, 320, 576... (multipler: 256)
Z2: ...-1344, -832, -320, 192, 704, 1216... (multipler: 512)
Z3: -2624, -1600, -576, 448, 1472, 2496... (multipler: 1024)
Z4: ...-5184, -3136, -1088, 960, 3008, 5056... (multipler: 2048)

I guarantee your maps will align to the above pattern.

Now the million dollar question I have for Grum and Mojang is: Why did you do this way????????? Is it bugged? NO. Is it intuitive? HECK NO. I am not a dumb guy and it took me a long time to figure this out. I am all for auto-aligning maps but come on guys. Make it easier than this.

Attached is file, zoom_alignments.jpg. This shows how the alignments work as you zoom. Each square is 64x64 blocks. I am only able to show 1/4 of a zoom-4 map on the 8x11 graph paper. But you will see the pattern. After actually visualizing it like this, I am ok with it. It actually makes sense.

Well... Okay. I respect that you have spend so much time on it, but what was the goal of all this? I don't even have to think of any coördinate while making maps in Minecraft. Unless I want to build my base at the middle of a map, that is. Was that your goal? So you could calculate where one can build his/her base with this new system?

Anyways I really hope they revert back to the old system or make some hybrid of the two systems. Now centering is impossible/hard, before 31a, alligning was hard. That's just dumb.

Don't mean to offend anyone, especially since I raged a bit when I made my 20th 1:8 map of a world and lost all alignment.... but it is really quite simple and most comments are looking at it from completely the wrong angle. STOP worrying/thinking about a CENTER!! and STOP worrying about so much MATH!! It is completely intuitive from the perspective of if someone is map making using all the same scale. This is because as you are exploring and get to the edge of ANY size map, step over 1 block to create the next, then match scale and you can continue mapping seamlessly. No more wasting time having to walk over terrain to get to the center of your desired map scale, thus wasting time as that distance walked to the center was not mapped, not to mention needed to follow a pretty strict co-ordinate system to ensure maps placed together are seamless. I think that the commenters are likely more experienced users, and in this situation that is the problem. Put yourselves in the shoes of a newb exploring with maps and it makes complete and total sense. Also is considerably more 'realistic' to start a map next to a current one and be on the edge of the next. I believe that is the answer to Adam's million dollar question and as it will be completely intuitive for the vast majority of players, it should be all the explanation you need, but I will elaborate anyhow.

I may post pics I took shortly, but they truly are not needed. Without using any calculations, here is the simplest explanation, and first I must preface by saying that you have to think of how the first 1:1 maps are made. You do not have to be at any exact center of a 1:1, which was as far as I remember ALWAYS the case. Standing anywhere in the 128x128 block space for map creation will yield the same map. The same logic follows through up the scales. Picture the entire surface being a grid of squares that are 1:16 map size / 2048x2048 blocks. Within each of those are 4x 1:8, 16x 1:4, 64x 1:2 and 256x 1:1maps. Creating ANY of the 256 1:1 maps within that space will yield the same 1:16, same goes for ANY of the other scales within.

As an example, and for the sake of continuity I will use the 0,0 start, this is actually the center of the 1:1 map for that area, and is the basis for the entire grid. The central 1:1 map is the upper left corner of ALL subsequent scale ups from that one, this means that by coincidence since I started there the upper left co-ordinate for the 1:1 will be the exact co-ordinate for ALL other scales. If I went one block north of the original 1:1 map and scaled it up, you would be standing in the lower left corner for each. Go 1 block left of the original 1:1 and scale up, you will be in the upper right corner for each.

Yes, this means the entire world is a logical grid. You can make any map anywhere to any scale, have someone else do the same thing 20,000 blocks away or where ever truly. If you each mapped all the way towards each other it would be a completely error free seamless map. This is infinetly better than having to worry about proper co-ordinates, because it is fool proof map alligning. A player can make a 1:16 map today, and another one make one across a world a year from now, they never need to speak or know where the other is, and still their maps would align.

I'd be more than happy to explain further and add pictures, but as far as I am concerned at this point, this is NOT a bug, IS working as intended. It is actually quite simple and extremely more intuitive than before. Players can now align maps of any scale simply without ever even looking the debug for a co-ordinate. Bug report should be closed.

Notes: The only thing I am not sure of is why 0,0 is the center of the 1:1 map for the area, and not an intersection between 4 central 1:1 maps.

Addendum: Adam's graphs are incorrect as they are not universal and rely on needing to go to the centre. This is a vast over complication and those images should be removed.

Addendum #2: If players REALLY need their builds to be in the centre of any given map size... just map first and then build..

@Joseph Charron. The zooming one is correct and it are universal. Use math and multiply by the appropriate number for the zoom. If you do not understand them or follow them what it means is you do not like or do not understand the new mapping approach they have in 1.8. Prove them wrong.

Sorry I didn't realize the long-winded explanation above is you as well. Your explanation is no less complicated than mine. I think it says the same thing... I think.

I needed to prove this wasn't bugged. My graph shows real numbers that these maps will align to at every zoom. What have you contributed to this thread?

Pfft, @Josepth Charron, I can't stop "worrying about the centre" when that is literally what my classification system is based on. 😉 Make a base, make a map centered from where the base is, map outward. No center = no consistent distances between regions and bases = rail lines that have inconsistent distances and confusing region/province boundaries!

And mapping first and then building won't work because at the highest zoom, the maps are too inaccurate to eyeball the center accurately. Even in the old system, the "center" of the map was always inexplicably a bit off visually even as the coordinates lined up.

I do think this system is relatively counterintiuitive for the average user who enjoys planning with precision. The fact that it took so long to go "aha, the new center is [this]" is proof of that, I think. I understand the need to make it universally consistent on a MULTIPLAYER server, but on single-player where there is one user...

@unknown, you put way too much thought into understanding a system that was designed to require no thought at all. Maps now align themselves on a grid, such that they either represent the exact same area at the same zoom level, or don't overlap at all. This makes it trivial to make a wall of maps in item frames that line up correctly with no overlap. Unfortunately, with this comes the loss of the ability to choose the center point of the map, and a greater risk of accidentally creating two separate maps that cover the exact same area of the world.

@unknown:

Torabi, assuming this change in map behavior is intentional (as you describe), it represents a philosophical change in the concept of maps in Minecraft. One of the beauties of Minecraft is that every individual can play the game in a different way, suited to their own interests. For those who like to explore large areas and stitch maps together, the new behavior will be regarded as a good thing. It will substantially reduce the effort required to get separate maps to line up with each other. For the rest of us for whom maps are primarily about mapping the area around where we live, it forces us to choose a location for our domicile that has a particular orientation to the invisible coordinate system. (Keep in mind that the grid coordinates are only visible if you either have a mod installed or use the "diagnostic" HUD.)
I personally don't like the new philosophy, though I think I understand it and recognize that there are those who will like it. Maps no longer work in an intuitive fashion aligned with the "primitive" character of stone picks and shovels. Instead they act more like satellite images managed by NSA computers.
Has this new philosophy of maps been vetted against the Minecraft vision?

This very succinctly describes the entire situation. However, I'd argue that there's been a gradual shift, at least in respect to maps, from realism to convenience, over the course of Minecraft's development. When they were originally added, they were centered on the exact block the player was standing on, but this was changed in 1.4.2 to center on the chunk. This was certainly less flexible, more magical, and required an understanding of the internal concept of a chunk to be able to predict where the map would be centered. But it made efficiently mapping out an area much easier without counting blocks or using the debug screen.

The ability to clone maps, and for multiple players to appear on the same map, was originally a bug: maps could only be cloned by shift-clicking when originally creating the map, and the player arrows would all be pointing in the direction of the person holding the map, even if the players were facing/moving different directions. This was later fixed up and promoted to a feature: copies of an existing map could be made by crafting it with another Empty Map, and player arrows reflected the actual orientation of each player. Maps also show up as green dots when a copy was placed in an item frame. This information is communicated "magically" between all copies of the map in the world. When item frames were originally introduced, the map showed up in the middle, like any other item, but as of 1.7.2, maps cover the entire block when placed in a frame, to allow for seamless tiling, and thus the creation of large, composite maps. This latest change is just an extension of that trend.

Minecraft is deliberately simplistic, and sacrifices realism for abstraction in many cases. Consider, for example, the use of the same furnace to both cook food and smelt ore. Or the crafting table, which is used to create a wide variety of items, and which features a number of metal (or perhaps stone) tools on the sides, and yet only requires four wooden planks to create. So I don't really think this change violates the philosophy of Minecraft, and I doubt there would have been many complaints, were it not for the absolute loss of the ability to choose the center point of the map.

I don't think reverting to any of the previous behavior is the best solution. That just sacrifices one usage pattern for another. Seamlessly tiling maps is now well supported. Ideally, there should also be a way for players to create maps that aren't locked to the grid, with a way to specify the center point down to the exact block, like when maps were first introduced.

@Arjan: Yes, this was a pain to figure it out and I do take away the proof to myself and to whoever else that may care that it is not bugged. The other advantage I have now is that I understand where the map centers will always go. It is true that you cannot have your base be the center of the map at all zooms, unless you build at the world origin. But if you desire having your base at the center of a map at a certain zoom, the numbers I wrote represent where that center will always be.

For example, you want your base in the middle of a zoom 4 map and the area you are in is like (-900, -900) let's say. You know that at zoom-4 center is (-1088, -1088). You can plan for it, if you want. Now if you don't care about center and you care more about lining maps up in item frames, then it will be automatic.

I think the suggestion others have given in this thread is a very good one. And that is, give us an option on how this mapping works. Let us set old or new.

@Torabi: My over-complication was partially my fault admittedly. I had some principals on how I thought it worked hard-wired in my head and I had to prove them out. However, a good portion of the difficulty will come to anyone who wants to understand where there base goes as they zoom a map. For the people that want to map based on their base, they are going have a hard time now. But if you want to make maps and frame them up, this change is excellent. It is a no brainer.

For me, since I understand it now, I can use them either way. Is better this way? Its clearly a matter of opinion.

@adam You don't need to use offensive language. Your second graph is correct yes, for starting at a centre and trying to scale up. It is just not universal because your graph does not show that you could be standing anywhere in that 2048x2048 map and get the same 1:16 map as a result. The graph more so shows that you would have to be in a specific location is my point. You are vastly over complicating something which has just been made simpler by the developers for everyone.
I do perfectly understand your math and appreciate you figuring that part out, however that is only important for a fraction of a percentage of people that desire to have something be in the centre of a scaled up map before they build. For the average user, no math is needed to make aligned maps is what I am focusing on. "The needs of the many" Also, if the debug screen goes away for quasi realism, no co-ordinates would really be known.

@SystemsReady I do see your point about wanting your build centred, I guess I think that would be a small percentage of people? Personally with myself using 1:8 maps, if the build is anywhere in that first one, by the time I add 7km worth of maps in all other directions, it is negligible. I frame them up though so that could explain my own perspective on that.
I believe taking this long for the aha moment is not proof of it being counterintuitive, perhaps it only is for us because we're used to having to travel to make maps in their centre for proper alignment. I think it would be pretty simple for someone who hasn't made maps before. I do though completely understand wanting to choose your centre yourself.
@MOD Torabi Only issue with what you said about maps not locked to a grid is that it cannot be down to an exact single block as you need to conform to the # of pixels which are an even #. The true centre has to be the intersection where 4 blocks meet.

@ whomever. Perhaps this new method also helps performance as every world now only has 1 master version of every size of map? Before when centering on any 1:1 map created meant many numerous iterations of all map scales. I do not know if this relates to how maps now instantly populate with the area you are in compared with the slowly filling in before and sometimes impacting performance if zipping around in a boat for example.

Hmm, since it is correct, someone should use Adam's maths to make a simple application that a player can enter their x and z, the map scale, and it outputs the center for that map.
I was making a spreadsheet but with needing the various scales it gets unruly fast. It is better as a database then an interface..

Adam's solution of making the center always (0, 0) instead of (64(a^2-a)), (64(a^2-a)) when a is the zoom level is really all that needs to be done, and an option of old vs new would be next to useless if the center was fixed to (0, 0). Joseph, your argument to stop using math sounds anything but intelligent. Math is essential for map makers anywhere, and the new values are confusing, though they do require math skills to figure out. It makes no sense for 64(a^2-a) to be the new center, but I assume this is a glitch.

I disagree that it was anything but intelligent. Of course math 'was' essential to me as a map maker for making massive ones with frames, it was absolutely vital. As this kind of map making is my primary use for them, the new system means there is not a single need for a number to be involved at any point, because everything will always line up 100% error free now. On my server anyone can map their own area anywhere in the world, and a copy of it will fit perfectly with the main one. Since this is the case a specific co-ordinate for a center does not matter at all, but as was mentioned this is a great new advantage for those of us doing the larger format frame thing.
Yes you will want to work out co-ordinates beforehand if you need a build to appear in a specifc place on a map. My viewpoint is based on the way I use them, and putting myself in the shoes of a new player -to whom going deep for redstone, farming sugarcane, and sparing iron to make maps is not really a priority. From that, knowing the center of larger maps is not nearly as important as is the ability to make them easily while exploring. If exploring thousands of blocks in one direction, being able to make the next map and start populating it seamlessly with the previous, without having to trek to a specific central co-ordinate is a huge time saver not to mention how logical it is from this 'on the ground' perspective. It also means that if you are not fully populating large maps you can have them match up in much nicer ways if displaying in frames.

Anyhow, stating that my argument is less than intelligent is a vast error. There is no NEED for math now when map making, there is just the WANT for those that want something to spefically be in the middle. For that case I completely have agreed that 0,0 would seem more logical. I would think it quite less than intelligent to dismiss an argument that is taking into account multiple ways of looking at this, in favour of narrowly focusing on being able to build before exploring/mapping an area and your buid ending up in the middle. It seems readily apparent to me that there are many more advantages to the new system compared with the desire for the 1:1 map to be the middle of every subsequent scale change. So yes, I would say it is not a bug and is working as intended. Some people being inconvenienced by something does not make it a bug.

Also, for maths sake, I have to point out that prior to this change there wasn't actually any central block to any of the maps, the basic map unit was/is a 128x128 block square on a static grid. Since 1:16 is 16 of the 1:1 maps across the center of your 1:16 map, 0,0 was not the center of your 1:1 map. The center was the intersection of the 4 central 128x128 / 1:1 maps. This is why when people build at a central 1 block co-ordinate it will apear a little off center on the larger ones. Truly, before this change, the true center of any lager map you made was always up to 128 blocks off in both x and z. Even shifting the grid so that the 1:1 map containing 0,0 stays 'central' when scaling up, this would still be the case. Soooo, since any map you've made and built precisely around where you stood being the exact center has been wrong.... you should actually have worked out the most basic math component of maps before dismissing my argument, which is that the change makes mapping easier/logical/sensible for players of any age and math skill.

The logic is that (0,0) is in a corner. Makes perfect sense from a programming standpoint.

I'd prefer (0,0) to be center, but I can live with the current setup.

Joseph, up until dismissing every map I've ever made as wrong, you were spot on. But to dismiss every map ever made as wrong is just lazy. The new system takes a certain corner of your map and makes it the new center, forcing 4 maps to show a certain point instead of 1. I agree that grids make sense for new users, but NOT with the current numbers. and the center of the world should always be (0, 0) or your spawn point, not (NEGATIVE 1088, NEGATIVE 1088), (960, 960), or any combination of the two. This is simple to fix and uses common sense. This is a little nitpicky, but absolutely necessary to some people and in particular almost all servers, unless they use (gasp) FOUR maps. Even then, the center still cannot be determined, which is a very important tool for many servers and people such as myself, Adam, and others. Though gridding is a good idea, more maps made in the past were based on (0,0) than probably any other point and this should be reflected. Please, give me a rational argument that supports these new numbers. I already agree on the grid.
I wrote before I read it fully... sorry.

Jesper, (0.0) isn't even the corner. (-64,-64) is.

Well, not confirmed. What do I say? It's in 14w32d.

14w32d. (that was for the pictures. weird.)

@Jesper Petersen: Center is (0.0). I first thought that where the maps align to their multiple of X was in the upper-left corner. This is not the case. CENTER is the multiple of X always. X depends on zoom level (128, 256, 512, 1024, 2048).

You have to use math to calculate center now. But only if you NEED it. I started one of the maps I had shelved in my 1.8 world. It looked so bugged when as I zoomed the map, my base was going all of the map. But now I understand that when I see my base near the upper-right corner of my zoom-4 map, all I have to do is move east far enough so that I am off that map, and then create a new map (make sure you go far enough or you will duplicate your current map). I can then zoom this map all the way out to zoom 4 and it will line up exactly where my current map left off. I like it now that I get it. Its automatic. Its easy.

I removed my vote for this issue to be fixed.

Oh, thanks for the strikeout edit. I didn't mean to offend anyone or start an argument, just seemed no one was realizing that a 1:16 map is 16 x 1:1 maps and not 15 complete ones with 1/2's of 1:1's on the map borders.
It's just kind of a small pet peave of mine when people center things on one block instead of 2 facing horizontally, or 4 facing vertically. This mostly stems from having made a city road grid for a server with an extensive subway underneath keeping everything 1 chunk wide, and making Residence only claim multiples of full chunks for players. Was an idea at the time to help a tad for performance with plugins. The inevitable by-product was that since the world is based on chunks, it is an even numbered system. After all, 0,0 has never been a block, it is the point between the central four +.5 and -.5 blocks. I could have sworn it used to be in the middle of a central chunk, I'm actually almost sure of it when I think back, because our city had a 1 chunk wide axis that straddled the 0 lines. However when I tested before posting yesterday, 0,0 was a point between 4 chunk corners.

I think we are all agreed on the grid issue, having the 0,0 point be the centre of the 1:1 map that ends up in the north-west corner of all its subsequent scaled up versions seems quite odd. Pondering what Suburb says, the centre of the world being the intersection of 4 maps of any size seems somewhat logical as it would perfectly divide all maps into a quadrant system. Then at least to calculate the centre of say the first 4x 1:16 maps your centres would be the +/- 1024 points, then any centre after is adding the simple 2048 blocks. That does of course not give you the desired 0,0 being middle of any single map, but makes calculating centres in your head simple at least, may be a sufficient compromise? I dunnno, would be nice for someone from Mojang to weigh in on this one.

@adam Thank you for coming around on the auto and easy part. Hopefully we can just get the grid placement tweaked a tad as I mentioned above so centre calculations could be a bit more intuitive for all. Thank you for putting the work into working out the previous calculations, just thinking that, map width multiplied by 1.5 or 2.5/3.5/4.5 etc would be much easier for everyone.

Agree with you Joseph, a Mojang staffer would really help. I've woken up fairly late over the past few months, and since noon in Stockholm is 6 AM in my time zone (EST), the earlier, the better for me. I'll try and get attention to the issue the earliest I think of it.

Oh memories.. -the pics

My intuition is that the maps meeting at (0,0), rather than being centered there, was the cleanest way of implementing the universal grid. It means no map ever crosses either axis, and thus the scaling algorithm never has to deal with both positive and negative coordinates on one axis. It's also a little easier to calculate which grid you're in for any particular zoom level, given the coordinates: divide each coordinate by the number of blocks for the desired zoom level, and round up. If the maps were centered at (0,0), the grid would be offset by half a map.

There are reasons to build near the origin, or at least near world spawn, however, and how that affects player behavior might make the additional complexity worth it.

@Torabi Sorry man, but as per our comments above, the maps do not meet at origin which is what we've most recently been discussing. 0,0 is the center of the 1:1 map in the NW corner for all larger maps for that area. Therefore all maps which 'could' have their western edge be 0,0 actually have it 64 blocks west of 0. Same situation applies to all maps which 'could' have their northern edge at 0, their northern edge is 64 blocks north of 0.
What you are stating is actually what I had just suggested above 😉 Same for the problem with centering maps at 0,0 with the grid offset by 1/2, hehe c'mon silly..

What Torabi is talking about would be a nice way to fix this though.

Oh indeed, tis what I said last night😉, whatever their map grid is currently needs to be shifted south 64 blocks and east 64 blocks. then at least 4 maps of any size around origin would meet at 0,0, and make finding map centres a simpler calculation.

Looks like I didn't test the lower zoom levels thoroughly enough to understand the algorithm. Somehow I missed the fact that 1:1 maps are still centered on the origin, possibly because it sounded like multiple people were insisting that it wasn't. That offset might explain the weirdnesses I was experiencing during my testing though - I was chalking it up to the map border.

I've come around to like the quadrant system (centered at (0, 0), of course), but for a new player, how is a quadrant-based system helpful? It hurts anyone who wants a map centered on themselves to map their tiny little area, though maps in general are probably more useful in creative or on big servers, which are the two big sections of the game that could use the quadrant system. This was already a little off with the closest-multiple-of-64 system, but with bigger maps the system is far more out of whack. So what I propose is to slightly modify the crafting recipe for quadrant-based maps. Normal maps will go by the usual recipe of 8 papers and the map, and quadrant maps will use a compass in the top center slot instead of a paper. So, here's the new recipes;

Normal Map-------------Quadrant Map
PPP-----------------------PCP
PMP-----------------------PMP
PPP-----------------------PPP

P: Paper M: Map C: Compass

Thoughts?

In 14w33a.

Not related to MC-1404?

It bears repeating that while these new not centered maps are good for tiling multiple walls, they are bad for single maps. Judging from the votes this bug has and the previous non-tiling bug got, the previous behavior was better. Maps aren't just for big walls of maps, lots of people have a bad sense of direction and like a map centered on their base. Practical use should trump decorative use.

I don't have anything against maps that tile easily, but they should be optional. Some new recipe might work, e.g. old map + slimeball would snap the map to be the adjacent one, depending on the relative direction of the items, which could be done in the small grid for all 4 (or 8) directions.

Hmm, practically speaking, did explorers making maps of the new world start in the centre? I hope the americans don't start changing all flat maps of the world to have the US in the centre.

For sense of direction I am quite confused by your statement. If someone looks at their single map, can see where they are, and can see where there base is. How can anyone with even the worst sense of direction not be able to get back home? Point your white arrow to your base and walk. Seems fairly foolproof.

I do of course understand the concerns of people who want their build to be in the middle of their first map, but having a static map grid of the world just seems cleaner from a programming perspective instead of needing to have a # of various grids.

Your snap idea is interesting, but one of the main advantages (aside to error free alignment forever) to this new system is being able to create a new map at the edge of an old without walking up to 1000 blocks to make their next. I'm not sure if both methods can exist in parallel, as well as having both not just confusing people.

Anyhow, by definition, this is still not a bug. It is users thinking it should be tweaked or changed entirely.

I agree with the concept of creating a way for a player to specifically craft maps to be used for either tiling or for small-scale individual use. In this way, perhaps if you opted out of tiling, then maps of one style could go all the way back to the old way of centering itself on the exact block you're in.

I know this is now a suggestion (but a big part of this thread is talking about non-bug design decisions), but for those who prefer personal, single maps, then what if you could craft a very expensive redstone-enhanced (throw in an emerald or two?) map that would be dynamic and always kept the player holding the map in the center, and it would scroll as you moved and store large areas (beyond one tile) in the one map like a personal computer.

Or just a way to manually reset the center of a map and discard the data outside the new center.

(To Altti Tammi: I'm not sure counting votes is very effective for something like this, since this is more of a for & against discussion, not a for & abstain discussion. Also remember that voting is a way to get Mojang's attention. They even say so themselves. So if you disagree with "fixing" this, then you're in a catch-22 where you want to vote to get developer feedback, but you don't want to vote to express support.)

Joseph Charron: If your base happens to be in a corner of a map, you have to have 4 different maps to be able to properly navigate in the vicinity of your base. I'm 100% sure maps of the US don't have Kansas in a corner. There's nothing hard from a programming perspective in allowing arbitrary centre points - there aren't any grids.

The snap idea was to craft a (copy of a) map into its neighbor, emptying it in the process. You wouldn't have to walk 1000 blocks to do it - you could do it everywhere in the world. Slimeball right of map? Moves map center east 128*2^maplevel.

I agree it's not a bug, but hey, neither was the previous one and it still got fixed. At least Mojang might read this if it's marked as a bug.

@Altti the Kansas ref is kinda silly. Also there is obviously a grid if the maps are right now snapping to a grid which is static for any world created on anyone's machine, with no ability to move the centre.

As an aside, I'm kinda honestly surprised that people for whom maps are important do not map before they build a structure of permanence, as if the first place they make as their home is the only spot they will be. but hey, it's a sandbox game, no one can really tell anyone how to play.

Hey, maybe they aren't paying attention due to the report title having the yankee minority way of writing centred. 😛

@Joseph I didn't say there isn't a grid now, but that there isn't one when arbitrary center points are allowed. When programming it's just a question of doing a modulus. Why is the Kansas reference silly? It's the exactly same problem people might have - the map shows only a quarter of the areas they are interested in.

I really think people shouldn't be required to choose their home based on where it falls on a grid. A single map isn't a world map and should be allowed to be centered to show whatever is necessary. The purpose of a single map is very different compared to a huge wall of adjacent maps and these gridded maps are helping people who want fancy map rooms at the expense of people who just want to see where they are.

I can't even comment anymore, I have nothing to add to Altti's argument.

Jonathan, I like your recipe, but normal maps should still have a player-centric system. To ask a person, who has never mined deep enough for redstone or been even near emeralds, to follow a grid on their own map is way too complicated for many. Though I like the grid system, it is too complicated for first-timers, and the two systems should be separate from each other. So, combining my recipes with Jonathan's, and tweaking them a bit, here's a proposal on how to create these maps. All maps will expand with the same recipe as always.
Normal (created Player-Centric)
Zoom: 0
~~~PPP
~~~PCP
~~~PPP
Gridded ((0,0)-Centric). Icon will be normal map with closed grid on it.
~~~PRP
~~~PCP
~~~PPP
Full (always Player-Centric). Icon will be normal map with Steve head in middle.
~~~RER
~~~PCP
~~~PPP
For the full map, the map can be placed entirely within item frames by first placing your current area in a frame, and then the frames beside them would have the map 1024 blocks N, NE, E, SE, S, SW, W, or NW of the original, and so on until the entire map is posted. All maps will expand on the frames as they do in the player's hands, though this could take a while, maybe even 1.9/2.0. For 1.8, I think the current (1.7) system should be kept until the gridded system can become its own entity, which hopefully can happen in the pre-releases or in 1.8 itself, because it seems 14w34 will be the final week of 1.8 snapshots.

the system have changed in 14w31a before when zoom the center of map not changed the new behavior is incomprehensible

Affects 14w34c

Sebastien is right. The gridded system, while helpful to experienced mappers, simply does not work for the average player.

How exactly does this grid system work? As in what numbers/axis do the maps affix to? I am experiencing the problem with my map's centre point moving as I zoom out. But if I can make a 128x128 map centred on the correct point, why does zooming out move the centre point? Is that actually related to the grid changes? I feel if I can make a small map on the correct point, that centre of that map should stay the same as I zoom out. Maybe we could zoom out an empty map and then when we started it it would centre to a grid, but if you zoom out an active map, the centre x/z should stay the same.

I did skim over it all, it's 90+ comments to read through, and some of them sort of explain a solution or a way to get a correct centre point. But I was looking for a simplified, concise answer. It would not only help me, but anyone in the future would see it, and not have to read through 90+ comments and sort out bits and pieces from multiple comments.

Affects version 14w34d

Yes, yes, and yes Matthew. All the maps should center at where you create the first one.

Should the title of this "bug" be simply changed to "New map confusion" ?

if is not bug why changes without explanation, i have post 4 screenshot and I would like to explain to me where is the logic ?

map create to my location is not center but, ... ok

the point are in right top ok its may be the new logic

always at top right like the new logic

and now is in middle right ... Why ??

This bug was created in the snapshot 14w31a. If this bug was not a bug we could see in the list of additions for 14w31a "new system for the maps" but it appears nowhere "new system for maps "on the site ... So this is a bug.

https://mojang.com/2014/07/minecraft-snapshot-14w31a/

/\/\ This.

It could always be one of those secret updates though.

Affects 1.8-pre1

When watching the changelog of 14w31a (https://mojang.com/2014/07/minecraft-snapshot-14w31a/) it can be seen that this change is result of correction of old bug (since 1.6.4) this bug is MC-36639 it is noted : "Zoomed out maps do not properly align" but this new system is slightly strange, Finally, it is the choice of Mojang

This ticket is probably a result of a secret change to maps implemented by fixing MC-36639.
Let's see if we can agree on a few things. I agree that:

The new grid system helps experienced mappers
The old system helped newer mappers
The new grid system's center of (-64, -64) is confusing
The grids help connect maps
The grids prevent personal maps
More math is required for old maps to connect

@ SuburbSomeone,
So if I follow along with the new grid, to have a 2048 map centred at ~x,~z I need to make the first map at (~x - 256),(~z - 256), -64 x 4 layers of zooming?

Actually Matt, it seems that it isn't (-64, -64) as previously thought. It has no center whatsoever. This proves that this must be a bug.

Hrmm well that is both good and bad. Good because it's a real bug, so it should get fixed. Bad because I thought I might have a work around to finish my map room. Thanks for the clarification Surburb

Sorry Matt no, due to the grid you cannot choose your centre, each 2048 map in the grid covering every world has a static centre. Sorry again, but you cannot finish your map room, you have to start over again from scratch like everyone else. & if they do shift the grid to line up with the 0,0 point you will have to again. Don't thank suburb, that's bad intel being provided.

Suburb, no one ever thought -64 -64 was the centre of anything. the 64 figure was the north west corner of the 2048 map which contained 0,0. It was also the north west corner of the north west 1024 map inside that one, and so forth down the line.

How come we are going backwards here... the only thing that was agreed upon concerning the 64 figure was that it is odd that it was the corner of 1x 2046 map, and therefore the point in between 4x 2048 maps and we did not understand why that intersection was not at the 0,0 point. If that is what you are saying by saying 'system's centre' that's cool, but add more words so it is clear to all. I do not understand why you are telling Matt that there is no centre whatsoever when the grid is static and always the same.

Yet again, this is not a bug, the grid is intended, we just want clarification if the way they line up is going to be permanent, or will they make more logical with the 0 point mentioned above. Plus some people would like Mojang to add an additional way to choose your own centre point. I would assume that won't happen and everyone is just going to have to use the new easy map making system. If they want their builds in the centre of a map, they are just going to have to make the map first.

A mod seriously needs to change the title of this bug, because it is wrong. The new maps are centred, just not at the point the player is standing when they make the map, unless they happen to be at that maps static centre point. The centre of map zooms 4 is good, it just isn't what some people want it to be. Again not a bug, it is a change that some people do not like. This has become somewhat ridiculous.

Affects 1.8-pre2

This is working as intended. This change occurred when they fixed MC-36639.

Maps now align properly at the higher zoom levels but it comes with the side effect that maps are no longer centered where they are made. This makes mapping easier since you no longer need to count blocks to get maps to align. It also makes it easier in multiplayer because you can now map with friends (who use the same zoom level) without worrying about overlapping.

Maps now align properly, but are now completely useless if you just want a map to carry around with you, centered on your home base. People who aren't ready to make a map wall will find maps to be of no use at all anymore; If people want to make a map wall they can use the console to line up their coordinates, the rest of us shouldn't lose the functionality that these items once had.

= This DOES NOT WORK as intended, Mojang!!!

Probably it does work as intended, but it would be one of the most awful intentions I have seen. I don't understand why Mohjang wants to remove functionality from the game...
As I suggested, it would be quite easy to create crafting recipes that allow to make maps that align properly with an existing one. This solution wouldn't kill the other (the main-) functionality of maps.

Affects 1.8-pre3

Strange how Mojang's people have failed to address this (or the beacon glitch) yet. Grids are nice, but... I'm just repeating myself, open up the old comments and you'll see. Hopefully the lack of Mojang staff on this issue = them being hard at work, but I'm not so sure. If votes were the default way to organize bugs, and they looked for bugs past MC-60000, then I'm sure they would know.

I imagine they'll wait to see the general response to the new functionality once 1.8 is released. Only a couple people have weighed in on this, and the activity on this ticket isn't necessarily representative of the general Minecraft userbase. The behavior could probably use some tweaking, but additional functionality (such as alternate crafting recipes for different types of maps) should be brought up on the suggestions subreddit. This change doesn't affect existing maps, and therefore won't damage existing world saves, so this issue probably won't be addressed for 1.8.

If this was intentional then I am sad, the old map function was actually useful, with this I now have no reason to use maps, but oh well the best I can do to change this is to complain as I currently am doing.

This change makes that people use f3 more because the old maps can use to measure distances.

Haha silly Auto, you can still measure distances with the new maps, the size of them did not change.
Ares, why is this method less useful, and why would you have no reason to use them? I don't see any logic there.

I still say the new map system is fantastic, is intuitive, and makes perfect sense.

Yet again, this is not a bug, this bug report should be closed finally...
People that do not like the change should go on Reddit as was suggested by someone already. Just because you do not like a change in an ever evolving 'game' does not at all make it a bug, especially when the new method makes so much more sense.
Of course as a bunch of us agreed on, it would be nice if the intersection between 4 central maps of any size would be more logical if at the 0,0 point. Still not a bug though!

ehh... it kinda is. It is neither based on (0,0) nor spawn, and unless a formula is stated in the code, then it is a bug, no question. IMO the maps should be gridded based on where you create your first one. So if you create your first map in a certain world at your spawn (let's say 36, 67, -124), and zoom it out to 1:16, then the borders should be (1060, y, 900), (1060, y, -1148), (-988, y, -1148), and (-988, y, 900). If you create it at (0, y, 0), the borders should be (1024, y, 1024), (1024, y, -1024), (-1024, y, -1024), (-1024, y, 1024), or maybe adjust all those numbers closer to the center by 1 to fit the map. In the first case, (1060, y, 900) would be the NW corner of the SE map out of a group of 9 maps, (1060, y, -1148) would be the SW corner of the NE map out of 9 maps,
etc.
I still think the old way was better for the average user.

Care to wager a Minecraft account? I'd put money down that it is not a bug at all. It is much more streamlined and less system taxing to have set static maps with each world instead of almost infinite variations. Again as we had previously agreed, not using 0,0 as the centre intersection is odd, but if anything I would say more of an oversight than a bug by definition.

In my experience on servers at least, the average user doesn't even bother to create any maps. New system is better and more efficient for people exploring a world and making maps at the same time, and provides completely fool proof map aligning. Considering that it makes making maps easier for everyone. The only downside at all with the new system is that people cannot choose where the map is centred, which my possible reason for that is in the above paragraph. Have you noticed how much faster maps populate now when exploring? Now a near infinite number of people can create a map standing anywhere within a 2048 width map area and all be accessing the same map file/code/whatever (while still being their own individual map). This has to be more efficient code/system/whatever wise than having a different unique map for each person standing in a different spot in that 2048 width map area. I believe this change benefits the vast majority of players, is a super simple system to understand that even my youngest players instantly grasp, and it is universal. Unless you are keeping your main world from 1.7 or earlier without the new things generated and changes made in territory you've explored, it really is no loss of time truly. In the time that we've all been discussing this change, I've already replaced all my old maps.

@All: Please stop discussing. This is a bug tracker and not a Forum. It's up to the devs either to declare this as intended or to fix it.

Affects version 1.8

The way I udnerstood the new system this is not possible. You would need to re-create your map wall or have parts at the transition from 1.7 to 1.8 generated maps either missing or overlapped.
In my own world I have the same problem. I will probably wait at least a few weeks, maybe they change things back to normal based on the reaction of the players.

EDIT: If you play survival and don't normally use cheats and stuff - I think re-mapping the old already mapped territory in creative mode or with Speed X is morally allowed 😛

Confirmed again in 1.8 official release.

To add instructions to recreate:

1. Go to 0,0 either by walking or /tp
2. Craft and activate a map while standing on 0.0
3. Zoom out a couple levels to see better

I also added a screenshot showing that I am at 0,0 while activating the map. Where it is crafted shouldn't have an affect on the center location, but I will look into this to confirm.

Assuming that when the white sort of arrow/pointer on a map becomes the white dot/circle means you just left the area of the map you are holding, this new map system doesn't work for me as intended (if what has been found out here in the comments actually is the intended functioning). I found the upper left corner block of a given 1:16 map (created at 0,0) by examining where the pointer became a circle on the map. Standing on this most left and up block of the map I moved one block up (that is, north) and created a new map. However, instead of showing me the area adjacent to the north side of the first map, where I would currently be located at the very south and left corner, I got the first map another time.
If this is intended behaviour it is everything then intuitive. Or am I still thinking to complicated about it??

This ticket turned a bit into a discussion forum. Keep in mind that this is a bug tracker, if you want to discuss this issue, please create a new topic on here: http://www.reddit.com/r/Mojira/

If there is one created, I will link it in the issue description.

I created a discussion thread in reddit for this bug in r/Mojira: http://www.reddit.com/r/Mojira/comments/2fsjjd/mc64909_new_maps_not_centered/

Affects 1.8.1

Excellent🙂 Maps work perfectly, stop rocking the boat.

Suggestion for a crafting recipe to make both ways work: The regular crafting recipe (map, paper all around) gives you a larger map with more space all around. If at any one expansion you have the map in the corner instead and the same 8 papers filling the other slots, the map will be aligned to the universal grid.

How about allowing the map to be placed anywhere in the crafting recipe, and making the map grow into the paper? It would look like this:

+-------+
P P P    | +---+ |
P M P -> | |   | |
P P P    | +---+ |
         +-------+

         +-------+
P P P    |   +---+
P P M -> |   |   |
P P P    |   +---+
         +-------+

         +---+---+
M P P    |   |   |
P P P -> +---+   |
P P P    |       |
         +-------+

No more automatic universal grid, but now you can line up an edge or corner which is much easier. You can also grow the map from the center (or any way you want) again. Best of both worlds?

The one caveat is that you must grow adjacent maps the same way when you grow from level 0 to level 1. There are four ways because left = right ≠ center and top = bottom ≠ middle. It's best to start from a corner so you can just walk a minimal distance off of the map to make your next one. All subsequent levels don't matter, at least, so if you really want to do this you only have to walk 128±64 blocks even if you're making level 4 maps (as opposed to 1024±64, which is hard to do without the help of F3).

That's an awesome suggestion I think, however you might want to post it there, as this comment section is not intended as a discussion forum: http://www.reddit.com/r/Mojira/comments/2fsjjd/mc64909_new_maps_not_centered/

@unknown: Proposals for a fix are always welcome, otherwise there wouldn't be anything in these comments. The /r/Mojira thread was created because the discussions turned into a is a bug / is not a bug fight.

@unknown: Your suggestion might be too complicated since most of the combinations of expansion directions wouldn't be useful. It would also cause slightly more work for the map wall crowd. I do like the intuitiveness and flexibility of your suggestion. Having varying expansions by half maps and full maps might complicate things a bit?

That's what I thought. I did add it to /r/Mojira because why not. If a mod objects now, I guess that'll be my new home.

This isn't very complicated, is it? It's only little bit of flexibility added in a minimal and intuitive way, to keep wall maps feasible and improve mapping in general. Maps have always been very rigid, and I feel this is still rigid. Why must it be so hard to get maps of the area you want? Maps should be less of a one-shot thing (sometimes with no way out, as this bug report shows). Ideally, you'd have an interface to visually position and align multiple maps, although that's hard to fit in the game's atmosphere and takes a lot of dev time. At least this is a good effort to improve things within the constraints of the crafting system.

Map walls would be slightly harder to make again. Slightly. I feel it's a good compromise.

One factor involved in the compromise is that I don't think the game should assign a special status to places at scales as large as 2048 blocks. It is necessary to some degree to make aligned maps feasible, but don't take it to extremes. Such a kludge. If I had my way, I'd probably round maps to 64 blocks instead of 128 (although really for uniformity). It would improve the miserable framing options of level 0 maps, not to mention multiples of 64 blocks are available at other levels.

The implementation might look like this:

int new_map_center_x = old_map_center_x - (recipe_map_x << old_map_scale + 6);
int new_map_center_y = old_map_center_y - (recipe_map_y << old_map_scale + 6);
int new_map_scale = old_map_scale + 1;

5 additions/subtractions (4 with common subexpression elimination) and 2 bit shifts. Decoding the crafting recipe really is the hardest part.

The map center was previously always a multiple of 128. Now level 1+ is congruent to 64 mod 128. My proposal allows level 1+ to be either (0 as well if I had my way). There is no technical reason to enforce either of these; it's all been to aid map alignment. The map code only wants all the blocks that make up a pixel to be part of the same chunk, i.e. multiples of 16 are needed to support level 4 maps.

"There are advantages as well as disadvantages and which of them prevails is subjective."

That is perfect, and should be the reason for closing this out as not a bug.