2 block tall flowers generated in previous version removes the 2nd block

Cannot confirm flowers dropping 2nd block, but can confirm flowers dropping as item or vanishing

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.

@@unknown:

in all the areas I visited where game-generated 2-block flowers already existed none of them had been itemized

Cannot confirm, see my screenshots. Was in a new generated world (1.7.10), planted tall flowers besides world gen planted flowers and only my tall flowers (all of them) uprooted.

I can confirm the bug in 14w29b.

Bug still occurs in 14w30a as well as 30b. Still does not affect all plants, but same plants are uprooted in all tests I have done. All uprooted flowers were placed, does not occur for naturally-generated.

I can confirm, 14w30b does both take off the top part as well as uprooting double height flowers IF the world was created with a previous version (14w##x for 1.8 snapshot).

Example to reproduce:

• use seed: 686298914 on a version where this bug wasn't present (like 14w26c).

• tp to -310 64 2136

• admire the double height flowers in the area (from there towards the South East)

• quit and copy the saved world to the save folder for 14w30b (if different from previous version(s))

• start the game and watch the double height flowers being uprooted or now turned into half-height (and sometimes being uprooted when walking past them, which might take a second or two).

Manually replaced double height flowers in 14w30b remain in place upon next load.

Manually placed double height flowers in previous version(s) might remain (1 out of 25 roses survived in my test).

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.

Thanks for testing it too, Ed! I really love that area... 🙂

I just tried a newly generated 1.7.10 world again with the same seed and all seems good. So it probably only affects worlds generated/used on some version after 21b (which I also just tested).

So I guess it's not really a bug any more then. 🙂

Time to reset the same world on my snapshot test server now!

Still occurs in 14w30c.

In my testing, I made a copy of my 1.7.10 world, then loaded it directly to 14w30c. Flowers still get uprooted.

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.

I'm sure, I never load this world in snapshots unless I load it from a copy. I'll try a few more things and report back.

Edit: When I say "a copy of my world," I mean I copy the world save in .minecraft/saves, so it has all of my buildings and whatnot. Doing the "re-create" option in-game does not affect flowers, the only ones that break are those that I've placed.

I created a fresh world in 14w30c (seed -298304267424731851), flew east to 410 80 201 to a sunflower plain. Reloaded the world on 14w28b, flowers were fine. I knocked down and replaced some of them. Reloaded the world back in 14w30c and the ones I had replanted were gone.

Edit 2: Seems to be a problem that was introduced in 14w29a. All previous snapshots load the plants fine in previously made worlds.

@crazyinabottle:
I agree, there seems to be a difference in manually planted and generated double height flowers.
I tested as follows:

• generated a world with your seed on 1.7.10

• checked your given location (410 80 201), I also visited a flower forest at -2500 66 -500

• planted sunflowers, peonies, roses and lilacs in both locations

• copied the world straight to 30c

• visited the locations and saw the manually planted double heights being cut in half then uprooted or instantly uprooted. Only a couple of the 16 manually planted double heights survived.

The generated sunflowers, roses, peonies and lilacs were fine...

As for in which version it started, it's hard to say. 26c, 28b and 29b seem affected by this manual planted issue. Strangely enough I didn't see the generated double heights uprooting as previously observed.

I'm puzzled...

When looking at a plant's data with F3, it seems that the plants that survive are the ones that are facing south. Those seem to get converted correctly--the rest don't and drop themselves.

Dan, I can confirm the facing south data. I created a new world in 1.7.10 and planted four of each tall flower, one of each facing a different direction. Upon loading the world in 14w30c, three of each flower uprooted, the ones remaining were south-facing blocks.

Bug still present in 14w31a. Hopefully this gets fixed soon.

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 know I'm starting to sound like a broken record, but bug is still present in 14w32a.

And, still a problem in 14w32d

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.

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

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.

Still present in 14w34d from a world created in 1.7.10.

This should really be looked into before 1.8, as it affects worlds created in the current stable version.

Some added information. Whether or not the top is destroyed depends on the facing data of the flower. All the flowers on my server on one side of buildings remain due to always placing from the same direction. Also, this world was created in release 1.2, and has run every version since. Hopefully this bug gets noticed soon, with 1.8 on the horizon, a lot of work placing flowers could go away. Still happening with 1.8 prerelease.

Uh.. common Mojang, how can you pre-release it with a showstopper like this? In case you need another world to reproduce it, here's a copy of my game files at db.tt/InrIbgNK with every garden and flower field getting ruined due to this. Plus, I get a lot of "Saving entity NBT... java.lang.NullPointerException" all over the world 😞

Also, someone should add 1.8-pre to affected versions for this bug, I couldn't find it when I searched.

Upgrading from 1.7 (I used 1.7.4) to 1.8 Prerelease 1 still decapitates/uproots the plants. Especially since this affects manually placed flowers, I'm really perplexed as to how this bug managed to go unassigned for so long. Landscapes that people may have spent an awful lot of time making would go kaput instantly.

Are we really going to be limited to the following choices: A) Stick to 1.7 or the early 1.8 snapshots forever for the sake of avoiding this issue, B) Upgrade to 1.8 and have to replace each and every tall flower in our maps? If it doesn't get fixed before the official release, everyone who has been playing on 1.7 all this while and upgrades will catch on and go nuts. That'd be a shame for an otherwise stunning update. Why isn't this bug getting the limelight it deserves?

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.

