Minecraft Wiki talk:Issues/Weekly 12w19a

Pistons with rails
I've noticed pistons that move a block with a rail on it will drop the rail as an item if moved in any direction except when it is pushed up. I think moving a block without dropping the rail as an item could be useful. I understand that it's similar to moving a block with torches on it (and I'm not saying change that too), but I think it could be useful to someone who wants to implement it somehow.
 * It would be useful for minerails to not be washed away by water, that way, it's like a block on it's own, and can be moved by pistons. If they can construct some way for items to actually be submerged in water but not washed away, that would be great. -- 11:22, 23 May 2012 (UTC)

World names reset
Also, I think world names have been reset to their original names. For example, I had a world named "Flat" that I renamed to "Flat2" before I updated to this snapshot; it now says "Flat" again. No big deal, though.

Aquatic mobs
undefined Passive mobs are ridiculously aquatic. I bred a moderate number of cows, sheep, pigs and chickens (30-40 or so) and left them to their own devices on a smallish island. (About 50x40 blocks in size, just inside an ocean biome). After a time I found that at any time around 90% of the mobs would be swimming about in the sea and only 10% of them would be wandering on land. The other way around would be fine... 22:42, 10 May 2012 (UTC)
 * I am almost positive this is just the mobs randomly moving around. Because you only had a small bit of land and a lot of water, they simply formed a uniform distribution from the point where you kept them. Vote to remove. -- 08:37, 11 May 2012 (UTC)
 * Heh, what a touching faith in the infallibility of random movement. :-) Thing is, I didn't wade out to sea before breeding these guys, so if you're right they should mostly stay clustered about on the areas of grass where I originally bred them. OK, let's allow them 90% on land, 10% in water. But mob movement is independent, so the numbers shouldn't matter, and in practice if I'd only had a dozen mobs, I'd expect all of them to end up in the water quite quickly. Once there, they tend to stay there because "Mobs will stop wandering within 5 seconds if there is no player within a 32 block radius. In this state, they will glance around randomly, but they won't walk anywhere. They can still be moved by other means such as flowing water, minecarts, etc.".
 * Basically, there is a hidden bias in the mob movement algorithm. 'If {mobs} are completely surrounded by grass, they will wander aimlessly', fine. 'If they can't see any grass, they will wander toward light.' That bit means a mob who falls underground will try to get back to the surface where it's light. But if it's equally light everywhere - as it is in lit caves, and on the surface - the mobs once again revert to just wandering randomly, because 'towards light' doesn't provide any guidance. The effect is that if they ever wander randomly too far away from grass, they can't find their way back, and then they freeze in place. Result: Mobs constantly tend to drift away from suitable terrain, i.e. grass, and towards unsuitable terrain such as water, desert, lit caves etc.
 * A refinement to the movement algorithm which would probably fix the behaviour is something like this: 'If {mobs} are completely surrounded by grass, they will wander aimlessly'. 'If they can't see any grass, and light levels are below {some mid-level threshold} they will wander toward light.' 'If they can't see any grass, and light levels are above {some mid-level threshold}, they will try to move uphill or towards shallower water.' 11:45, 11 May 2012 (UTC)
 * OK, so it sounds like you've looked into this more than the "average" submitter does when they submit this kind of thing. Sure, that sounds like there is a flaw in mob behaviour. But its not actually a bug. I would consider it as an annoyance. If enough people agree that it is an issue with the game, we can make it a major annoyance. -- 12:10, 11 May 2012 (UTC)
 * I think that there may be another bias toward ending up in water. Mobs move slower in water and therefore are effectively trapped because their random movements no longer move them very far.  19:47, 11 May 2012 (UTC)

Spawn point generation/placement.
Removed as I could not reproduce this bug with the seed. 07:31, 12 May 2012 (UTC)BrickVoid

Naming of wood blocks
a There is a hyphen in the names of the wooden slabs that does not exist in the names of other wooden things.
 * Names "Oak-Wood Slab" and "Oak Wood Plank" are not only inconsistent (one has a hyphen, the other doesn't), but also a bit misleading: the trees from which this wood comes from are apple trees not oak trees (because they drops apples and oak trees should drop acorns). In addition, "Oak Sapling" grows into an apple tree. Replacing all the instances of the word "Oak" with "Apple" should fix this confusion. -- 20:15, 11 May 2012 (UTC)
 * Actually, they are oak trees. It just so happens that oak trees in minecraft grow apples. 21:49, 11 May 2012 (UTC)
 * In my opinion it's more like : In minecraft Apple Trees look like real-life Oak Trees. Kcin is right, "Oak" should be renamed "Apple" 09:59, 12 May 2012 (UTC)
 * As there is no risk of confusing e.g. 'Oak Wood' with 'Oak Wool' or 'Oak Stone', isn't the word 'Wood', hyphenated or not, pretty much redundant? (And a bit ugly too.) Why not just 'Oak Planks', 'Birch Slabs', 'Spruce Stairs' etc.? (Late thought - if 'Oak' wood was renamed to 'Apple' you would need the word 'wood'. 'Apple Planks', 'Apple Slabs' etc. don't work.) If Jungle Wood was given a more specific name, it wouldn't be needed there either. (Although 'Jungle Slabs', 'Jungle Planks' and so on don't sound too bad to me anyway.) 10:17, 12 May 2012 (UTC)
 * I'm pretty sure that Mojang said at one point or another that they are oak trees but I'm too lazy to find a reference. Anyway, I agree that it should just be Oak Planks, Birch Planks, etc.  22:06, 12 May 2012 (UTC)
 * I have to agree with dropping the wood word alltogether. It sounds nicer, is shorter and gets rid of some repetition. 12:56, 14 May 2012 (UTC)
 * Maybe they using word oak, because they are going to make apple tree for the apples later. WHICH WOULD BE TOTALLY COOL. 12:55, 12 May 2012 (UTC)

