Tedstar (Curtis Anderson)

After analysis of the code changes between snapshot 19w38b and snapshot 19w39a, I have observed the following changes to the code structure.

The snapshot in which this bug first appeared introduced a reordering of the render order found in the level renderer code. The following table was created based on the render profiler strings (used to keep track of rendering time and which indicates the order in which elements are drawn) between the last unaffected version and the first affected version.

The draw order found in 19w39a does not appear to have changed much in newer snapshots, at least following analysis of 20w20a which has the same draw order as 19w39a.

The table shows that the translucent layer was moved from being drawn after particles to now be drawn before particles.  This is problematic because any particles drawn behind the translucency will now be clipped by the depth test, which is what can be observed in this bug report.

As a test, I have recompiled snapshot 19w39a with the 4 lines of code that draw the translucent layer moved to be below the particle drawing code. As shown in the following screenshot, particles now render behind water again. This is a modified snapshot, and not reflective of the vanilla game.

I'm unsure if the following was ever intended behavior but this bug also prevents the entire hitbox of a transparent block from being seen.

Ex: If you look at a block of ice in a lake, you see a square above the ice, but not the other sides of the hitbox, which used to be visible.

This actually isn't fixed, the new shadows are just caused by MC-163242.

I also cannot reproduce the issue.  Between 1.14.4 and 19w40a, the code for getting a random character did not change, but there was a change in the string rendering method.  So perhaps that fixed it.

Would this relate to MC-129481 with the improper water culling?

Although this issue is about the faces culling when they shouldn't, whereas the other issue is faces not culling.

If someone with the required permission would like to, I would be alright with transferring ownership to Connor Steppie.

This bug will likely be fixed once the transition to Blaze3D graphics library is complete, but it is still useful to keep track of problems that need to be tested once the library is released.

Can you reproduce the issue on an unmodified server? If not, that would be an issue to report to the developers of PaperSpigot.

I think this bug and MC-140469 are the same issue with village generation altogether being funky on uneven terrain, but either way here is a seed and coordinates with a particularly bad village. Seed: -6751619097844995455
Coordinates: /tp @s 874.2 73.88 -469.22 46.6 39.7

Edit: Upon regeneration of the world, the paths have now molded to the terrain properly, and generated structures are not sunk into or floating above the ground. The only issue in the new world is with paths that intersect lakes. So this bug appears not always reproducible.

This bug appears to affect more than just paths, as I have seen houses and other structures that are floating or submerged in the terrain. I found a particularly bad village in seed: -6751619097844995455
Coordinates: /tp @s 874.2 73.88 -469.22 46.6 39.7

Affects 1.13.2, 18w43a, 18w43b, 18w43c.

Affects 1.13.2, 18w43a, 18w43b, 18w43c.

No, sorry it is multiple custom items each with a single component as their name.

It has to be multiple items to have a list of NBT values, and they must have custom names because otherwise the display.Name value won't exist and the NBT component will resolve to [].

1. Give yourself some items with custom names. (The color has been omitted to shorten command length.)

   /give @s stone{display:{Name:"\"Simple Stone\""}}
   /give @s oak_planks{display:{Name:"\"Pretty Planks\""}}
   /give @s birch_leaves{display:{Name:"\"Luscious Leaves\""}}
   /give @s fire_coral_block{display:{Name:"\"Capricious Coral\""}}

2. Then put all the items into a chest, and display their display.Name value using an NBT component.

   /tellraw @a {"nbt":"Items[].tag.display.Name","block":{"x":<x>,"y":<y>,"z":<z>}}

   But of course replace the xyz values with the chest block coordinates.
   The entries in the list of NBT values have ", " between the items and have [] around them.

   ["Simple Stone", "Pretty Planks", "Luscious Leaves", "Capricious Coral"]

3. Then instead interpret the data as text components (using "interpret":true).

   /tellraw @a {"nbt":"Items[].tag.display.Name","interpret":true,"block":{"x":<z>,"y":<y>,"z":<z>}}

   And now this time it is just the raw name values without any ", " between them, but still with [] around them.

   [Simple StonePretty PlanksLuscious LeavesCapricious Coral]

I colored the first item in the list and the color did not cascade to the other items, so if anything it may just be adding each item name as extra text to a text component. In which case it is intended insofar as text components do not delimit between children. But perhaps it is not intended for the command output.

Should this bug also cover the default style for lore (italic and color purple)? Or is that a separate issue / not an issue?

/give @s stick{display:{Lore:["{\"text\":\"The default style of lore.\"}"]}}

Edit:

I suppose it may not be an issue since that is always how lore has been.

Finally resolved in 18w43a/b
<3 <3 <3

@Poslovitch
This issue is separate from MC-123790.

The problem in MC-123790 was that item names were given italic formatting in certain places, even when "italic":"false" was in the JSON.

This issue is about item names being given "italic":"true" by default when no "italic" key is specified, which is inconsistent with JSON handling in other places, like the /title command. (Where when "italic" is not present, it is not set to true by default.)

My guess is this is caused by how renaming in anvils gives an italic name; and maybe a custom name in NBT is not properly differentiated from a custom name by an anvil.

Given the code piece calls a generic 'liquid' function I guess this is expected but it also happens with lava.

Modified server so invalid, but also a duplicate of vanilla MC-134865

Works as intended.

Was able to recreate with Vanilla server by customizing MOTD in server.properties.

Possibly related to the fix of MC-133260?

Either way, the server MOTD is sent as JSON text component, and to get color using server.properties deprecated section-sign \u00A7 must be used. So it may be invalid still.

Edit: I've created MC-134865

Affects 18w30a