"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.

This bug is still present in the official release of minecraft 1.8,though I have observed something else that may lead to the solution to this problem. Last night when replacing all of my 2 block tall flowers in my grand garden, i noticed that every time i would break the bottom block of a two block tall flower (that was not glitched and actually had its upper half) the top half would momentarily turn into the upper half of a peony before disappearing moments afterwards, no matter what type of two block tall flower it was.

if anyone can go ahead and look into proving this next part please do because it may be the solution to our flower problems.

After a while of thinking i resolved that this peony bug and the popping off flower bug must be related to an issue of missing/corrupted/mismatched metadata. here's my reasoning, of course all two block high flowers were designed to break and fall as an item if either the top or bottom blocks were broken (we all already knew that part, but just keep that in mind), and from the peony bug we might be able to assume that the top blocks of all two block high flowers use the same block id, just different metadata to determine what type of flower and which orientation (thus resulting in them reverting to metadata 1 or 0 when in the process of being deleted, which then must be a south facing peony).
Finally the reason why the top block goes missing must be because somehow in the crossover from 1.7 to 1.8 the orientation metadata is lost, and the orientation metadata for the southern facing flowers must be 0, because when no value for a variable is specified the computer will assume it to be 0, allowing only south facing flowers to retain their upper half because the orientation variable for them was already 0, also meaning that any flower that is not south facing will of course glitch out because the bottom half remembers is orientation but the upper half is attempting to go into an orientation that should not be according to the lower half, and when the game realizes this it deletes the conflicting upper half possibly in order to avoid crashing or to avoid other conflicts, and last but not least when the flowers receive some form of update they realize their upper half is missing and break the lower half and drop the item.

I hope everyone here can understand what i am trying to say and that you can understand that this is all just conjecture based on my observations and i have not the time nor the java coding experience needed to prove or fix this issue. but if anyone else here does have the time/experience then it would be wonderful if you can look into this.

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.

We've seen this too, if you break a 2 tall flower it flashes with another type of flower right after you've broken it.
But this does happen on newly planted ones too.

I'm getting desperate about this, so I just took a look at it with MCEdit. MC 1.8 generates downright all top parts for tall flowers (including tall grass and fern) with an item ID of 175 and a data value of 8, while for some reason, MC 1.7 generates top parts with values between 8 and 12. Apparently, replacing all those flower tops with 175:8 does the trick. The java exceptions are gone from my server shell too.

But what now? Because that's an irreversible workaround. I can't tell really if that's a 1.7 or 1.8 bug. Although, the wiki says about value 8: "Top Half of any Large Plant; low three bits 0x7 are derived from the block below" (from http://minecraft.gamepedia.com/Data_values#Large_Flowers). So can someone confirm this before any of us is going to ruin their game files?

Hmm, how did you manage to replace the id's of all your flowers?

Regarding the id's, I think we need a Mojang response to this.

@Rickard, I'm using the 64-bit MCedit dev version 0.1.8build799. The release version is incredible outdated. Check the "MCEdit > Keys" menu for camera controls. And MCEdit takes a whole lot of RAM, so better do not edit very large worlds all at once or it might just crash on you.

How to:
1. After opening the world (level.dat), uncheck 'Record Undo' in the upper right corner. Undo takes a lot of time.
2. Expand a selection from sea level to the highest mountain (selecting whole chunks takes longer).
3. On the bottom toolbar, click the Fill and Replace button.
4. For the first tab, search for "Tall Plant Top" with the ID 175:9. Then click Replace and select 175:8.
5. Click the bold yellow Replace button to apply. Repeat this for 175:10 to 175:12 of course.

So, that's it. Saving takes a lot of time because it will relight all modified chunks. But that's nothing to worry about and will fix lighting bugs anyway.

PS: It's quite possible that MCEdit stops with a nasty error code saying something about malformed chunks. That's not a bug but indeed a corrupted chunk and MCEdit can't handle it. I'm mentioning it because I had this quite often at random. In such case, look for "Minecraft Region Fixer". It's a command line tool, so for example "region-fixer.exe --dc c:\your_gamefiles\world" would remove the broken chunks and the game files are accessible by MCEdit again.