Mob movement visually out of sync with actual position.
This behaviour is most common with creepers and is very dangerous because they move and then blow up even after you think you're visually out of range. This is in SSP with the 12w19a snapshot.

I've tried to tackle several creepers one at a time and they almost always blow up if they see me first, this is because the game isn't tracking the creeper's movement in real-time, it first has to send my attack instructions to the server, then the server has to calculate the effect of the attack, and send the result back to the client, thus introducing lag to fighting off creepers.

It used to be possible to knock a creeper back out of explosion range, this just got a lot harder in the snapshot because they now blow up even if you do get out of range and can still deal 1/2 heart of damage because at the time of explosion the server calculated that you were actually in range of the creeper explosion.

I don't think that the sword range is far enough to deal with creepers and they're far too dangerous to tackle in cave systems with anything except a bow outside of their attack range. 01:13, 13 May 2012 (UTC)BrickVoid

Moved:Water source does not generate on top of another water source
undefined When there is a solid block under that space, a water source will form between two water sources. Due to an oversight, this does not happen on top of another water source. As a result, it is difficult to fill in pools and when dealing with water eddies are often accidentally created. 22:51, 12 May 2012 (UTC)
 * I moved this bug here because it has been reposted on other pages with the same critical comments: The water mechanics are that way for a very good reason. If you allowed water sources to generate on top of other waters sources all waterfalls that you might make with a bucket would be permanent. -- 09:13, 14 May 2012 (UTC)
 * Really? I'm trying to visualise how that would happen and I can't. A typical one-bucket waterfall has one water source block. Lots of running water tiles, yes, but only one source. The normal infinite water source trick needs two existing spring blocks, and generates another making three. Torchic's proposal needs three existing spring blocks and generates one more making four. (And in particular, the new addition would have pre-existing spring blocks on three sides anyway, including underneath.) Can you please explain how that unavoidably leads to unremovable 'permanent' waterfalls? -- 00:27, 17 May 2012 (UTC)

Discussion:Time does not pause in Single Player
undefined Time does not pause in Single Player when using the console or main menu. --Techokami
 * Not a bug, SP is server-like
 * It is a bug. ---
 * I do believe Mojang stated they'd do this on purpose.
 * this is a bug and it's going to be fixed. want proof? go to dinnerbones twitter account to may fourth. you will see this: Nathan Adams ‏ @Dinnerbone
 * "The #1 complaint about the new singleplayer that I've noticed is the lack of pause. We *are* adding it back! Maybe for multiplayer too."
 * 12w18a features includes the following (which shows this is not a bug; but because of complaints they are re-adding the pause)
 * "Separated server logic and client. Singleplayer is now a local server.Game no longer pauses when entering a command, writing on a sign/book or pausing the game. "
 * Heh, this is one of the few legitimate examples of a major annoyance. (As per guidelines in .) It should be preserved for posterity. -- 00:32, 17 May 2012 (UTC)

Abandoned Mineshaft
I was playing in singleplayer on the new pre realease (12w19a) and i was in an abandoned mineshaft and i noticed a lack of chests. I went on, and i found a dungeon connected to the mineshaft WITHOUT ANY CHESTS! Is this a bug?
 * No, you were just unlucky. It's unusual to have a dungeon with no chests, but it does happen. About 10% of the time, in my experience, although I don't know the exact odds. -- 03:32, 18 May 2012 (UTC)

Giant mushrooms not growable?
x? In the latest snapshot (12w19a) mushrooms cannot be placed or turned into giant mushrooms, even at night.
 * This is since 1.2.4 and it's a feature. Jeb made it so that you aren't able to place s in a light level that's over 7. Plus, make sure that they have enough space to grow. See . Since this is not a bug, I'm downgrading it to annoyance. <> 09:52, 11 May 2012 (UTC)
 * I'm not sure that the current behavior is intended. I am of the opinion that the inability to grow mushrooms at night is a bug.  The light level in a pitch dark plain is calculated by the game to be 15, which seems like a bug to me.  I'm not going to upgrade to a bug just yet, but if anyone agrees with me feel free to upgrade this to a bug.  19:01, 11 May 2012 (UTC)
 * Looks like I didn't read the last part... ಠ_ಠ anyway, not being able to place them during night time IS a bug. <>
 * Not a bug. Indeed the ability to place and grow of mushrooms at daylight level on gras was a bug. For balancing reasons the placement is not allowed at night. To grow giant mushrooms either make an underground mushroom farm or place the mushrooms on, because that is possible even at daytime. Downgraded and move to Skipped. -- 09:02, 13 May 2012 (UTC)
 * When I tried a spot-check in Creative just now, I couldn't get giant mushrooms to grow from normal ones even deep underground and on mycelium. Tried both red and brown mushrooms too. -- 03:28, 18 May 2012 (UTC)
 * Just dug 7x7x7 space and could grow both mushrooms into giant mushrooms. Light level was zero, planted on dirt, used creative, (height 7 is just the amount you can reach upwards when standing on ground). 14:23, 18 May 2012 (UTC)
 * Retried, worked. Have to assume my first mushroom chamber just wasn't quite big enough. Sorry! -- 23:42, 18 May 2012 (UTC)