Timothy Southwick
- NickNackGus
- nicknackgus
- America/Havana
- Yes
- No
MC-34263![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
Normal
MCL-17255
When loading different worlds (save files), previously loaded map items remain loaded.
What I expected to happen was...:
Map items will display the appropriate content for the world.What actually happened was...:
The first map item of a given ID I open in a world carried over to worlds I open afterwards. In order to view the appropriate map contents, Minecraft must be restarted. The map data is not actually copied to the second world, but appears on the screen as though it was.Steps to Reproduce:
1. View the first map created in a world (save, not dimension. create a new one if needed)
2. Exit the world, but not Minecraft
3. Open or create a second world (save, not dimension), and open the first map in that world. the map from the first world will be displayed instead, same with the 2nd, 3rd ... 9000th map of a world. I used higher numbers for pictures in maps.
4. Maps that were not loaded in the first world, but were loaded in the first will generate as normal, but that bug will carry over to the first and any future worlds
5. restart Minecraft, it will clear the bug. The bug will occur again if you open a second world without restarting. Not tested with servers.
Written book titles use plain text instead of raw json text. I suspect this was overlooked because books use the tag Item.tag.title instead of Item.tag.display.Name like other items.
It looks like almost everything is stored as raw json text in 1.14 instead of plain text. This is nice for a number of reasons - full in-game text formatting support without the section symbol, being able to copy the text using /data modify, not needing legacy text code...
As a side effect of this, attempting to copy a book title to certain other places, such as block/entity names, results in an error:
/execute as @e[type=minecraft:item_frame,sort=nearest,limit=1] run data modify entity @s CustomName set from entity @s Item.tag.title An unexpected error occured trying to execute that commandThis can be confirmed by signing a book and quill, dropping it on the ground, and noting that
/data get entity @e[type=minecraft:item,sort=nearest,limit=1] Item.tag.titlereturns the title as a normal string tag,
/data get entity @e[type=minecraft:item,sort=nearest,limit=1] Item.tag.display.Namereturns the error
Found no elements matching Item.tag.displayand that running
/data modify entity @e[type=minecraft:item,sort=nearest,limit=1] Item.tag.title set value '{"text":"Hi"}'and picking up the book sets the title to
{"text":"Hi"}instead of
Hi
How to reproduce
In creative mode with cheats enabled:
Use a piston to push a blockinto the block occupied by your feet- Place a minecart rail on the block occupied by your head
- Place blocks on either side of the rail so that the minecart will not roll away
- Place a hopper minecart on the rail
- Execute /give @s minecraft:apple (or any other valid /give command)
Expected result
The player picks up the item, and the hopper minecart does not.
Actual result
Both the player and the hopper minecart pick up the item, duplicating it.
Suggestions
- Have the item entity determine when it can be picked up, and which entity/block entity to transfer its contents to
- When an entity/block entity attempts to pick up an item, make a temporary copy of the item stack, attempt to delete the item entity, and give up if the item entity is already deleted
- When any entity/block entity attempts to take an item from an item entity, make the operation atomic - do not allow any other attempts to interact with the item entity until the first attempt is complete
Unlisted video demonstrating the bug
Code analysis
The following is based on a decompiled version of Minecraft 1.12 using MCP 9.40pre-1. – [Mod] bemoty
The /give command puts the item specified in the second argument of the command into the inventory of the player specified in the first argument of the command. With that, it also summons a so called "fake item" with an infinite pickup delay (32767) and an age of 5999 at the position of the player. The issue here is that net.minecraft.tileentity.TileEntityHopper and net.minecraft.entity.item.EntityMinecartHopper don't check an item for its pickup delay, the Minecart with a hopper at the position of the player's head therefore captures the fake item, which it obviously shouldn't.
I managed to fix this bug by creating a public getter for the delayBeforeCanPickup field in the net.minecraft.entity.item.EntityItem class, adding a for-loop to check if the picked up item has a pickup delay other than 32767 to the captureDroppedItems() method of net.minecraft.entity.item.EntityMinecartHopper, and adding a simple if-statement to the already existing for-loop in the captureDroppedItems() method of net.minecraft.tileentity.TileEntityHopper.
net.minecraft.entity.item.EntityMinecartHopperpublic boolean captureDroppedItems() { // ... List<EntityItem> list = this.world.<EntityItem>getEntitiesWithinAABB(EntityItem.class, this.getEntityBoundingBox().expand(0.25D, 0.0D, 0.25D), EntitySelectors.IS_ALIVE); List<EntityItem> list2 = new ArrayList<EntityItem>(); for(EntityItem ei : list) { if(ei.getPickupDelay() != 32767) { list2.add(ei); } } if (!list2.isEmpty()) { TileEntityHopper.putDropInInventoryAllSlots((IInventory)null, this, list2.get(0)); } // ... }net.minecraft.tileentity.TileEntityHopperpublic static boolean captureDroppedItems(IHopper hopper) { // ... for (EntityItem entityitem : getCaptureItems(hopper.getWorld(), hopper.getXPos(), hopper.getYPos(), hopper.getZPos())) { if(entityitem.getPickupDelay() != 32767) { if (putDropInInventoryAllSlots((IInventory)null, hopper, entityitem)) { return true; } } } // ... }How to reproduce
In creative mode with cheats enabled:
- Drop a falling block such as sand into the block occupied by your feet
- Place a minecart rail on the block occupied by your head
- Place blocks on either side of the rail so that the minecart will not roll away
- Place a hopper minecart on the rail
- Execute /give @s minecraft:apple (or any other valid /give command)
Expected result
The player picks up the item, and the hopper minecart does not.
Actual result
Both the player and the hopper minecart pick up the item, duplicating it.
Suggestions
- Have the item entity determine when it can be picked up, and which entity/block entity to transfer its contents to
- When an entity/block entity attempts to pick up an item, make a temporary copy of the item stack, attempt to delete the item entity, and give up if the item entity is already deleted
- When any entity/block entity attempts to take an item from an item entity, make the operation atomic - do not allow any other attempts to interact with the item entity until the first attempt is complete
Unlisted video demonstrating the bug
Code analysis
The following is based on a decompiled version of Minecraft 1.12 using MCP 9.40pre-1. – [Mod] bemoty
The /give command puts the item specified in the second argument of the command into the inventory of the player specified in the first argument of the command. With that, it also summons a so called "fake item" with an infinite pickup delay (32767) and an age of 5999 at the position of the player. The issue here is that net.minecraft.tileentity.TileEntityHopper and net.minecraft.entity.item.EntityMinecartHopper don't check an item for its pickup delay, the Minecart with a hopper at the position of the player's head therefore captures the fake item, which it obviously shouldn't.
I managed to fix this bug by creating a public getter for the delayBeforeCanPickup field in the net.minecraft.entity.item.EntityItem class, adding a for-loop to check if the picked up item has a pickup delay other than 32767 to the captureDroppedItems() method of net.minecraft.entity.item.EntityMinecartHopper, and adding a simple if-statement to the already existing for-loop in the captureDroppedItems() method of net.minecraft.tileentity.TileEntityHopper.
net.minecraft.entity.item.EntityMinecartHopperpublic boolean captureDroppedItems() { // ... List<EntityItem> list = this.world.<EntityItem>getEntitiesWithinAABB(EntityItem.class, this.getEntityBoundingBox().expand(0.25D, 0.0D, 0.25D), EntitySelectors.IS_ALIVE); List<EntityItem> list2 = new ArrayList<EntityItem>(); for(EntityItem ei : list) { if(ei.getPickupDelay() != 32767) { list2.add(ei); } } if (!list2.isEmpty()) { TileEntityHopper.putDropInInventoryAllSlots((IInventory)null, this, list2.get(0)); } // ... }net.minecraft.tileentity.TileEntityHopperpublic static boolean captureDroppedItems(IHopper hopper) { // ... for (EntityItem entityitem : getCaptureItems(hopper.getWorld(), hopper.getXPos(), hopper.getYPos(), hopper.getZPos())) { if(entityitem.getPickupDelay() != 32767) { if (putDropInInventoryAllSlots((IInventory)null, hopper, entityitem)) { return true; } } } // ... }
Bug still exists in 1.7.1, updated version information.
Not a duplicate of
MC-33193. This is about map data of the same ID being shared across save files, not map locations being shared across dimensions or worlds. The screenshots I've attached show the effects of opening one save after another, and the map data being left in cache. The contents of the map appear in the other save, misrepresenting terrain and images contained in maps.Although I do not know any 1.7 servers to test this with, in theory loading a map in single player and going onto a 1.7 server would make it appear as though your single player maps were on the server, and vice versa.
As for Meta's comment, deleting the map data files does NOT fix this bug, but restarting Minecraft does. I agree that it sounds like a feature, saving time in loading maps. However, it sounds like that feature was poorly implemented.
Actually, this bug was fixed exactly on the official release of 1.7.2. I just haven't found a button to close the report.
This bug still exists. Aside from some stone being replaced by the new stone variants, the screenshot could be reproduced exactly in 14w30c. I wonder if this bug is because ravines aren't allowed in river biomes, in which case enabling them would be no different than having ravines in ocean biomes.
It isn't a problem for normal worlds, but it is a problem for mapmakers using /give.
That sounds like it should be a new bug report, assuming other particles aren't causing issues.
Adding to that, if you want it to mount there more permanently, you can add this line the file system tab at /etc/fstab:
/media/home/tim/.minecraft /home/tim/.minecraft auto defaults,nofail,nobootwait,bind 0 2
Keep in mind this issue will affect all worlds in all affected versions. I'm not sure if current/previous versions will be playable after January 19, 2038. It should be possible to test by changing your system clock, however.