Minecraft Wiki talk:Issues/1.1

Redstone repeaters
Since about 1.5 in smp it seems that Redstone repeaters don't update their state properly if the signal leaves the current chunk. I have tried in in 1.1 and the problem is still there Easy way to see this is make a U from where you are standing that is about 12-14 full lengths of redstone and repeaters (15 pieces of redstone and a repeater at the end) in each direction then just place a torch at the start of the U and you'll see that the signal dosent make it out of the chunk. there was an improvement from RC2 to now but the problem is still thereMatkam

Falling into one-deep water from height not always fatal
Tested on an up-to-date SMP server. Randomly fell into a one-deep pool of water from a normally deadly height and survived. After some testing, determined that survival alternates... jumping off from a ledge at an odd y-coordinate or walking off from an even-y, I survived; walking off from odd and jumping from even, I died. Did not seem to effect fall damage onto ground, just water. Deeper water was normal. --Patteroast 13:05, 13 January 2012 (UTC)

Should "Typos" be a subsection under Language Bugs?
And if so how should we mark them (annoyance, minor bug). Also edit here for possible layouts of typos:

1. Language (Language Abrv) - "mispelled word/phrase" -> "correct word/phrase"

Ex. English (UK) - "Lava bucket" -> "Lava Bucket"

World generation
I found what I consider to be a major bug in the world generation code concerning mineshafts and dungeons that hold mob spawners. This applies to single-player and perhaps multiplayer maps generated with the default server files but I do not play multiplayer much nor do I run a server, and I cannot verify the impact it would have on multiplayer servers.

Whenever any part of a mineshaft intersects with a spot where a chest would be generated for a dungeon's mob spawner, that chest may be deleted but the contents of it will spill out onto the floor of the dungeon.

This was found while I was browsing a map in MCEdit and looking for my home, and I confirmed what was happening by moving my character down into the dungeon to see what had happened. Interestingly enough, the player would not know that a chest had popped out of existence unless they had some kind of mod that alerts them to this happening.

The reason I call this a major bug is because records can be generated in dungeon chests and this bug would unintentionally rob players of their chance to loot that from the dungeon chest had it not been deleted by a mineshaft.

There are other interactions concerning mineshafts and chests that should be examined: For instance, if the world generator wants to place a mineshaft chest where a dungeon chest is, the chests may not be generated, deleted outright, or have contents spill out, as I have noticed other instances where there are items lying about in worlds I'm checking out in MCEdit.

BrickVoid


 * I disagree with this. I don't think it's really bad behavior. It would be one thing if dungeons were limited, but due to the random nature of Minecraft, there will always be more to discover. A dungeon without a chest is a risk that you have to take sometimes, and I don't feel "robbed," I just assumed dungeons sometimes spawned intentionally without chests. Now knowing the cause, I think leaving the behavior as-is is perfectly fine. ImJake9 00:30, 16 January 2012 (UTC)
 * By your statement above, we will forever be forced to live with the curse of bugged terrain generation code, this is not what I think Mojang should be encouraging. I strongly disagree with your statement above.  Terrain generation code should be robust, complete, and not subject to accidental deletion of intended map features.  Dungeon chests are one such feature, and I will not rest until this bug is fixed.  BrickVoid
 * I still disagree with you. You see, let's say this is fixed. If that happens, then ALL dungeons will have chests. I don't think that's good. I like the risk of having some dungeons with no chests. So, I'd support a small chance of no-chest dungeons. In this case, though, it isn't necessary, since a bug causes unintended behavior that is nevertheless beneficial. ImJake9 01:37, 17 January 2012 (UTC)
 * Unintended behavior is not beneficial therefore your statement above has no meaning. I would not support any chance of dungeons that do not have one or both chests because of a bug that deletes them which is the point I'm trying to get across.  If Mojang wants to deliberately write code which decides if a dungeon gets up to two chests, then that is fine, however, a bug causing deletion of a chest a different code section of the terrain generator added is not okay!  Get it now? BrickVoid
 * No, I don't. I fail to see how two pieces of code that produce the same effect can be good/bad depending on how the code is implemented. Many games have unintentional code that is never "fixed" because the "bug" was unintentionally causing behavior that the devs liked anyway. Sure, maybe some fine-tuning is in order, and the items dropping out is weird, but this feels more like an annoyance than a bug. ImJake9 00:59, 18 January 2012 (UTC)
 * And that's why unintended behaviour is not benficial. Let's say Mojang reuses the same piece of code that makes abandoned mineshaft tunnels to make new terrain features, and that they've added other terrain features as well in the meantime.  Then they find out that it deleted one of the other features they've already implemented and because a lot of people liked those features, they end up having to go back and fix the original bug that unintentionally deleted these chests.  It's never a good thing to have to rewrite code you thought was bug free because of a bug it had that you only found out about much later.  Preventative measures are best taken early and no good programmer would ever let bugged code lie unfixed.  Also, this should be considered a bug because chests are an entity and world generation code should not be going around deleting entities randomly anyway!BrickVoid

