neurospex

@unknown That is no more game-breaking than going to The End without supplies to beat the dragon. You would have to die in order to leave.

@unknown That would only be true if you consider being on top of the Nether as game-breaking. Having the bedrock barrier be passable through clever use of the Chorus Fruit could be considered a nice secret.

@unknown Seems a bit crazy that they can't ride minecarts. Many of us like to create mob museums. To have one that must be moved with pistons only, especially considering where they spawn, would be incredibly painful. Consider making it so they can't teleport when in a Minecart.

Confirmed with LordPriford's steps. But please consider keeping this version, as it's quite fun and not game-breaking 🙂

Yay, all fixed in 1.8-pre3, thank you for your help Ezekiel

1.8-pre1 the main title screen works nicely with the built-in fullscreen on a retina display, but all other menus and the game itself still have the resolution bug for me on a MacBook Pro late-2013 with retina display.

This includes trying to open the video options to get out of built-in fullscreen. Users who have this issue will not know what is causing the problem and may have trouble exiting the built-in fullscreen if they are not accustomed to hotkeys.

@Ezekiel, sure, trivial if and only if users are clearly informed. Thank you.

@Ezekiel, it is not going to be clear to people just getting the 1.8 update that fullscreen is the issue and that native fullscreen is a viable option. Currently using Mac OS X native fullscreen is most likely not the common method for going fullscreen and is not clear in the interface how to use it. Using the F11 or custom hotkey is the more obvious and discussed method. That makes this bug nontrivial. New 1.8 users with retina displays, especially those who default to fullscreen as most do, will immediately encounter the bug and feel helpless in remedying the situation.

@Phil71994 Please don't make duplicate reports.

Having done more thinking on this issue, here is what I propose:
If a hopper points into anything other than a hopper, then if the object it points in to can accept items, that should take priority over a hopper below that hopper. If a hopper points into another hopper, than the hopper below the original hopper should take priority over the direction the original hopper is pointing. This allows all old contraptions to still work while making new contraptions allow for storage item sorting.

Confirmed, this is still an issue in 14w32b
I am on Mac OS X 10.9.4 running Java 1.7.0_60
MacBook Pro Late-2013 with Retina display

I also test this in Java 1.6.0 and still had the same issue

The title to this bug needs to be updated to be more descriptive.
"Daylight Sensor - Does not behave like it should be!" could be any misbehavior. Perhaps something like this would help:
"Daylight Sensor - Emits signal at night when not exposed to sky"

Personally, this "bug" is a great feature that I use in a lot of builds. I consider it a moonlight detector and find it to be very helpful. I hope this is left as is.

However, I would like to see arguments against this behavior. Perhaps there are ways to address those arguments while leaving this behavior intact.

To be clear, the issue is that hoppers do not replicate the behavior of shift+clicking stackable items in your inventory while viewing a chest with incomplete stacks of that same item.

Hoppers favor placing items in the earliest possible slot instead of the earliest slot with the same stackable item type when present.

This may be intended behavior.

This seems to be broken again. I if I make a vertical stack of chests and point hoppers into them, items which go into the top hopper will either all end up in the bottom chest, or half in the top and half in the bottom. Any middle chests will be skipped for some reason.

It should be desired that if a hopper is pointing in to a chest or another hopper, that should take priority. Items should be fed from the hopper into the desired destination with a higher priority than another hopper trying to pull from that hopper by being below it.

A player shows intention with a hopper by directing it at a destination. This should be higher priority than placing a hopper below another, with the upper hopper /not/ pointing directly at the lower hopper.

Confirmed, first saw this in 14w06b, noticed that my empty cart return was no longer working. Issue caused by empty cart triggering the tripwire.

We DO want a player/mob in a minecart to trigger a tripwire, but we DO NOT want an empty minecart to trigger a tripwire. Unsure about minecarts containing furnaces, chests, command blocks, or TNT.