Bug
Maps generated in 18w31a and below reset upon updating to the latest snapshot. A new map zoomed out to the maximum based on the current location is shown.
The correct .dat files for the map are still in the game folder.
Analysis by @unknown:
— The affected snapshots are able to handle maps where 'dimension' is an integer tag. The issue only seems to occur with byte tags, which is how it was stored prior to 18w31a.
How to reproduce
Create a world (tested with 1.13)
Make a few maps
Update it to 20w22a
❌ The maps don't show the original, but are reset and zoomed out
Logs
The logs have many entries like the following that seem to be related to the problem
(20w22a) Error: "Not a string"
[13:29:13] [Server thread/ERROR]: Not a string
[13:29:13] [Server thread/ERROR]: Error loading saved data: map_7
java.lang.IllegalArgumentException: Invalid map dimension: 0b
at czd.c(SourceFile:127) ~[20w22a.jar:?]
at czd$$Lambda$4342/903822550.get(Unknown Source) ~[?:?]
at java.util.Optional.orElseThrow(Optional.java:290) ~[?:1.8.0_51]
at czd.a(SourceFile:127) ~[20w22a.jar:?]
at czi.c(SourceFile:72) [20w22a.jar:?]
at czi.b(SourceFile:58) [20w22a.jar:?]
at yz.a(SourceFile:1167) [20w22a.jar:?]
at bkc.a(SourceFile:58) [20w22a.jar:?]
at bkc.b(SourceFile:63) [20w22a.jar:?]
at yy.a(SourceFile:94) [20w22a.jar:?]
at yl.g(SourceFile:1070) [20w22a.jar:?]
at yx.p(SourceFile:398) [20w22a.jar:?]
at yx.a(SourceFile:337) [20w22a.jar:?]
at yz.a(SourceFile:348) [20w22a.jar:?]
at net.minecraft.server.MinecraftServer.b(SourceFile:860) [20w22a.jar:?]
at net.minecraft.server.MinecraftServer.a(SourceFile:799) [20w22a.jar:?]
at eoh.a(SourceFile:92) [20w22a.jar:?]
at net.minecraft.server.MinecraftServer.run(SourceFile:658) [20w22a.jar:?]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_51]
Linked issues
is duplicated by 2
Attachments
Comments 13
I decided to do a better test. I made a new world in 18w31a and made a map. Then I loaded that world in 20w21a and the map still worked.
Then I made a new world in 18w30b and made a map. then I loaded that world in 20w21a and the map was blank.
This validates my theory from my earlier comment that the bug only affects maps that have not been touched since before 18w31a.
Does this also affect worlds last saved in a release version? Worlds opened in snapshots may be corrupted beyond repair.
I just repeated the same test but with release versions instead of snapshots.
Made a new world in 1.13 (last release before 18w30b) and made a map. Then loaded the same world in 20w21a and the map was blank.
Then I made another world in 1.13.1 and made a map. Then loaded the world in 20w21a and the map was still filled in.
I used the seed "map" in both worlds.
I don't think this is because of an old version of the game corrupting maps. It seems more likely that it has to do with map format changes made in 18w31a, and 20w21a not being able to read the old format.
I created this world in a 1.16 snapshot version, so these maps do not use the pre-18w31a map format.
I found a workaround get these maps working in 20w21a/20w22a by editing them in NBTExplorer.
The old map format stores dimension data (whether the map is from the overworld, nether, or end) as a byte tag, but in the new format it is instead stored as a string tag.
It appears that 20w21a and 20w22a only handle the case where the dimension tag is a string, so if the tag is a byte it throws an exception, as seen in the log output in the description.
Changing the dimension tag to a string in NBTExplorer allows the affected snapshots to read the maps.
Workaround:
Back up your world.
Find the map_x.dat file (where 'x' is the map number) for a map that isn't working and open it in NBTExplorer.
Expand the 'data' compound tag and find a byte tag called 'dimension'.
Record the value of this tag. It should be either 0, -1, or 1.
Delete the 'dimension' byte tag.
Create a new string tag called 'dimension'.
Edit the value of the new 'dimension' tag. If the old value was 0, set the new value to "minecraft:overworld". If the old value was -1, set the new value to "minecraft:the_nether". If the old value was 1, set the new value to "minecraft:the_end".
Click the save button in NBTExplorer.
Load up your world in Minecraft, and type the command "/give @a minecraft:filled_map{map:x}" (where 'x' is the map number) to give yourself the map you just edited.
Confirmed with a fresh world created in 1.13 and upgraded to 20w22a.
I updated the description and removed everything related to the map art generator, as this issue clearly affects vanilla.
The maps don't actually need to be in an item frame either. It happens with any maps where 'dimension' is a byte tag.
Also, the affected snapshots are able to handle maps where 'dimension' is an integer tag. The issue only seems to occur with byte tags, which is how it was stored prior to 18w31a.
I had this issue as well, but on maps created in-game.
The maps that still work seemed like they are all maps that I have updated recently, so I loaded some old backups of my world in 20w21a to see what was broken.
When I loaded a backup from August 2nd 2018, all the maps were broken, but when I loaded one from August 4th, a few of the maps were not broken. The maps that were not broken are ones I was working on filling at that time. So it seems like any map that had been updated after some snapshot around that time were the ones that still work, and older maps break.
My guess based on the date is 18w31a, because it was released August 1st 2018. So it seems like any map that has not been updated since before 18w31a now breaks in 20w21a.