You'd better read the instructions before posting an issue or modifying this page, lest raptors from the depths of the intertubes attack you and devour your liver. Also, spellcheck and the talk page are your friends, as are research, diligence, and Jeb.
Please do not spontaneously delete an issue report or comment, unless it is patent nonsense submitted by someone who has not logged in. If possible, contact the submitter by user-talk first and tell them about your concerns. They will almost certainly oblige. As always, assume good faith.
If you're unsure of an issue, it's good practice to post about it on the talk page to see whether others can reproduce it. Make sure you're testing the bug in the correct version (for this page, that's 1.0.0) with no mods installed. Also, make sure to proofread your issue report before submitting it; unintelligible issue reports come off as inconsiderate and disrespectful. Finally, please determine which game mode(s) your issue appears in, and flag it with the appropriate label(s).[1] (Also, note that if, for example, a minor annoyance appears in both single-player and multiplayer, and in both creative and survival modes, you should label it as [A], not[A][SP][MP][Su][Cr].)
Be sure to sort issues by category, type, and priority: redstone issues go in the Redstone section, etc.; bugs go in the Bugs subsection, with major bugs listed before minor bugs, annoyances in the Annoyances subsection, with major ones before minor ones, and issues that Jeb has marked as fixed or skipped are moved to the Fixed/Skipped section. Issues that Jeb cannot reproduce, however, are to remain in their original place.
Please sign all issue reports and comments by typing ~~~ (three tildes; tilde may be found above Tab ↹ on USA keyboards, and to the right of @ on British keyboards).
There is no need to place bullet points before issue labels. Use bullet points only for comments. Be sure to leave a single totally blank line before each new issue (but not before comments), unless the issue appears directly beneath a header.
Issue Labels
Please mark your issue with one of these issue labels: (listed from highest priority to lowest)
[!!] = {{bl|!!}} = Critical bug that can crash a Minecraft client or server.
[!] = {{bl|!}} = Major bug. Use this tag sparingly; if there is consensus your bug is not major, it will be downgraded.
[A!] = {{bl|a!}} = Major annoyance. Think very carefully before flagging an annoyance as major. Is it really more important than most minor bugs? Use this tag sparingly; if there is consensus your annoyance is not major, it will be downgraded.
[X] = {{bl}} = Minor bug.
[A] = {{bl|a}} = Annoyance.
[?] = {{bl|?}} = Potential issue that you are unsure of or that the community (on the discussion page) believes requires further vetting. Note: do not use this label to indicate this-is-not-a-bug; instead, replace the issue's current label with [A] or [A!]. Furthermore, it is inappropriate to use this to flag something you disagree with; instead, express your opinion in a comment. When you apply this label to an issue, place it after the issue's existing labels; do not remove those labels.
Labels for indicating that an issue happens only in a particular game mode: (These labels cannot stand alone; you must use them in addition to, not instead of, the ones listed above.)
[SP] = {{bl|sp}} = Single-player.
[MP] = {{bl|mp}} = Multiplayer.
[Su] = {{bl|su}} = Survival mode.
[Cr] = {{bl|cr}} = Creative mode.
Labels for indicating that an issue is restricted to a particular OS:
= {{OS|OSX}} = Mac OS X
= {{OS|Win}} = Windows
= {{OS|Linux}} = GNU/Linux
Labels that Mojang (not you!) uses: (Please place these tags in front of existing issue labels; do not remove the existing labels.)
[F] = Issue for which a fix will appear in the next update.
[N] = Not a bug; intended behavior. By definition, this label is inapplicable to annoyances; annoyances are not bugs.
[S] = Issue that will not be fixed in the next update.
[U] = Issue that Mojang has tested but was unable to reproduce.
To produce these labels, use the following code: {{bl|c}} where c is the code of the label you wish to use. (e.g., a for annoyances, etc.)
The default issue type is minor bug; you can produce this label with the shorthand {{bl}}.
Redstone and Pistons
Bugs
[!]Piston Quasiconnectivity Bug, Revisited A piston can be powered by a block that is not directly adjacent to it, but diagonally above or 2 blocks above, but changes to these blocks will not propagate updates to the piston*. Nevertheless, when the piston is caused to update by other means, it will take into account the state of these nonadjacent blocks. See this image for a better description along with a visual explanation.
The same applies to powered rails.
(Please do not delete this bug or this comment. It's fine if you disagree, but deleting is immature and petty.) Jeb marked this bug as skipped a while back, but since time has passed and new evidence has come up, I would like to ask him to reconsider. I've stated my reasoning here; please leave any comments you may have there so as not to clutter up this page. Jeb, please read before deciding. ;) —Immute [talk]
I really hope he reads your statement, it sums up the facts very well!
[!][MP] Using /time set will cause redstone torches to burn out.
When using a clock circuit on an RC2 test server, the circuit contained an inverter in which the torch failed to light after approximately 5 cycles after the /time set command was issued. Reproduced the bug multiple times by deleting the world and recreating the clock.
The circuit was tested at varying times between 10 minutes and 1 hour before the command was issued in each test, never failing until after the /time set command was issued.
How to reproduce:
Make a simple clock circuit containing an inverter(or even just a torch that turns on and off with each cycle)
Allow the circuit to run for a few minutes to verify the torch is stable.
Issue a Time Set command to the server.
Observe the torch failing to function within a few cycles of the command.
Replacing the torches causes them to burn out immediately in one cycle, but if the circuit is left in place for approximately 15 minutes the circuit will begin functioning again.
[F] Trapdoors do not close if powered by a repeater. Same with a repeater powering the block a trap door is connected. If you power the repeater the trap door will open. If you unpower the repeater the door stays open.
They also stay open if they are being powered by an adjacent torch which is then removed. --Hersmunch
[!] Piston can "burn out" in a state simultaneously powered and un-powered. When it's in this state, it can be repaired by destroying the extended piston head. This will destroy the extended piston head but not the rest of the piston. --Munin295
To reproduce: The image shows two different 1-clocks (powered by the same torch). If you attach a piston and block to the right 1-clock, it works fine. If you attach a piston to the left 1-clock, it works fine until you add a block—then it "burns out" in a state that appears to be both powered and un-powered. It's then actually possible (in Cr at least) to reset the piston by destroying the extended arm (without destroying the piston). --Munin295
Another way to reproduce the same bug. (the torch is on the ground, not attached to the block with the redstone.) --User42
[!] If you build a Gravel/Sand tower(> 2 blocks) on a Piston (connected to a clock) most of the Gravel/Sand will disappear after a couple of pushes. (Update: instead of disappearing they will plop as item instances) This is especially annoying when trying to build sand/gravel doors.
"Upgraded" to Major annoyance because this bug ruins a lot of piston creations.
Appears in both SP and MP
this has been happening for quite a while already (don't remember when i first saw it; 1.8? i've only played since 1.7 and didn't build anything that would have shown it), so it's not due to some recent change. Piranha
Pretty sure this is done intentionally to address the sand / gravel duplication bug with piston and sticky piston... As a result of that, we are left with this unfortunate side effect. Chiisana
Worked hours on a huge gravel door just to find out the gravel vanishes when the door closes oO
I'm not sure if this is a bug, it's probably just because the pistons are partially extended and the gravel lands on a partial block (such as signs, torches, slabs, etc...)
[S]Skipped because this was a side-effect when removing the gravel/sand duplication bug. /jeb
[X] If a piston is powered but cannot extend because of the amount or types of blocks in front of it, the piston will still not extend after the blocks have been removed, even if its power source remains. (this should become a major bug, not a minor one, as it could mess with auto building bridges and other devices that use a piston's max push amount. This could break a lot of things!)
[X] When walking into a solid block and onto a redstone repeater while standing in an area that is two blocks tall, the player falls into the block beneath the repeater.
Can fall through 1 block high floors occasionally.
[U]Tested in both single- and multi-player /jeb
[X] Redstone repeaters can prevent the player from entering areas that are two blocks tall, but it is possible to step onto repeaters while already standing under a low ceiling.
Are you sure this is a legitimate bug? The Repeater takes up some space in the front, but the arrow behind it allows walking, I'm probably misinformed please correct me if I am.
Yes it is. Same with trapdoors. Don't know, if it should be fixed, it allows you easy one-way doors. — MiiNiPaaT|C
[X] Sticky pistons can be used to pull minecart rails off of the ground.
[X] If you put some redstone, a lever and redstone torch like this: http://i.imgur.com/RKjjC.png the torch doesn't invert when you flip the lever, and when you flip again it makes a fast pulse.
Is it only on Survival, or does it happen in Creative too? MrNintendoMan 10:13, 26 November 2011 (UTC)
[X] If a piston in a BUD state is updated by placing a piston that is then pushed or pulled by the BUD piston it will turn in to a block which is rendered in ever direction as the piston head. (Some Examples: http://i.imgur.com/Ox0Yg.png) --Incanus uk
Confirmed and I would like to add that the mis-rendered block does not drop a piston when broken, which leads me to believe its deeper than just a rendering issue and the block actually changes. -kiba_urufu
[X] Standing next to an elevated pressure plate (such as those used to generate tables in the villages) will activate it.
No; what happens when you bump into a table in real life? This behavior is useful for detecting players in minecarts during a vertical descent.
Agreed. This behavior should be left as is. —Immute [talk]
[X] If a chunk is unloaded whilst a wooden pressure plate has an item on it then it will stay in the on position forever, Jeb fixed it for logging out and back in but it still happens for chunk unloading when moving farther away.
[X] Pistons don't respond to block updates caused by another piston directly popping a block by extending. This bug can be exploited to make a directly powered piston BUD. There is a video example watch?v=VXX98KedPGc --Incanus uk
[F] Redstone Repeaters cannot power dispensers (block can actually pass power through it but no dispensing happens), the top half of doors, curved rail and TNT. This is most obvious if using a repeater to power a block adjacent to one of these blocks. If there is any redstone wire or torches within two blocks of the dispenser/door/rail/TNT and a block update happens either next to the dispenser/door/rail/TNT or the redstone gets an update then the dispenser/door/rail/TNT will be activated. For the TNT see this video: watch?v=zJ0TLeVV_PA --Hersmunch
Annoyances
[A!] Redstone materials can no longer be placed on top of glowstone.
Known_bugs/Version_1.9pre6#Blocks scroll down to "Fixed/Skipped/Non-Bugs" and find jeb's comment. — MiiNiPaaT|C
It still breaks tons of great lighting designs and should be reconsidered.
That's secondary; it contradicts Notch's decision to make them into stone type in 1.6.6, so it must be reconsidered. Chiisana
[F] Fence gates do not respond to redstone signals.
[A!] If you lay in a bed and then break it whilst still when you walk into any walls you get hurt
[A!] If you are sleeping in a bed and then the bed gets pushed by a piston then you can walk into walls and take damage,also cant climb ladders, can be fixed by saving and quiting.
[A!] Selection of ladders is problematic in 1.1 [1]
[A!] When a sticky piston is moved by another piston, the block that should be stuck to it does not move.
This issue is a legitimate annoyance (note that I did not call it a "bug") because it was a feature of the Piston Mod, and a very reasonable one at that. I suspect that its non-inclusion was either a mistake or an act of laziness. :P (Hence, do not delete this issue please.) The status quo makes absolutely no sense and serves no purpose whatsoever. The rule for which blocks a sticky piston should pull back should be the following (in pseudocode): (—Immute [talk])
def computeHowManyBlocksToPullBack(extendedHeadLoc: Vector, stickyPistonDirection: Vector): Int = {
var ret = 0
var currentPos = extendedHeadLoc + stickyPistonDirection //start withblock right in front of the retracting head
while (ret < 12 && world.getBlockId(currentPos) == StickyPiston.Id
&& !Piston.isExtendedPiston(currentPos)
&& Piston.getDirectionOfPistonAt(currentPos) == stickyPistonDirection) {
ret += 1
currentPos += stickyPistonDirection
}
if (ret < 12) {
val finalId = world.getBlockId(currentPos)
if (finalId == Piston.Id && !Piston.isExtendedPiston(currentPos))
ret += 1
else if (Piston.canMoveBlockOfId(finalId))
ret += 1
}
return ret
}
[A!][!] When you stay on a pressure plate that opens double doors, they both go open, but if you no longer stay on it, only one door closes.
[A] Redstone doesn't point towards pistons. Mojang should make redstone point to pistons
[A] Redstone torches tend to make sizzling noises if it is turning on and off very quickly(> 2 ticks).
Achievements
Bugs
[F] The "Sniper Duel" achievement does not register when completed.
[N] Throwing leather on the ground, then collecting it earns the achievement for killing a cow. 188.238.159.215
It is called "harvest some leather", not kill a cow. --77.160.32.204 16:36, 23 December 2011 (UTC)
[N] The "Getting Wood" achievement is obtainable under any circumstance where a block of wood is collected, rather than only from destroying a block of wood. 188.238.159.215
not sure if already discussed but for "Getting wood" it seems to be the right behaviour, if it were named "Harvesting wood" I'd agree. 87.168.51.129 13:00, 9 December 2011 (UTC)
"Getting wood" means you get a wood block. it doesn't automatically mean that you MUST chop down a tree to get wood. --77.160.32.204 16:36, 23 December 2011 (UTC)
[F] Game crash,if you open the achievement page with Italian language (Week 49 Snapshot)
Should this be upgraded to "Critical"? 70.67.15.67
The game does no longer crash, but still can't display invalid strings. Fixed the error in the Italian translation. /jeb
[X] None of the interfaces like achievements, statistics, workbench, furnace, etc..., are translated in Latinoamerican Spanish. (Not very much a bug)
when you are putting down seed on farmed land (dry/wet) the seed some times dissuader and you lose your seeds pumpkin/water melon/seeds (it has been like this from 1.8 pre and it is so annoying)
you mean disappear? That happens when there is not enough light for the plants to grow. Put some torches up. --temotodochi
[X] When having enchanted items in a minecart with chest, and you destroy the minecart with chest without removing the enchanted items, the enchantment on the items can be lost.
Credits
Annoyances
[A] It's not obvious that pressing Esc will skip the credits. Add a "Esc to skip" note to show players it can be skipped, and prevent players who want to see it from accidentally pressing Esc. This feature is in many other video games where cutscenes are skippable.
Blocks
Bugs
[!] Glass Blocks hold dropped items(to be picked up) but they make get to unreachable places-delete or edit as necessary
Can you explain? Shellface 19:10, 12 January 2012 (UTC)
[!] Interesting terrain generation, seems like part of a nether portal, and a few hundred dragon eggs, causes game's memory to rocket ( up to 1.5gb from normal of about 300mb) pic @ http://tinypic.com/r/2mxixzl/5
running on a server, but world was ported from a single player world created in 1.0. Seed and location are shown in the image ~~ChrisPDuck
[?] Rarly, trees generates on sand blocks, beside the dirt. (Only Pine Trees?)
[!!] When loading world which has blocks ids which are not in minecraft (mods, etc.) minecraft crashes. Instead a failsafe like filling those non-existent blocks with air (id 0) should be provided.
If that were to happen then the modded world would be destroyed upon saving, It's better it just crashes. --Joshua
It would be more robust if an "unknown block" type block were created. The block id would be preserved -- any unknown block would be displayed as a generic, easily destroyable "unknown" block. Maybe with the id printed on it. That way you could remove a mod without loosing the ability to use the world. And no crashes. --Eleazzaar 01:26, 12 December 2011 (UTC)
Possibly, Notch could add a msg saying "Unknown blocks types have been detected in this world! (Mods?) Would you like to let them remain as transparent blocks or delete them?" -- OpToCo
Why don't you remove all mod blocks by yourself before uninstalling that mod? This way you could persevere until the fix is out.
[!] Soulsand no longer holds minecarts in place. Before you say "that behavior made no sense," remember that soulsand is 15/16 m high (try walking onto it from a normal block). Half slab holes most certainly do hold minecarts in place, so soulsand should too. Many engineers have made useful mechanisms that rely on this behavior, so it should not be removed. (Jeb made this argument for keeping the Piston Quasiconnectivity Bug, so it must apply here as well; if not, the argument was invalid when it applied to the piston bug too.) —Immute [talk]
[!] With a set of double doors, clicking the left door opens the right one (though clicking the left door again then opens it). Additionally, with both doors open, clicking the right door closes the left one first.
It's a new feature. If you click on the left door twice both will open, if you do it again on the right door both will close.(this is if you are outside)(I.E click on the left twice both left and right will be open, then click twice on the right and both will close.(its the left from the outside for opening and the right on the outside for closing, from the inside its right for opening and left for closing.))(i use this all the time now!(handy for spiders))
Evidence? This feature seems highly improbable, since opening double doors by hand has never been a problem (interaction with redstone is the problem). Moreover, new behavior is nonsensical. I suspect that this new behavior is the result of a slightly botched fix to the "wooden doors can't be opened by hand" bug, as are the new problems with hatches. Recommend changing tag to [!]. —Immute [talk]
It's very confusing. Certain constructions are impossible now. --Mrheat
[X] When a door is open and you right click to place an item on the first block beyond the door (i.e. click through the open door) the block/torch/etc is placed but the door also incorrectly closes.
I can confirm this. I think this is related to the new (but confusing) behavior of doors. Clicking a door sometimes opens or closes an other door instead of the door you clicked. --Mrheat
[X][MP] Chests sometimes don't close after being opened, persists through client restart Cboz718
If you quit and reconnect, the chests reopen themselfs. 92.25.55.58 22:00, 2 January 2012 (UTC)
Chests will always become stuck open if they are right clicked more than once before the chest interface appears. They will stay open until the server is restarted. 71.3.251.252 20:48, 10 January 2012 (UTC)
[X] Closed fence gates STILL have their collision boxes as the entire cube.
In addition to this, blocks where multiple fences meet (corners, for example) also take up the entire block with their collision box. Invisibool
I think it's only from inside of the corner, isn't it? --Kimitsu 05:31, 24 November 2011 (UTC)
[X] If you hit the exact corner of a block, you sometimes go into that block
[X] If a bed is placed next to a drop off or transparent block, you sometimes fall out of the bed, taking fall damage if the drop is tall enough
[X] Beds, levers, fire, signs, wooden/iron doors cannot be placed on snow (should replace the snow like all other blocks do).
[X] Enchantment Tables cannot be blown up with TNT.
I don't see how this is a bug. They're made out of 4 blocks of obsidian. I'd expect them to be almost invincible. –ultradude25(T|C)
Agreed. Anyway, going from one extreme to the other is Notch Trolling 101.--Inertia
I only put this as a bug because the fact enchantment tables can be so easily mined, despite the "4 obsidian blocks" as you so aptly put. Unless it's protected by magic...
Would youprefer for it to take 9 seconds to mine an Enchantment Table, which is a helluva lot more useful than Obsidian?
[X] A melon can be placed onto the side of a block when there is nothing beneath it. Pumpkins can only be placed where there is a block underneath.
[X] Sometimes a generated light torch is facing the block that it should be connected. pic http://i.imgur.com/gAyqX.png
[X] Dead bushes cannot be collected with shears.
[X] When in a stronghold. When a torch is placed on a Smoothstone block, the block will change to any 3 of the stone Brick (normal/mossy/cracked) Happens around 80% of the time
Did you observe this on SMP in a newly generated chunk?--Inertia
[X][MP] Only in SMP you can't write on a sign that is on/near a block that is periodically been updated. To reproduce, make a simple clock with a redstone torches and a repeater. Then put a sign on the block of the torches. Any text will be erased at every block's update.mooviies
this happens even if the block isn't being updated, but you are looking at any blocks being updated that are in the background. Jamslambs
[?] When you shoot a bow, the green bar displays that is has durability, but the durability is endless so it shows a full green bar once it has been shot.
Unable to reproduce. Durability goes down with each use for me. — MiiNiPaaT|C
I am able to recreate the endless bow durability. Possibly SMP related. Perhaps it happened because I carried two bows (only used one, the other was a backup). There's a remote possibility it's Nether related. I'm not sure if the Nether has anything to do with it, but I was particularly conscious of my bow's condition while in the Nether. I never needed to use my backup bow no matter how much I used my primary one. Went through at least three stacks of arrows.--Inertia
[SP][MP][Su] Blocks that are broken adjacent to tilled plots cannot be picked up if elevated by another block from a 1x1 hole. The broken block is then attracted and attached to the tilled block until the replaced, blinding block has been removed.
Can't reproduce this. Was it MP or SP? --Samman412 01:12, 18 December 2011 (UTC)
I confirm this in SP vanilla minecraft 1.0.0. Dig a 2 deep hole in dirt leaving the dirt block items in the bottom, use a hoe on the surrounding eight dirt blocks and place one opaque block at the bottom of the hole: the dirt block items will rise to the top of the opaque block, but place a second opaque block on top and the items do not rise up further - they get stuck inside one of the tilled earth blocks. Generally non-opaque blocks such as tilled earth, slabs, stairs, glass, and ice do not displace items. I have just now re-tested tilled earth, wood slabs, cobblestone slab, and ice blocks (100% legit) still do not displace items in 1.0.0 vanilla. -Aurelius 16:19, 22 December 2011 (UTC) See my updated getsatisfaction thread at http://getsatisfaction.com/mojang/topics/items_displaced_by_halfsteps_are_not_pickupable_in_smp where I again confirm the problem with SMP reported in Beta 1.6.5 still exists in release 1.0.0 - I also retested cobblestone half slabs which still demonstrate the same bug in [SP][MP][Su] .
[!] In all game modes, when a block is removed from under a fence, a floating block you can pick up gets stuck under the fence. Now, when you place another block under the fence, if there is nowhere for the floating block to move, the block will jump up and get stuck in the fence, blacked out, unobtainable - especially if there are multiple floating blocks you can obtain.
Also, the same thing happens with glass - when a block is floating in a 1 block hole and you place a piece of glass in the hole, the floating block gets stuck in the glass, unobtainable.
[!] Explosions at or above the top layer of a map, especially from TNT propelled upwards by adjacent explosions, cause damage to the bottom of the map. These explosions damage bedrock and expose the Void, and cause server instability or crashes.
[X]Lily Pads break boats upon contact, making exploring ocean hazardous.
They're solid blocks. This happens with all solid blocks. HotdogPi 01:09, 24 November 2011 (UTC)
If anything, the bug is that boats are even more breakable in 1.0 TheCakeisAlive 19:32, 24 November 2011 (UTC)
[X] When you dump water from your bucket on a Lily Pad, it doesn't drop and the water floats on the space above where it used to be.
This happens with lots of other small blocks such as flowers, torches, long grass etc. too. --Hersmunch
[X]Lily Pads can be placed on water intersecting the player (e.g. in 1-block deep water you are standing in), unlike other blocks which cannot be placed if they would intersect the player. KPReid
[X] When some blocks are checked to see what their bounding box is they are able to set the bounding box for all blocks of that class. More details here. --Hersmunch
[X] When a half slab is on top of an ice block, walking on or throwing items on the half slab will make them slide across as if they were directly on the ice. 77.167.233.98 18:25, 12 December 2011 (UTC)
[X] Crouching while on top of a cake does not prevent you from falling over the edge, particularly when the block below the cake has air on the side you are moving to.
Crouching isn't supposed to prevent players from falling. Crouching only makes players move slower, making it easier to walk to the edge of a block without accidentally going too far.
Is there any source for this claim? This page says it's intended, and it does keep me from falling off every other block type I've tried. Orthotope
Crouching doesn't prevent you from falling less than one block. Always been like that. Shellface 19:10, 12 January 2012 (UTC)