Wyatt Jackson
- BillyThePie
- billythepie
- America/New_York
- Yes
- No
8 issues
Key
Summary
Status
Reporter
Assignee
Created
MC-58511![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
Added Attachments:
Added Attachments:
Added Attachments:
Added Attachments:
Added Attachments:
Added Attachments:
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 Wyatt Jackson:
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]
![[Helper] Lord_Quadrato](../../../data/avatars/users/26105.png){kind=small}
Wyatt Jackson Thanks for testing, added your findings to the description.
This has happened to me in singleplayer survival (14w46a). To try to stop the infinite looping, I held a directional button while the world was loading, to try to move out of the portal quickly enough to keep from teleporting back. When the world finally loaded, I had already fallen off the platform my portal was on, and I fell into lava and died. I think this means that the game starts (allowing the player to move, and the portal cooldown timer to start) before the dirt texture loading screen actually goes away.
I really think this bug is two separate problems. One being that portals don't require you to get out and back in to teleport you again. And the other being that the cooldown (and probably the rest of the game) starts before the loading screen goes away.
I was able to reproduce this in 1.13-pre5.
Created a world in 1.12.2; Placed a banner (white with no decorations); Quit game and reloaded world in 1.13-pre5; Broke banner (in survival mode); After a few seconds the game crashed.
I did this several times, in a few different worlds, and it seems to happen to me very consistently. It does not happen if the banner is placed in 1.13-pre5, and it does not happen when the banner is broken in creative mode. But if the banner is placed in 1.12.2 (or some earlier 1.13 snapshots but I'm not sure which ones) and then broken in 1.13-pre5 in survival it consistently crashes for me.
Crash Report: crash-2018-06-30_10.04.18-server.txt
This appears to still happen to baby bees in 19w36a. I haven't seen it happen to adult bees in 19w36a though. See attached video.
I think this might be caused by the block breaking texture (cracks on surface of block), because it never happens to me on blocks that break instantly, such as torches. The game crashed for me when breaking a quartz block with an unenchanted diamond pickaxe, but did not crash when mining quartz blocks with a pickaxe enchanted with efficiency IV (which makes the block break instantly). It also crashed when I was jumping in the air to break a netherrack block, but not when I mined a netherrack block while standing on the ground (both times with an efficiency IV diamond pickaxe). I also tested dirt with an efficiency IV diamond shovel, and the game did not crash, but it did crash when breaking dirt with no tool.
Interestingly though, chests and shulker boxes also do not seem to cause the game to crash, despite the fact that the breaking texture is rendered (albeit incorrectly) while breaking them.
The boat does appear to teleport back to its starting point, but collision with the player still occurs in the where the boat is supposed to be. The boat can be broken or reentered by clicking on the boat in the old location, but the boat item drops in the new location. (See attached video)
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.
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.
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.
But if the maps were created using an online map creator, then the map creator might have been using an older map format. In fact it is very likely they intentionally use an older format in order to be compatible with as many versions of the game as possible, since a lot of servers still use older versions.
The maps I tested on were all created in game, so they use whatever map format matches the versions I listed.
Still happening in 20w22a. If you create a map in 1.13 then load the world in 20w22a, the existing map will be replaced with a blank one.
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:
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.