ThothofMythos

@ j_p_smith:
Now I know to look for the "Future Update" information instead of just "Resolved".

I appreciate the explanation.

Definitely not resolved as of 23w44a - the most recent update showing for my launcher.
MC-266289 and MC-266287 both show as resolved. However, this issue still occurs.
Using the same worlds, and a new one, the issue continues.
Whether rebooting the launcher entirely, or just closing and reopening the world: loot tables reset each time.

I don't understand how all of these issues are marked as resolved; could someone explain the logic to me?
If the issue is a duplicate, I understand it being marked as a duplicate, but the tickets that the duplicate is linked to are marked as "resolved" as well - but the issue continues.

May be related to MC-266325?

I'm sorry to see this marked as "Won't Fix" but... alright.
Thank you, Mojang, for looking into it!

This doesn't appear to be just missing rows for the stairs, I found another missing slice, this time of wall, in the same mansion I referred to in my previous comment.

XYZ: 22568, 80, -11009
Facing North.
Seed: 5596122738704322835
Large Biomes generator setting.

Still in 16w43a

Another example:
XYZ: 22528, 85, -10985
Seed: 5596122738704322835
Large Biomes generator setting.

But, of course, it occurs to me after the fact to mention that this example world was generated with "Large Biomes".

Steps to Reproduce:

1. Create/find a dark room (e.g: through the fill command - "/fill ~5 ~3 ~5 ~-5 ~-1 ~-5 minecraft:dirt 0 hollow")

