Christopher Carrig
Assigned
Reported
Comments
For me, it's been flashing Peony as the top block whenever I break a two-block tall flower. I also noticed a single tall grass block with peony as the top block, but it reverted to normal grass when broken.
Leaving the chunk for a while and returning seems to have fixed the 3-block pacing. That Golem now walks the entire length of his accessible area on patrol. The one that stopped to stare at the floor for two day-night cycles has also resumed his less purposeful wandering(he doesn't patrol so much as meander, frequently stopping to stand around for long periods). Not sure if this was a natural occurrence due to the complexity of mob AI or if anyone else has had issues with Iron Golems behaving strangely, but the high casualty rate in 1.8 makes me wonder if their enemy detection is off, or if something else in their AI distracts them at critical moments, making them more likely to stand and stare than attack nearby threats.
Confirmed in 1.8-pre2(didn't see it listed among the bug fixes, but I broke some obsidian just to be sure).
It seems to impact Obsidian and Redstone Ore mining for me more than other blocks, even when all other graphics run smoothly. I've had the problem on and off through different snapshots(based on the comments, it's been fixed a few times for everyone). Using F3+A used to take longer to load, now it refreshes so quickly I can barely tell it happened. Also, the Midmap Level slider lags while all other options don't. Not sure if those last two are related, but I thought it worth mentioning anything that seems off.
Also noticing a strange lag when trying to adjust the slider for Midmap Levels, not sure if it's related.
I've been having this problem as well.
There seem to be other factors, as I tried to test the Creeper/Ocelot issue on a platform above the ground and also on the ground in an open area and noticed different behavior. It may be that Creepers only run away/avoid Ocelots given enough space to do so. I can confirm that Creepers make no effort to avoid Ocelots when an Iron Golem is present, which makes me concerned they would have no effect if I surrounded myself with cats in survival.
Ran some more tests in 14w34b, and I think this is a bug completely unrelated to Iron Golems. The Creeper on the platform moved among the Ocelots with barely any interest in them. When I spawned an Iron Golem, it made short work of the Creeper before it could explode. I think a separate big report should be filed now that Creepers are no longer afraid of Ocelots.
I noticed this as well. Creating an iron golem and surrounding it with cats does nothing to stop creepers from suicide bombing the iron golem. Confirmed in 14w32d. Multiple creepers blew the iron golem out of a small, fenced area with no less than three cats between them and the golem
I've noticed it through all the 1.8 snapshots up to 14w31c so far. Sometimes they even leave their houses at night for no reason and stand around outside. It may not be part of the same bug, but I've also noticed at least one villager who stays in a fenced yard at night and makes no effort to go inside.
Confirmed in 14w32c, first time I noticed it ever. Phantom walking sounds on wooden floors throughout my house, even when I'm outside. Did not occur in save previously, seems to have started after the invisible chest issue was fixed. I should add that I'm in single player mode, only mobs in and around the house. Two cats that were sitting or standing still, and a spider outside.
Similar problem, began when I switched from Fast to a Fancy graphics and increased render distance to 12 chunks from 8. I noticed flashing in the distance and could see the same images repeated across the entire chunks even as I flew into them in creative mode. Affects 14w32b
Confirmed. The save hasn't been opened since 14w31a, and it took me a moment to realize the chests were still there. After opening and closing some of the outlines, they seem to render normally. Others remain invisible. Ender chests are not affected.
Observed same problem in 14w31a. Written Books would only stack for me if named the same thing on signing(only tested by calling each "Written Book"). Renaming other written books to the same named would not allow stacking, and unstacked written books would not activate the trade.
Renaming to the same thing does not allow stacking in the trade menu. I encountered the same bug while trading. Using both slots for written books of different names doesn't work, nor two renamed to the same thing. Only way I was able to get the trade to work was by naming the books "Written Book" when created and stacking them in the first trading slot.
Pictured are the region where unlit portals keep spawning and the location underground where I was placed at least twice when one of the portals was generated unlit.
I've confirmed in my game that it creates a variety of portals, sometimes near each other, all unlit. Sometimes you materialize in dirt or stone nearby and beneath the portals. Other times, if you lit the portal yourself, it will direct you there reliably. When snapshots are turned off and the same world is created in vanilla Minecraft, portals generate normally in the same locations.
Are you sure there wasn't? You asked specifically whether I created the
world in 14w26c.
On Sunday, June 29, 2014, [Mod] Kumasasa (JIRA) <[email protected]> wrote:
> [Mod] Kumasasa
> <https://bugs.mojang.com/secure/ViewProfile.jspa?name=kumasasa>
> commented on an issue Re: New Nether Portals shunt player
> into walls instead of where portal is created in survival
> <https://bugs.mojang.com/browse/MC-59630>
>
> Did you create or open this world in 14w26a / 14w26b or is it a new world
> created in 14w26c ?
> [image: Add Comment]
> <https://bugs.mojang.com/browse/MC-59630#add-comment> Add Comment
> <https://bugs.mojang.com/browse/MC-59630#add-comment>
> Minecraft <https://bugs.mojang.com/browse/MC> / [image: Bug]
> <https://bugs.mojang.com/browse/MC-59630> MC-59630
> <https://bugs.mojang.com/browse/MC-59630> New Nether Portals shunt
> player into walls instead of where portal is created in survival
> <https://bugs.mojang.com/browse/MC-59630>
> Created a portal in the Overworld which formed in the Nether(as two
> portal frames intersecting at the corner of the obsidian frame), but going
> through the portal for the first time in survival lodged me in solid stone
> and suffocated me. Going through the second time in creative brought me to
> the portal that was created in the nether without incident. I la...
> This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) [image:
> Atlassian logo]
>
Did the version get rolled back from C to B? My games no longer load in C.
On Thursday, July 3, 2014, [Mod] Kumasasa (JIRA) <[email protected]> wrote:
> [Mod] Kumasasa
> <https://bugs.mojang.com/secure/ViewProfile.jspa?name=kumasasa> updated
> an issue Minecraft <https://bugs.mojang.com/browse/MC> / [image:
> Bug] <https://bugs.mojang.com/browse/MC-59630> MC-59630
> <https://bugs.mojang.com/browse/MC-59630> New Nether Portals shunt
> player into walls instead of where portal is created in survival
> <https://bugs.mojang.com/browse/MC-59630> Change By: [Mod] Kumasasa
> <https://bugs.mojang.com/secure/ViewProfile.jspa?name=kumasasa> Affects
> Version/s: Minecraft 14w27b [image: Add Comment]
> <https://bugs.mojang.com/browse/MC-59630#add-comment> Add Comment
> <https://bugs.mojang.com/browse/MC-59630#add-comment> This
> message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) [image:
> Atlassian logo]
>
I recently upgraded my graphics card in an effort to get rid of this issue. If anyone was able to fix this just by playing with Nvidia settings(and/or Optifine settings), I still haven't had any luck.