Ed Hall

I don't think there is much question that Mojang should fix it. Whether they patch 2-block flowers when old worlds are loaded or fix/ignore orientation metadata for the top block elsewhere in the code is up to them. But Rezzing has shown that a simple fix is all that is needed.

I've noticed the peony flash with tall grass and ferns as well.

The orientation sensitivity of this issue has been known from the beginning (I'm not the first one to notice it) and disagreement between top and bottom block metadata makes good sense as a trigger for this behavior. Someone with access to the code could check it out fairly quickly (both where the metadata gets set, and where it is tested).

There have been other self-dropping issues during the 1.8 snapshot cycle, such as item frames, pictures, flower pots, and so on. These all may have a similar cause: improper (likely missing, as you surmise) propagation of metadata.

"Insanity: doing the same thing over and over again and expecting different results."

Tested as before. User-placed non-South-facing two-block flowers still decapitated when moving world from 1.7.10 to 1.8-pre3 and, after a short amount of time, the flowers uproot themselves while I watch.

I keep testing because it takes no more than a couple minutes to do so. I get that devs might not find fixing it so easy, but this glaring incompatibility bug hasn't even been assigned.

Thanks to Galaxy_2Alex for updating the title of this bug; I doubt that devs would bother to skim 30+ comments to figure out whether this is relevant to the 1.8 release when it said "earlier snapshot" and not "earlier release."

However, the bug remains in 1.8-pre2; tested as earlier described, results as earlier described, 1.7.10 -> 1.8-pre2.

The "dup" bug MC-62140 does not mention that the bug affects updates from the 1.7 release. It only refers to incompatibility between snapshots.

Annnd... still in 14w33c. Created world in 1.7.10, added 2-block flowers and fern, loaded world in 14w33c, watched the tops of most of the flowers disappear followed by the remaining half-flowers dropping themselves.

Yes, this bug still exists; tested with world created in 1.7.10. Same behavior as before.

The title of this bug is misleading – the problem isn't just incompatibility with an earlier snapshot – it's with worlds created with the current release, 1.7.10, and earlier releases as well – verified with 1.7.4. If the bug still exists when 1.8 is released, a lot of pretty flowers that people may have worked hard to plant will uproot themselves.

Confirmed. I tested like this:

1) Generated new world with 1.7.10. The random seed was 6602167148430341072.
2) In /gamemode 1, placed tall fern, peony, rosebush, and lilac while facing each of the four compass directions.
3) Saved game, restarted in 14w31a.
4) For the first second or so, all 16 plants were fine. Then 12 of them popped off. Only the ones I had placed while facing North remained.

I can't confirm your result, crazyinabottle. I applied Catherina's test to both 1.7.10->14w30b and 1.7.10->14w30c (things changed overnight). In both cases I was careful to remove the previous test world. The flowers emerged unscathed. There would seem to be an additional variable involved here. Are you certain your 1.7.10 world hadn't been loaded under another snapshot first? Is there some starting seed and location that you can provide that elicits the problem? Just saying "it happens in a copy of my world" doesn't help us replicate the bug.

Given that we've seen other bugs like this (e.g. paintings and item frames popping off walls, etc) I have to suspect that there is some touchy code involved, likely dealing with block coordinates. So possibilities include location differences (say, positive vs negative X or Z) or some residual coordinate offsets from world generation, or something else beyond my present imagination.

Thanks to Catherina's detailed description, I was able to replicate the described behavior – but I think it is a problem with 14w26c and not 14w30b. I'll explain:

First, I created a world in 14w26c with Catherina's seed, and tp'd to the specified location. Flowers! (More 2-block flowers than I've ever seen in my worlds...). I quit and reloaded the world in 14w30b. Flower mayhem! Uprooted and decapitated flowers, as described.

I then deleted the world and started over with 14w21b – same seed, same coordinates, same flowers. I quit and reloaded the world in 14w30b. The flowers were all intact! Roamed around a bit, quit and restarted, everything was still OK.

OK, I'm lazy and didn't do a binary search to find at which version the incompatibility started. But it explains my observation that older areas didn't show the problem.

I'm not certain that the half-flower (which I've never seen) and uprooted flowers are the same bug. It happens inconsistently, but some peonies and lilacs planted several snapshots ago (when they were first added) uprooted themselves. Others did not. Flowerpots placed back in 1.4.6 (this is an old world that I've expanded many times after snapshots) were also automagically dropped as items. (All the flowerpots I had were affected but I only had a few.)

Oh, one addition: in all the areas I visited where game-generated 2-block flowers already existed none of them had been itemized. However, the most recent such area probably dates to a snapshot from last March or April, so if flowers generated in more recent snapshots have problems I wouldn't see it.

Portal issues seen in a world with several existing portals in 14w29b:

1) Some existing portals no longer lit, both in the overworld and nether.
2) Some existing portals partially lit (one blot lit, all blocks but one lit), both in overworld and nether.
3) Going through portal landed in mid-air in the nether, falling on top of existing portal. No new portal.
4) Going through portal into nether and landing over lava (ouch). Returned to find new portal (unlit) about 6 meters from intended (also unlit) destination had been created on shore of lava ocean near where I fell.
5) Going through portal back into overworld and materializing in solid rock. Dug to surface to find second unlit portal about 6 meters from my intended destination (which was also unlit).
6) in a couple of cases, portals were entirely lit and functioned normally.

In all cases, making sure the portals on BOTH ends were completely lit by destroying any portal blocks in creative and re-lighting resulted in the portals working as expected. This suggests to me that portal coordinates were corrupted but that re-lighting the portal stored the coordinates correctly.

Also seen here (OS X 10.9.1 Java 1.6.0_65), just as submitter described. More disturbing than the displacement of 2-block-wide paintings was their removal from the walls (and, if not replaced quickly enough, complete disappearance). Also noted was the following server message:

[19:12:32] [Server thread/ERROR]: Wrong location! (23, 11) should be (23, 12), sx['Painting'/157, l='world', x=379.94, y=80.50, z=191.50]
java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Thread.java:1266)
        at aqz.a(SourceFile:647)
        at arn.a(SourceFile:294)
        at arn.a(SourceFile:81)
        at arn.a(SourceFile:69)
        at nl.f(SourceFile:129)
        at nl.c(SourceFile:80)
        at net.minecraft.server.MinecraftServer.h(SourceFile:257)
        at net.minecraft.server.MinecraftServer.a(SourceFile:228)
        at mm.f(SourceFile:182)
        at net.minecraft.server.MinecraftServer.run(SourceFile:347)
        at mc.run(SourceFile:647)

Confirmed; client crashed as Iron Golem approached. Traceback was identical to the one posted. Samuel's work-around (thanks!) allowed me to continue in the same world.