2. Grab a Mushroom (red or brown), a double-plant, and a light-generating block (Redstone Lamp, Sea Lantern, Jack o' Lantern, Glowstone, Lava... anything that creates a light level of 15)

3. Place the mushroom, place the light-block 2 blocks away from the mushroom, so that the light level on the mushroom is 13.

4. Cause the mushroom a block update by placing the double-plant next to the mushroom.

5. Observe:

   • The mushroom updates, sees that the light level is too high, so drops - expected.

   • The double-plant drops as an item, but leaves the "head" of the plant behind - unexpected.

     • The double-plant will only drop as an item if it is of a type that normally drops when broken, as opposed to only drops with shears. i.e: Rose Bush or sunflower, instead of double tall grass or a tall fern.

This appears to be only Partially Resolved.
The bed definitely seems to be fixed - but I am still seeing this issue with double plants.

I created a new Super Flat world in the 16w41a snapshot to test this, as well as the world I had been checking each version in.
In both cases, double plants still 'pop' and leave the 'head' behind when placed next to an 'invalid' block (e.g: a mushroom/farmland crop in improper lighting conditions).

@unknown;
Would it be better to reorganize this ticket along the lines of: "Block Updates cause bed and double plants to drop"?
Not to be confused with redstone updates, of course, as a redstone "BUD" switch doesn't appear to affect the bed/double plant at all.
This could, perhaps, help collapse this and the "relates to" tickets under one ticket.

Using a too-well-lit mushroom and a rose bush, for example:
Placing the rose bush causes an update to the surrounding blocks.
When the mushroom receives the update from the bush, it realizes that it is in an invalid position and drops.
When the mushroom drops, it causes an update to the surrounding blocks - including the base of the rose bush.
When the base of the rose bush receives the update from the mushroom, it realizes that it is in an invalid position as well (Because the top of the rose bush hasn't been generated yet) and drops.
Then, the top of the rose bush generates from the initial rose-bush placement.

If the Cactus block from MC-59303 is being updated, and updating, just like the mushroom from the above example, this could explain the behavior.

If the "Observer" block from MC-107600 is updating on game ticks, instead of redstone ticks, this could explain the behavior - and explain why redstone piston-based BUD switches don't cause the same issue, as redstone ticks, if I understand correctly, occur once every 2 game ticks.

Possible explanation for Observer BUD/Piston BUD differences:

• Observer BUD:

  • Placing the foot of the bed updates the Observer block.

  • The Observer block updates the foot of the bed, which realizes it is in an invalid position (as the head of the bed is missing) and drops.

  • The head of the bed is placed.

• Piston BUD:

  • Placing the foot of the bed updates the piston and schedules a "redstone tick".

  • The head of the bed is placed.

  • The piston extends - which, since the bed is already complete when it updates the bed, doesn't affect the bed.

SLSCool,

I suppose that would depend on usage - if per Latin roots or in the sense of 'txt msg' shorthand.
Though, I doubt this is the place to be discussing grammar, sentence structure, and the evolution of language.
However, as I do try to use the language correctly, thank you for pointing out the error.

Should I take the "Related to..." note off of the description?

It is interesting that you mention methods - that it's a program, and it behaves this way because something in the coding is telling it to, isn't something I had really thought about. I know that it's a program, but I hadn't looked at this from that perspective...

I was inclined to ask why you would think it's separate methods and not just an "if/else" branch; but thinking about what that code might actually look like...
I realize it's probably full of method calls.
Three at least: "jump", "swim_up", and of course the method that 'listens' for user input (typing on the keyboard; moving the mouse; etc.) and then performs the action...

if on_ground == true then jump
. elsif swimming == true then swim_up
. elsif game_mode == 'Creative'
. if just_jumped == true then flying != flying end
. else do_nothing
end

Well, I don't know about being one of the "biggest" new bugs; the bright red lava from 16w21a❓ was pretty big... and painful to look at! I'm really glad that one got fixed; I was worried there for a little bit that the developers had actually changed the texture of the lava!

I'm not sure how there would be a quick fix for this bug; you could change the auto-jump to count as "holding" the space bar until the player model is in contact with the ground again (which might also solve the water issue); but I can imagine that could 'cause all sorts of trouble in Creative/Spectator mode; especially with the ability to change between them with a keyboard shortcut.
What did you have in mind as a possible solution?

That 'auto-jump' seems to count as the "jump" key is easily noticeable while in shallow water; if you move towards a block and auto-jump tries to get you out, you'll see yourself bobbing up and down slightly (the same as if you were tapping the jump key over and over - on a non-creative/spectator mode).

Still noted in 1.10 PreRelease 1;

One thing to note;
It only appears to occur when facing East or West and approaching the East or West face of the block.
If you are facing North or South when approaching the East or West face of the block (by strafing sideways) auto-jump will still activate.
If you are facing East or West when approaching the North or South face of the block (by strafing sideways) auto-jump will still activate.

The 'Y-axis' (up/down) angle of the camera doesn't appear to affect how 'facing' reacts to the blocks; other than that auto-jump will activate while moving backwards if the camera angle is +/- 81.4 degrees.

It would still add clutter, even though the field is a collapsible list?
I thought the "Affected Versions" field affected search results like the 'Labels' and title do.

My reasoning was:
If only "16w20a" and "16w21b" are listed as experiencing the issue, that means either "16w21a" didn't have the issue or it wasn't tested for the issue.
I can't imagine the developers have the time, or the inclination, to check their updates against each and every single bug report to see if their changes resolved any issues unexpectedly.

However, even if I don't entirely understand the reasoning, if it isn't needed then it isn't needed.
I don't mean to argue.
Thank you for the response.

You may want to update the affected versions to include: "Minecraft 16w21a".
Because, right now, it may seem the bug report is saying that it wasn't working in 16w20a, fixed in 16w21a, then broken again in 16w21b.

From what I've seen: being in the air and hitting the jump key does not toggle flying.
This is easily tested by walking/jumping off of a tall tower, falling for a second, then hitting the jump key.

But, yes, it does seem that auto-jump counts as a 'jump' key - so hitting jump yourself, after auto-jump activates, starts you flying.

This isn't necessarily a bad bug, probably useful - a lot of bugs in Minecraft have been useful.

I've noticed this issue as well; also in the east-west direction.

However, it only appears for me in a few specific circumstances:
(A) Sneaking up to the block, then letting go of the sneak key.
(B) Standing directly next to the block before moving towards it.

—

(A) When facing the +/- Z direction; approaching the block by sneaking, and then letting go of the sneak key will auto-jump.
When facing the +/- X direction; approaching the block by sneaking, and then letting go of the sneak key will not auto-jump.

(B) When facing the +/- Z direction and being directly next to the block; moving forwards will auto-jump (ex: 39.700 (facing South), 39.300 (facing North))
When facing the +/- X direction and being directly next to the block; moving forwards will not auto-jump (ex: 39.700 (facing East), 39.300 (facing West))
You can get into these positions by: sneaking towards the block; walking up against a wall, then strafing (walking sideways) to be in position; being pushed by liquids or other entities

—

I hope this information was clear and useful.