kasamikona

Current enchantments only make sense on weapons/tools/armor. You can't enchant blocks in survival mode using an anvil. The ability to do so in creative mode is a result of being able to enchant any item. Being able to name any item has multiple uses, but in relation to blocks it allows containers' GUIs to show custom titles, so in this case it makes sense to save the name in the already-present tile entity data.

From a more technical standpoint, storing names and enchantments in placed blocks would require tile entities or something similar, which with current game mechanics would make the block unmovable by pistons even if it's normally movable (imagine unmovable dirt). The only way to fix this would be to fix MC-164, which is currently still marked as WAI.

I'm very interested to see what direction Mojang go with this given that difficulty.

The text has been changed a while ago, I'm not sure what version exactly, but the issue can now be closed.

Interestingly it seems this issue has been partially fixed (not sure exactly when, but testing in 1.14.4). Items are now positioned correctly while swimming, but the issue still exists for sneaking (the main focus of this report).

@violine1101 This appears to be MC-162127 (the issue is referring to the grey top of the held grass block, not the transparent beds)

Confirmed for 1.14.3-pre3

The issue is in the LayerHeldItem.renderHeldItem method (MCP 1.12.2 names). First the item is rotated by the arm rotation (translateToHand), and then if the player is sneaking it is translated 0.2 units downwards. However, this is 'downwards' relative to the arm rotation. When the arms are fully raised (aiming a trident when not swimming), the item is actually translated 0.2 units upwards. This can be fixed by applying arm rotations after the sneak translation.

I've identified the cause of this.
All entity models are created 1.5 blocks below where they should render, and then moved up by a little over 1.5 blocks in the rendering process. I don't know why it's done this way but it is. The issue is, the guardian model does not set a pivot/rotation point, and it defaults to [0, 0, 0] (relative to the entity position) which is above where the model is. When the model is rendered, everything is shifted up 1.5 blocks, putting the model in the correct place, but the pivot point is now at [0, 1.5, 0] which is way too high.

The correct location for the pivot, in my opinion, would be at 0.5 blocks above the bottom of the guardian, or 1.0 blocks below the default pivot.

In MCP 1.12.2 naming the code solution would be, in the constructor of net.minecraft.client.model.ModelGuardian, the following line needs to be added:

this.guardianBody.setRotationPoint(0.0F, 1.0F, 0.0F);

(entities are modelled upside-down so using a positive value here shifts the pivot point downwards from its default)

@leasoncre
What you're seeing here is that right-clicking the sugar cane is simply 'refreshing' its state. This may occur when clicking with other items or even an empty hand. As there is usually no visual difference between different growth stages for those two plants, the server does not always send age changes (even in singleplayer, it's still client and server processes running separately). For whatever reason, right clicking re-sends the current state even if nothing actually happened as a result of the clicking. The cooldown you saw is just the sugar cane taking time to actually increase its age again.

I have had this issue myself in earlier versions. The game expects the UUID (Universally Unique IDentifier) to be unique, so it may cause strange intermittent issues when it is not actually unique. Even if it has worked in the past, it is not supposed to work.

Either there was a lighting error or you did not wait long enough. Light level 14 will eventually melt snow after a random amount of time. The melting action is decided by the snow itself by checking its own light level, it does not know the source of the light.

Minecraft currently does not distinguish between 'hot' light sources and 'cold' light sources. Ice and snow only melt based on the light level (not including sky light).

It is caused by the having the same pair of 'UUIDLeast' and 'UUIDMost' on both items. You need to use a different number in at least one of the values. For example, the first item can have UUIDLeast:1,UUIDMost:1, the second item can have UUIDLeast:1,UUIDMost:2.

@Grum that's not quite what the issue is here.

The creeper in the example will move along several blocks as it's on top of the fence, not inside it. In 1.13 it suddenly stops about half way along, when the water level is lower than the creeper's feet. Before 1.13, the creeper would be pushed all the way to the end.

The new behavior makes more sense but is an unnecessary change that breaks previous creations.

Edit for context: this issue was closed as a duplicate of the issue mentioned.

This appears to be different to MC-127303.

That report is about air pockets inside flooded caves. This report is regarding the interaction between flooded and non-flooded caves/ravines.

The information I gave about color depth, resolution, graphics driver etc. is not 'bs'. Please attach your resource pack with exactly the same resized texture file that you tried (different image editors might do it slightly differently, which could make it harder to figure out the exact issue), so that we can attempt to reproduce the issue and have a better idea of what exactly is going wrong. Just complaining that a suggested fix isn't working won't benefit this bug report or the developers' attempts at fixing it.

This sort of issue sometimes happens when loading chunks too fast. If it always happens in that one same place even after restarting the game though, then the issue is with the server and you'll have to contact them.

The character can be pasted in with Ctrl+V and appears as a character flashing between 0 and 7. At least, that's how it worked a few versions ago. If it's changed, then Mojang isn't responsible for updating the wiki.

Seems like the network protocol involves transmitting the client's language setting to the server for whatever reason, and the server refuses the connection if it doesn't know what the reported language ID is. Fixing this requires either updating the protocol to not transfer the client's language setting (which there doesn't seem to be any use for) or putting in a workaround for servers to silently accept unknown languages without disconnecting.

(Note to moderators)
This is not a duplicate of MC-2878;
This issue refers to minecarts getting stuck and remaining stuck when reloaded, while that report is describing minecarts not being able to travel through unloaded chunks but makes no mention of them getting stuck when the chunks are reloaded.

Hmm, pretty sure this was fixed a little while ago but it's reappeared.

I understand what was intended by the introduction of this, but it was done in completely the wrong way.
How it should've been done: Repeater doesn't power non-solid blocks, and shouldn't update them either.
How it actually was done: Repeater does power non-solid blocks but doesn't update them.

Proposed fix: disable repeaters from powering non-solid blocks, and keep the change regarding block updates.

Note: this proposed fix will still probably annoy many redstoners, myself included, but it seems like a significantly more logical solution.

Alternative solution: Allow the repeater to update the piston itself directly.