David N. Thomas

I have also noticed that pistons seem to be erroneously powered when the piston arm is extended into a space that would be powered.

For example, place a piston 1 below and 1 below a block such that the extended arm will be directly below said block. Then place a redstone torch on the back of the block to power the piston. Now place a button on the block and press it. The only time the piston retracts is for the brief moment when the button power has ended and the torch has yet to update. In other words, the extended piston SEEMS to be powered both by the torch AND by the button if it is extended.

Removing the torch and pressing the button does not power the piston which indicates it is not getting power diagonally from the button but is instead being powered through the piston arm.

Whether this is a long-standing issue or not it is still irrational if not inconsistent behavior that does hinder the process of making some rational designs compact, even if it can be used in irrational ways to make other designs compact.

This is actually an old issue that maybe was fixed or supposedly fixed at some intermediate point. In my old SMP world I had stumbled across one stronghold and when I used Eye of Ender to try for another it sent me to another area even if I was standing above the stronghold I had located. To add insult to injury the "stronghold" it was directing me to had been obliterated by other terrain generation.

Eventually I employed AMIDST to confirm my coordinates and test it against the third stronghold. The Eye of Ender would not find either of the existing, unmolested strongholds even while standing above their end portals. It would only direct me to the location where the missing end portal should have been.

This was back around 1.3.1 at the latest, though I do not have an accurate lower bound on the version number in which either the testing or terrain generation occurred.

Version: 13w02b

Setup is as follows:

Two hoppers are adjacent to each other without being connected to each other.

One has a normal chest source and the other has a trapped chest source; which hopper has which source seems to be arbitrary.

When items are added to the trapped chest they are correctly transferred to the hopper that it is connected to and then on to that hopper's output.

When items are added to the normal chest they are incorrectly transferred to both the adjacent hopper and the correct output. The transfer seems to alternate, resulting in an observed, approximate 50/50 split between the correct and incorrect destinations.

It seems as though the click handler is now triggered on mouse up (when you release the mouse button) instead of mouse down (when you press the mouse button). This creates a problem when moving the mouse rapidly as the game will either think you are clicking elsewhere or dragging. I suspect this is a by product of the way the new inventory drag features were implemented. I have been able to avoid the click problems by being mindful of where my mouse cursor is when I release the button but that results in painfully slow inventory management and crafting.