Ben W
- bedelato
- bedelato
- America/Chicago
- Yes
- No
MC-13559
Low![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
![[Mojang] Panda](../../../data/avatars/users/41658.png){kind=small}
Enchanting with an enchantment table stillsubtracts levels in creativeEnchantment table still deducts levels in creative
Pick block from inventory in creative doesn't preserve size of stacks
Uncertain whether or not this is intended (only Mojang can tell us that) but I'll put this up anyway.
When the "pick block" key (which I map to to left ctrl due to my laptop only having a two-button touchpad) is used in creative mode on a block that you have in your survival inventory (not the hotbar), it takes the block from your inventory and moves it into the hotbar; if the hotbar is full, it switches with the current hotbar slot.
However, when this is done, you end up with exactly one of whatever block you picked, regardless of how many items were in the stack originally.
Steps to reproduce:
1. Be in creative mode.
2. Put a stack of several of one kind of block (say, Grass Block) in your survival inventory (not the hotbar). Make sure there is only one stack of said block, and there is more than one item in said stack.
3. Find the block you chose in the world and use the pick block key on it.
4. The block will appear in your hotbar. Observe that the size of this stack is 1, as indicated by the absence of a number.
5. Open your survival inventory and observe that the stack you originally had is gone.Example:
In creative mode, I put a stack of 64 stone blocks into my hotbar. I place some stone in the world, then move the stack to my survival inventory. I then use pick block on the stone I placed. One block of stone appears in my hotbar; the stack of 64 is nowhere to be found.Notes
May or may not be a duplicate ofMC-13053, as they both involve the "pick block from inventory" feature; however that issue deals with enchantments and names, while this one deals with the sizes of item stacks.
Uncertain whether or not this is intended (only Mojang can tell us that) but I'll put this up anyway.
When the "pick block" key (which I map to to left ctrl due to my laptop only having a two-button touchpad) is used in creative mode on a block that you have in your survival inventory (not the hotbar), it takes the block from your inventory and moves it into the hotbar; if the hotbar is full, it switches with the current hotbar slot.
However, when this is done, you end up with exactly one of whatever block you picked, regardless of how many items were in the stack originally.
Steps to reproduce:
1. Be in creative mode.
2. Put a stack of several of one kind of block (say, Grass Block) in your survival inventory (not the hotbar). Make sure there is only one stack of said block, and there is more than one item in said stack.
3. Find the block you chose in the world and use the pick block key on it.
4. The block will appear in your hotbar. Observe that the size of this stack is 1, as indicated by the absence of a number.
5. Open your survival inventory and observe that the stack you originally had is gone.Example:
In creative mode, I put a stack of 64 stone blocks into my hotbar. I place some stone in the world, then move the stack to my survival inventory. I then use pick block on the stone I placed. One block of stone appears in my hotbar; the stack of 64 is nowhere to be found.Notes
May or may not be a duplicate ofMC-13053, as they both involve the "pick block from inventory" feature; however that issue deals with enchantments and names, while this one deals with the sizes of item stacks.Uncertain whether or not this is intended (only Mojang can tell us that) but I'll put this up anyway.
When the "pick block" key (which I map to to left ctrl due to my laptop only having a two-button touchpad) is used in creative mode on a block that you have in your survival inventory (not the hotbar), it takes the block from your inventory and moves it into the hotbar; if the hotbar is full, it switches with the current hotbar slot.
However, when this is done, you end up with exactly one of whatever block you picked, regardless of how many items were in the stack originally.
Steps to reproduce:
1. Be in creative mode.
2. Put a stack of several of one kind of block (say, Grass Block) in your survival inventory (not the hotbar). Make sure there is only one stack of said block, and there is more than one item in said stack.
3. Find the block you chose in the world and use the pick block key on it.
4. The block will appear in your hotbar. Observe that the size of this stack is 1, as indicated by the absence of a number.
5. Open your survival inventory and observe that the stack you originally had is gone.Example:
In creative mode, I put a stack of 64 stone blocks into my hotbar. I place some stone in the world, then move the stack to my survival inventory. I then use pick block on the stone I placed. One block of stone appears in my hotbar; the stack of 64 is nowhere to be found.Again (I'm unsure) this may or may not be a duplicate of
MC-13053(resolved "Works as Intended"), as they both involve the "pick block from inventory" feature; however that issue deals with enchantments and names, while this one deals with the sizes of item stacks.
Uncertain whether or not this is intended (only Mojang can tell us that) but I'll put this up anyway.
When the "pick block" key (which I map to to left ctrl due to my laptop only having a two-button touchpad) is used in creative mode on a block that you have in your survival inventory (not the hotbar), it takes the block from your inventory and moves it into the hotbar; if the hotbar is full, it switches with the current hotbar slot.
However, when this is done, you end up with exactly one of whatever block you picked, regardless of how many items were in the stack originally.
Steps to reproduce:
1. Be in creative mode.
2. Put a stack of several of one kind of block (say, Grass Block) in your survival inventory (not the hotbar). Make sure there is only one stack of said block, and there is more than one item in said stack.
3. Find the block you chose in the world and use the pick block key on it.
4. The block will appear in your hotbar. Observe that the size of this stack is 1, as indicated by the absence of a number.
5. Open your survival inventory and observe that the stack you originally had is gone.Example:
In creative mode, I put a stack of 64 stone blocks into my hotbar. I place some stone in the world, then move the stack to my survival inventory. I then use pick block on the stone I placed. One block of stone appears in my hotbar; the stack of 64 is nowhere to be found.Again (I'm unsure) this may or may not be a duplicate of
MC-13053(resolved "Works as Intended"), as they both involve the "pick block from inventory" feature; however that issue deals with enchantments and names, while this one deals with the sizes of item stacks.Uncertain whether or not this is intended (only Mojang can tell us that) but I'll put this up anyway.
When the "pick block" key (which I map to to left ctrl due to my laptop only having a two-button touchpad) is used in creative mode on a block that you have in your survival inventory (not the hotbar), it takes the block from your inventory and moves it into the hotbar; if the hotbar is full, it switches with the current hotbar slot.
However, when this is done, you end up with exactly one of whatever block you picked, regardless of how many items were in the stack originally.
Steps to reproduce:
1. Be in creative mode.
2. Put a stack of several of one kind of block (say, Grass Block) in your survival inventory (not the hotbar). Make sure there is only one stack of said block, and there is more than one item in said stack.
3. Find the block you chose in the world and use the pick block key on it.
4. The block will appear in your hotbar. Observe that the size of this stack is 1, as indicated by the absence of a number.
5. Open your survival inventory and observe that the stack you originally had is gone.Example:
In creative mode, I put a stack of 64 stone blocks into my hotbar. I place some stone in the world, then move the stack to my survival inventory. I then use pick block on the stone I placed. One block of stone appears in my hotbar; the stack of 64 is nowhere to be found.Again (I'm unsure) this may or may not be a duplicate of
MC-13053(resolved "Works as Intended"), as they both involve the "pick block from inventory" feature; however that issue deals with renamed blocks, while this one deals with the sizes of item stacks.
Uncertain whether or not this is intended (only Mojang can tell us that) but I'll put this up anyway.
When the "pick block" key (which I map to to left ctrl due to my laptop only having a two-button touchpad) is used in creative mode on a block that you have in your survival inventory (not the hotbar), it takes the block from your inventory and moves it into the hotbar; if the hotbar is full, it switches with the current hotbar slot.
However, when this is done, you end up with exactly one of whatever block you picked, regardless of how many items were in the stack originally.
Steps to reproduce:
1. Be in creative mode.
2. Put a stack of several of one kind of block (say, Grass Block) in your survival inventory (not the hotbar). Make sure there is only one stack of said block, and there is more than one item in said stack.
3. Find the block you chose in the world and use the pick block key on it.
4. The block will appear in your hotbar. Observe that the size of this stack is 1, as indicated by the absence of a number.
5. Open your survival inventory and observe that the stack you originally had is gone.Example:
In creative mode, I put a stack of 64 stone blocks into my hotbar. I place some stone in the world, then move the stack to my survival inventory. I then use pick block on the stone I placed. One block of stone appears in my hotbar; the stack of 64 is nowhere to be found.Again (I'm unsure) this may or may not be intended, and also I acknowledge the possibility that it could be a duplicate of
MC-13053(resolved "Works as Intended"), as they both involve the "pick block from inventory" feature; however that issue deals with renamed blocks, while this one deals with the sizes of item stacks.
The food saturation value (essentially an invisible hunger bar that drains before the visible one
is) is depleted on peaceful, even though the displayed hunger bar never goes down. Hunger values should not be affected on peaceful.Steps to reproduce:
- Eat some food to restore saturation.
- Switch to peaceful and run around for a bit. Eventually the hunger bar will start shaking, indicating that your saturation is fully depleted.
The food saturation value (essentially an invisible hunger bar that drains before the visible one) is depleted on peaceful, even though the displayed hunger bar never goes down. Hunger
valuesshould notbe affectedon peaceful.Steps to reproduce:
- Eat some food to restore saturation.
- Switch to peaceful and run around for a bit. Eventually the hunger bar will start shaking, indicating that your saturation is fully depleted.
The food saturation value (essentially an invisible hunger bar that drains before the visible one) is depleted on peaceful, even though the displayed hunger bar never goes down. Hunger (or any related value, including saturation) should not go down on peaceful.
Steps to reproduce:
- Eat some food to restore saturation.
- Switch to peaceful and run around for a bit. Eventually the hunger bar will start shaking, indicating that your saturation is fully depleted. Indeed, if you switch to Easy or higher at this point, any further exhaustive activities will deplete your hunger bar as if your saturation were zero.
Can confirm, this is not completely fixed in 13w41b. Tried to /give myself block 36 for no reason, on the second attempt minecraft crashed. When I reloaded the world the chunk I was in was completely reset, all changes to it were lost.
My world's fine now, with some tricky NBT editing I managed to restore the chunk in question from a world backup.
Not much explanation needed here. For some reason, the cave generator won't overwrite mycelium in mushroom biomes, which is unexpected as caves will overwrite most other surface blocks.
The attached screenshot is an excellent example of this quirk, as it shows clearly how the generated cave replaced the dirt under the mycelium with air (expected behavior) but left the mycelium intact (not expected).
The screenshot was taken at X=112, Z=5101, seed -787338382, Large Biomes. I have noticed this with a few other cave systems as well (for example, in the same world, at around X=102,Z=4976, there is a giant cave whose ceiling is suspiciously one block thick and made of mycelium.)
PS: I realize the screenshot was taken with a modded Minecraft. I acknowledge this up front, lest this issue (which I have many reasons to believe is present in vanilla) get closed early with a healthy side of boilerplate moderator comments. Because losing on a technicality would suck.
Update 10-30-2013: Due to the new world generator in 1.7, the seed and location provided may no longer valid for 13w36a and later. To confirm the issue for later versions, another mushroom island with a would-be-exposed cave will have to be found.
Not much explanation needed here. For some reason, the cave generator won't overwrite mycelium in mushroom biomes, which is unexpected as caves will overwrite most other surface blocks.
The attached screenshot is an excellent example of this quirk, as it shows clearly how the generated cave replaced the dirt under the mycelium with air (expected behavior) but left the mycelium intact (not expected).
The screenshot was taken at X=112, Z=5101, seed -787338382, Large Biomes. I have noticed this with a few other cave systems as well (for example, in the same world, at around X=102,Z=4976, there is a giant cave whose ceiling is suspiciously one block thick and made of mycelium.)
PS: I realize the screenshot was taken with a modded Minecraft. I acknowledge this up front, lest this issue (which I have many reasons to believe is present in vanilla) get closed early with a healthy side of boilerplate moderator comments. Because losing on a technicality would suck.
Update 10-30-2013: Due to the new world generator in 1.7, the seed and location provided may no longer be valid for 13w36a and later. To confirm the issue for later versions, another mushroom island with a would-be-exposed cave will have to be found.
Translucent block items (e.g. ice, stained glass) now render translucency ( thus fixing
MC-35630) but now there's a new issue. The attached screenshot should speak for itself.edit : The issue is that MC-
Translucent block items (e.g. ice, stained glass) now render translucency ( thus fixing
MC-35630) but now there's a new issue. The attached screenshot should speak for itself.edit: Th
eissueis that MC-
Translucent block items (e.g. ice, stained glass) now render translucency ( thus fixing
MC-35630) but now there's a new issue. The attached screenshot should speak for itself.edit: This issue most likely relates to
MC-1379, and appears to be a special case of that bug, which while being fixed in 13w41a, has resurfaced in 13w42b
Translucent block items (e.g. ice, stained glass) now render translucency ( thus fixing
MC-35630) but now there's a new issue. The attached screenshot should speak for itself.edit: This issue most likely relates to
MC-1379("Transparent t, and appears to be a special case of that bug, which while being fixed in 13w41a, has resurfaced in 13w42b, now that item entities have the ability to show alpha transparency.
Translucent block items (e.g. ice, stained glass) now render translucency ( thus fixing
MC-35630) but now there's a new issue. The attached screenshot should speak for itself.edit: This issue most likely relates to
MC-1379("Transparent texture makes transparent texture behind invisible"), and appears to be a special case of that bug, which while being fixed in 13w41a, has resurfaced in 13w42b, now that item entities have the ability to show alpha transparency.
Translucent block items (e.g. ice, stained glass) now render translucency ( thus fixing
MC-35630) but now there's a new issue. The attached screenshot should speak for itself.edit: This issue most likely relates to
MC-1379("Transparent texture makes transparent texture behind invisible"), and appears to be a special case of that bug, which while being fixed in 13w41a, has resurfaced in this special case in 13w42b, now that item entities have the ability to show alpha transparency.
Translucent block items (e.g. ice, stained glass) now render translucency ( thus fixing
MC-35630) but now there's a new issue. The attached screenshot should speak for itself.edit: This issue most likely relates to
MC-1379("Transparent texture makes transparent texture behind invisible"), and appears to be a special case of that bug, which while being fixed in 13w41a, has resurfaced in this special case in 13w42b, now that item entities have the ability to show alpha transparency. An oversight like this is understandable given this order of changes.
Translucent block items (e.g. ice, stained glass) now render translucency ( thus fixing
MC-35630) but now there's a new issue. The attached screenshot should speak for itself.edit: This issue most likely relates to
MC-1379("Transparent texture makes transparent texture behind invisible"), and appears to be a special case of that bug, which while being fixed in 13w41a, has resurfaced in this special case in 13w42b, now that item entities have the ability to show alpha transparency. An oversight like this is understandable given this order of changes.This does not justify reopening
MC-1379however, as this issue is more specific.
Translucent block items (e.g. ice, stained glass) now render translucency ( thus fixing
MC-35630) but now there's a new issue. The attached screenshot should speak for itself.edit: This issue most likely relates to
MC-1379("Transparent texture makes transparent texture behind invisible"), and appears to be a special case of that bug, which while being fixed in 13w41a, has resurfaced in this special case in 13w42b, now that item entities have the ability to show alpha transparency. An oversight like this is understandable given this order of changes.This does not, I feel, justify reopening
MC-1379however, as this issue is more specific.
Translucent block items (e.g. ice, stained glass) now render translucency ( thus fixing
MC-35630) but now there's a new issue. The attached screenshot should speak for itself.edit: This issue most likely relates to
MC-1379("Transparent texture makes transparent texture behind invisible"), and appears to be a special case of that bug, which while being fixed in 13w41a, has resurfaced in this special case in 13w42b, now that item entities have the ability to show alpha transparency. An oversight like this is understandable given this order of changes.This does not, I feel, justify reopening
MC-1379however, as this issue is more specific.
Translucent block items (e.g. ice, stained glass) now render translucency ( thus fixing
MC-35630) but now there's a new issue. The attached screenshot should speak for itself.edit: This issue most likely
relates toMC-1379("Transparent texture makes transparent texture behind invisible"), and appears to be a special case of that bug, which while being fixed in 13w41a, has resurfaced in this special case in 13w42b, now that item entities have the ability to show alpha transparency. An oversight like this is understandable given this order of changes.This does not, I feel, justify reopening
MC-1379, as this issue is more specific.Translucent block items (e.g. ice, stained glass) now render translucency ( thus fixing
MC-35630) but now there's a new issue. The attached screenshot should speak for itself.edit: This issue is most likely a special case of
MC-1379("Transparent texture makes transparent texture behind invisible"). That issue was fixed in 13w41a. In 13w42b, however, alpha transparency support was added for item entities. My theory is this was a simple oversight when fixingMC-1379, as it was not relevant to item entities when the fix was applied.That said, because this is merely a single special case that only became apparent due to a subsequently added feature, I do not feel that this justifies re-opening
MC-1379.
Translucent block items (e.g. ice, stained glass) now render translucency ( thus fixing
MC-35630) but now there's a new issue. The attached screenshot should speak for itself.edit: This issue is most likely a special case of
MC-1379("Transparent texture makes transparent texture behind invisible"). That issue was fixed in 13w41a. In 13w42b, however, alpha transparency support was added for item entities. My theory is this was a simple oversight when fixingMC-1379, as it was not relevant to item entities when the fix was applied.That said, because this is merely a single special case of a fixed issue that only became apparent due to a subsequently added feature, I do not feel that this justifies re-opening
MC-1379.
Under the precedent set by existing climbable blocks (e.g. vines, ladders) as well as flight in creative and spectator modes, the established control scheme is: jump = go up, sneak = go down (or go down faster), jump+sneak = don't go up or down.
Scaffolding as implemented in 19w04b does not have this behavior. Instead, the jump key overrides the sneak key so that holding both makes the player climb up. To be consistent with the above, jumping and sneaking should cancel each other out when both are held at once.
OS: Windows 10 x64 (version 1809, build 17763.253)
Java:
Minecraft bundled Java (1.8.0_51 x64)CPU: 12x Intel Core i7-8750H @ 2.20 GHz
GPU: NVIDIA GeForce GTX 1060 with Max-Q Design (driver version 417.35)
![[Mod] Asteraoth](../../../data/avatars/users/92886.png){kind=small}
Found a reliable way to reproduce in 1.5.1 creative singleplayer.
If you are viewing the survival inventory in creative mode (the bottom-right tab, with the chest icon), using number keys in the hotbar works as expected.
In any other tab of the creative inventory, switching items in the hotbar with number keys causes the following behavior: After exiting the creative inventory, selecting the hotbar slot corresponding to the pressed number key and attempting to use that item (by right-clicking) causes whatever item is in that slot to be replaced with what was in there previously (i.e. before switching). The contents of the slots do not matter (edit: see below), for example if "2" is pressed over an empty hotbar slot, right-clicking with slot 2 selected will effectively "delete" the contents.
Edit: Further testing has shown that hotbar slots 3 and 7 (i.e. pressing the number keys "3" and "7") seem to be unaffected by this bug for whatever reason.
Edit: If a number key is pressed corresponding to a slot, and the item in that slot is a potion or splash potion, the behavior becomes unpredictable, appearing to depend on many different factors: The item is duplicated as described above, but the behavior on right-clicking varies in complicated ways. Items other than (splash) potions in the affected slot seem to follow the rules above.
After switching hotbar items in this manner (using number keys, on any tab other than survival inventory), the following actions will cancel the effect and revert to normal behavior:
-Exiting and re-opening the inventory.
-Further manipulation of items in the inventory, by any means, including mouse action or number keys; however the latter may trigger the bug anew in addition to canceling the previous effect, if not done on the survival inventory tab.
Pressing the same number key on the same slot twice (or any even number of times) will behave as expected, doing nothing to the items.
Example:
In the creative mode inventory, place a lever in hotbar slot 1, and redstone in hotbar slot 2. Open the creative mode inventory and go to the "Building Blocks" tab (top left, with bricks icon; any tab other than the survival inventory will work.) Put the cursor on the redstone and press "1". Visually, the items will appear to have been switched; there will now appear to be a lever in slot 2 and redstone in slot 1. Exit the inventory screen.
Trying to place a lever (now in slot 2) works as expected.
Trying to place redstone (in slot 1) causes a lever to appear in the hotbar in place of the redstone (effectively duplicating the lever), and for all intents and purposes the game acts as if you had a lever in that slot.
Attempting to drop the redstone (by default with Q) drops a lever instead.
My theory is that it's caused by whatever code makes items not disappear (i.e. be "copied" instead of "moved") when picked up from the upper part of the creative inventory. For some reason, this code is applying to the hotbar slots on these screens too, but only when number keys are used.
Normally, when you are in one of the category tabs in the creative inventory, pressing a number key on a slot in the upper, scrollable part copies a full stack of whatever was selected into the corresponding hotbar slot.
For some reason, when a number key is used on a hotbar slot, the same code is running, causing the item to be duplicated into the specified slot; however, unlike the above behavior, this copies the quantity of the item too, instead of giving a full stack. The client switches the items on the screen, but on the server side what actually took place was a duplication; this doesn't become visible to the player until the client recieves an inventory update.
As for why slots 3 and 7 are unaffected, I have no clue.
Happened to me in 1.5.1. Just started playing around with making a texture pack, and ran into this same issue. It's not a major project of mine, so this is only a minor bug for me, but yeah.
Notably, I found that this is still an issue even when the texture pack I'm trying to modify is not the active one. This is obviously a bug, as Minecraft shouldn't be reading from any pack other than the active one, right...?
As mrheat and C.J. Wijtmans said, the cause is obvious: Minecraft is forgetting to release a lock on the texture pack zip file, and as a result retains exclusive access to the file when it's not strictly needed.
It's a very common file I/O pitfall, and the fix is trivial - just putting a texturePackZipFileObject.close() after loading the pack should suffice.
Happens to me in 1.5.1 when digging straight up (most noticeable on trees).
Most noticeable to me when mining (the sounds play and the XP bar fills, but no orbs are visible; occasionally I'll see one if I'm far enough away), but I have observed with XP from mobs as well.
For me, forcing anti-aliasing on my nVidia GeForce GT 555M causes this issue; however installing Optifine and enabling anisotropic filtering eliminates it.
Can confirm in 1.5.1. Was just about to submit a duplicate of this, good thing I remembered to search at the last minute.
Can't reproduce - flew around the spawn area and found several horses, but none with armor.
Still in 1.6 prerelease.
Still in 1.6.1.
EvilSeph: Can confirm that the changes only apply to new AI mobs. Spiders, zombie pigmen, and Endermen still aggro when attacked in creative.
Johann-Lukas is right regarding the cause.
When they added chests to nether fortresses, they used the same random object to stuff the chests as they used to generate the fortress. The result being that initially the fortress will generate the same as before... until it creates a chest, at which point the RNG will get thrown off, creating an entirely different fortress from that point on.
I also agree that there is no way to fix this. The damage has already been done, the best course of action now is to just move on.
Affects 1.6.2.
Seems to affect only the first slot in my screenshot... Why? Is it a quirk with the particular filter I'm using (the "blobs" one)?
Works as intended!? Come on, those trees look horrible,
I can confirm this too. 64-bit Java 7 on 64-bit Windows 7. Graphics card is an NVidia GeForce GT 555M, not sure if that's relevant.
It appears to still affect 13w39a.
Can confirm for 13w39b. It happens for me when just placing the item in the frame, no rotation needed.
If you ask me, all appearances point toward this being an intended feature.
Cannot confirm for 13w41b, appears to be fixed. The custom name appears and disappears as expected.
Can confirm, this is not completely fixed in 13w41b. Tried to /give myself block 36 for no reason, on the second attempt minecraft crashed. When I reloaded the world the chunk I was in was completely reset, all changes to it were lost.
My world's fine now, with some tricky NBT editing I managed to restore the chunk in question from a world backup.
Still affects 13w41b. Tried to /give myself block 36 for no reason, on the second attempt minecraft crashed. When I reloaded the world the chunk I was in was completely reset, all changes to it were lost.
My world's fine now, with some tricky NBT editing I managed to restore the chunk in question from a world backup.
I commented on
MC-32880with this story also, found that one first.Can confirm for 13w42b. Probably has something to do with whatever they did to the rendering engine to make it show only the forward faces of stained glass etc.
Appears to be fixed in 13w42b. Both stained glass and ice item entities render translucency. However translucent blocks don't show behind translucent items...
Edit: I've submitted the second issue as
MC-35920.Still present in 13w42b. Since your level isn't visible anymore in creative mode, a few more steps are required to observe. But I can confirm that it is present. I've updated the affected versions.
Maps align to the same grid on all zoom levels. A 1:1 scale map is 128 blocks across. So if you're at 1:2 zoom, you need to go 256 blocks away in order for the maps to align correctly.
Confirmed for 13w41b. I know that snapshot's outdated, but the fact that this is not a new bug deserves mentioning. Switched from my survival world (where I'm working on creating a "map board") to a creative superflat (where I happened to be experimenting with maps.) Brought out a map and it turned out to show part of the other world.
Edit: ...additionally confirmed in 1.7.1. Further experimentation shows that it does not actually overwrite any map data, but rather it appears to be re-using the maps from the previously loaded world. This happens when a map item in the second world has the same damage value as a map that exists in the first one - the game incorrectly loads and displays the map data for the previous world instead of the data for the current world.
This has happened twice to me now, both times while viewing a chest. Cannot reliably reproduce.
Th3F4114n0n3: I think this is an oversight with the fix for
MC-1379- this wasn't an issue before, because item drops didn't use alpha blending until 13w42b.Ezekiel: Yes, still affects 13w48b, just checked. Added to affected versions.
Affects 1.7.4. Unpausing the game replays the last raised sound event. It's very annoying.
It appears to be related to timing — if I pause the game just as the sound is ending, I can reliably reproduce.
Cannot confirm in 1.7.4 release. Arrows shot from a /summon'd skeleton in singleplayer, as well as those shot from an infinity bow, were able to despawn normally.
Appears to have been partially fixed as of 1.7.4. A ceiling of slabs, as in the second and third pictures, now behaves as expected in most cases from what I have observed.
I'm surprised that even with the overhaul to enchantment tables in 14w02, they somehow overlooked this.
Consider reopening - 1.14 seems to have regressed. Portals in my world which worked "correctly" in 1.13.2 and prior now exhibit different player facing behavior.