Tavis

MC-47986 is not a duplicate of MC-11193. MC-11193 is about the green wire updating the piston prior to the magenta wire turning off when the power is cut. MC-47986 is about breaking the magenta wire, then breaking the green wire and expecting the piston to be retracted.

The colors I'm using are from MC-11193.

The bottom piston should not be powered in that picture.

I don't think this ever happened before beta 1.8.

If I understand this correctly, the problem is that "falling sand" with a lava or water ID (which can be spawned with custom spawners in vanilla) will use the full 2x2 texture on its sides.

in Normal it only happens for small square chunks for a split second and is barely noticeable

Sounds like you have "Advanced OpenGL" turned on. See MC-3998.

It may be because minecraft has to keep an eye out for every player, and has to keep up accordingly.

Nope. It's a client side issue. By default, the server doesn't send enough chunks to "fill" far render distance but the client goes ahead and renders the empty chunks anyway. The client prioritizes rendering chunks the player can see but it doesn't re-check empty chunks until they get re-rendered, so the ones the player was looking at when they got rendered will render fine (unless you have Advanced OpenGL on - this is unrelated to MC-3998), but the ones you weren't looking at at the time they were rendered don't get re-rendered until everything else you can see gets rendered.

You can work around this if you have a server by setting the view distance higher (about 12 or 13 I think), but unfortunately I don't think there's a way to change it in singleplayer. Alternatively, as mentioned above, setting Render Distance to normal works fine.
Note that this only applies to "chunk errors" you can see through. If you can see the sides of chunks it's an issue with the client never actually getting the data in the first place.

As far as the boats breaking, they collide with items. You can test it by setting up a dispenser on a clock a few blocks above some water, filling your inventory, and boating through it in survival.
I would imagine that in some cases the boat manages to hit the lilly pad item before it gets a chance to be picked up or fall far enough to avoid the boat.

And, removing a thing that is the fundamental princable of many redstone contraptions, for example 3by3 and 4by4 doors, would be a terrible idea.

I posted a screenshot of a working 3x3 door and have built half of a 4x4 door that operates by manually toggling levers. The design can be mirrored and the lever flipping can be automated.

try building a 5by5 piston door without this.

You're getting a bit ridiculous here, but I suspect that those would be possible to build using redstone blocks.

Well, repeater locking.

Name one useful thing besides this that aiming a repeater at the side of another repeater does. I'd also like to point out that it is immediately obvious that something is happening.

The only case where, with pistons, this breaks things, is a redstone block ontop of a piston.

Two systems that are normally not used together and don't normally interfere can break when they are both activated at the same time. You may notice that this bug was reported before 1.5.

And, you can generaly curcimvent this behavior with slabs.

That is neither an obvious solution nor solves all of the problems with this bug.

And only in highly compact piston circuits does it become obvious.

They don't need to be compact for this to be a problem. A single wire in the wrong place is all it takes.

And unless you jump right into advanced redstone without wiking anything, you should realize this happens.

How about experimenting with redstone and building up your knowledge? How do you think people managed to write the wiki in the first place?

And design circuits around it.
Not against it, hoping that it will be fixed magicly and then your circuit will work.

This is pretty much what already happens because, short of using a mod, we can't test the circuit to make sure it would work.

Creepers were origionaly a improperly moddled pig.

And then Notch just gave up and left them with a pig skin and dropping pork.

Here's a much more flexible piston toggle. The repeater is required when it is facing most directions, but in some cases it can be omitted. The input can come from any direction, the output can be taken from any side of the redstone block, and the output piston can be rotated in any direction except towards the input.

–

For the alternating extended/retracted piston wall using the mod provided: Send a one tick pulse to the repeaters next to the pistons while sending a two tick pulse to the other ones to extend the pistons directly next to the repeaters. The other pistons can be extended as normal or with a one tick pulse if you like consistency. Two or more tick pulses will clear the wall. If you want to extend raw pistons just use redstone blocks and add another wall of pistons in front of the first. If one set of rows is already extended it can be reversed with a one tick pulse.

@grum Floating sand, breaking and placing blocks, flowing water, etc. would still need to be updated somehow. If everything were simulated the simulation could also take into account any blocks that should respond to such changes.

Can't you make the lower row piston, block, repeater, wire – giving you two rows of wire, with a block separating them?

In fact, as I look at that, why use a repeater there at all? Why not redstone dust normally?

That would power the piston you can't see behind the block the repeater is on.

I would also like to vote against adding a gamerule. Utilizing gamerules for optional forward compatibility has never happened before, and if you do it once everyone will end up demanding it for everything.

This would allow each row to be controlled independently if not for this bug: http://puu.sh/3AWbM.jpg

My implementation of the bug fix allows repeaters to power the piston below and in front of them. I think that behavior is useful and intuitive enough to keep, and I'm not quite sure how I would be able to fix this particular device if it was removed:

There's supposed to be a wall in front of it, and powering the piston below the piston next to the repeater would break it.

Powering individual rows of a wall using pistons and redstone blocks is possible with this implementation but quickly gets quite bulky. Powering rows of wall has always been pretty much impossible, so I think it might be worth looking into adding a mechanic to remedy that. You still can't do it with a wall of RS torches, but that's objectively less useful than pistons.
–
@grum: BUDs don't expose more implementation than any other system, they just use it differently. For all anyone else cares, they could just as easily poll for changes every tick and the only difference would be performance. Besides, if all that mattered was hiding implementation we'd all be staring at blank or maybe even invisible screens. 🙂

No, they were kept so that not everything was destroyed on the change.

You might also remember that at one point wooden stairs and fences didn't burn. Slabs got a new block because fire and tool properties are based on block ID, and removing the old blocks would have replaced all the existing ones with air or a different type of slab.

–
Another device that breaks is this piston toggle. It can be fixed by extending the redstone above the pistons over the top of them, placing the torches on the sides of the blocks directly above the pistons, and placing redstone wire directly below those torches:

The torches can be placed on any side of those blocks as long as they don't interfere with the output.

I know for sure CNB's 4by4 door is broken

I don't think that one will be easy to fix. It might be possible with redstone blocks, but that's the kind of thing I would expect to break eventually no matter what tricks were used.
–
EDIT: Never mind, I didn't remember how it worked, but after looking at it again it looks doable.
–
I managed to fix this 3x3 door by modifying it slightly. It's not quite as compact as the original but the concept is obviously workable.

Hoppers locking when receiving redstone isn't obvious on first glance.

That's a problem with hoppers not having any externally visible or audible indication that they are being powered. They respond immediately to changes that affect them, so the worst case for debugging hoppers is far better than the worst case for debugging quasiconnective pistons.

Try making a 10x10 wall of pistons that all move together without this quasiconnectivity (use that mod above).

Challenge accepted. If you don't want to see a bunch of pistons being placed click here instead.

This is not a duplicate of MC-886. Opening GUIs (including chat) clears the state of most keys, but does not clear the state of the control key.
To reproduce the problem:

1. Open a GUI to free your mouse

2. Hold CTRL

3. Click on another window to make Minecraft lose focus

4. Release control

5. Go back to Minecraft and open chat

6. Type a multi-letter word

7. Press backspace

8. Observe that the whole word has been deleted

For completeness, I am using Ubuntu.

I wrote a mod that removes this behavior: http://www.minecraftforum.net/topic/1874049-sspsmp-pistondispenser-quasiconnectivity-fix/

His comment implies that it is a bug that they won't fix "because users love bugs."