Problems with animals (sheep etc), baby animals and fences
There is currently a reported problem where mobs (including sheep, cows etc) are able to escape fenced areas. This appears to have become worse with the introduction of baby animals.

To test build a fenced area and add animals, any kind. They will bounce as if on springs to the top of the fence. It does not matter how high the fence is. If a block roof, either glass, or solid - say cobble - is placed over the fenced area then the animals will glitch through this.

Animals also appear to glitch through each other and so can stand on each other. The upper animal is now free to wander off. Since a baby animal's parents follow it this can result in the whole family running off. The baby glitches, the parents stand on it and bye farmyard.

Animals in fenced enclosures that are underground also glitch and, if there are enough in the enclosure will creep through the fence, only to be dragged back as if on elastic. If two do this at the same point then the 1st does not get dragged back and escapes. This does not appear to happen if the fence is above ground.

Hostile mobs also glitch through solid blocks to try and get to the player. To test build a wall with a single block ledge and stand on the ledge. Hostile mobs will bounce through the ledge to get at - and push but not damage - the player. It does not appear to matter how high the wall is and you cannot hit the mob while they have glitched. Spiders - that climb - are the main culprits, but I have also had creepers bouncing up 5 block high walls.

This problem has been mentioned on a number of other sites since around 1.8 but does not appear to have been fleshed out here - so I am reporting. Is it worth adding this info to the bug report?

No longer possible to make copy Map1?
Is anyone else having the issue where every map you make is automatically Map0, no matter where you make it? I thought they were supposed to be new maps if they were made at a new center, but since the 1.0 it doesn't seem to work, and 1.1 didn't fix it. I have so far tested this only in Survival Single Player. To test: make a map. Take compass, paper, and a workbench and walk off the edge of the map. Put down the workbench and craft a new map - it will be a copy of the old one, making it impossible to map the new territory.

EDIT: OK, I realized what was going on above is that I was trying to make multiple copies of the new map with shift-click. Is there a way I haven't discovered yet to copy maps other than map0? Because if not, I still think it rates "annoyance" at least.

Changing biomes -> World contineously freezing
I've noticed, that the biomes could change. It looks like they're wandering. You can see it when you visit an tundra biome at the border to another biome (like the plains). Please mark the borders, and later, when revisiting and it's snowing again, you will see, that there the borders are changing, other biomes could get snowy, and the tundra gets warmer. Normally that sounds not bad.

BUT THERE IS A PROBLEM! The snow and the ice of of the ex-tundra zones will not melt! So, the world will freeze and covered with ice and snow... I think thats an Annoyance at least, maybe a major one. I'll try to find out more, but please try to reproduce it. Thanks!--Locoloco 21:04, 16 January 2012 (UTC)

SMP Chunk Problems
I currently own a smp server, and with 1.1 I started experiencing problems. People were building things, going out of the area, and when they returned they often found the chunk had reverted to a previous point. This got to be quite commonplace on my server. I installed an autosave mod, and this has severely lessened the problem, but it still happens sometimes.