liach

I have attached steps to reproduced in the issue body.

At least by 20w27a, the player head block entity attempts to load skin information on the server thread with a call to MinecraftSessionService.fillProfileProperties (with a true parameter) (usually implemented by yggdrasil) which will effectively block ticking on the server thread until the Minecraft server receives a response from the authentication server.

Most other calls to this fill profile properties are made on non-ticking threads, such as in executors on the client. This may be addressed like lighting where the block entity information is updated when the fetching of data completes asynchrously; however, it would potentially break commands expecting skull information to stay constant after generation from a command (such as setblock)

Affects 20w17a.

I've tested a mixin in a fabric mod and apparently that fixes the issue.
Proof: https://bugs.mojang.com/secure/attachment/285478/2020-04-23_02.59.45.png
(Released under public domain, feel free to take without crediting me)

@Mixin(ChatHud.class)
public abstract class ChatHudMixin {

	@Redirect(method = "render(Lnet/minecraft/client/util/math/MatrixStack;I)V",
			at = @At(value = "INVOKE", target = "Lnet/minecraft/client/util/math/MatrixStack;translate(DDD)V"))
	private void redirectMatrixStackTranslate(MatrixStack stack, double x, double y, double z) {
		stack.translate(x, y, -z); // 0, 0, -(-100)
	}
}

So in ChatComponent.void render(com.mojang.blaze3d.vertex.PoseStack,int) method, you don't do poseStack translate -100 after push, you do translate 100 instead. It is a bug with a negative sign.

Oh my thank mojang for that vector3f 0.01 pose stack multiplication

This apparently hides some characters behind f3 as well. When the characters in chat hud has bit overlap with that from f3 menu, the chat hud loses its bits.

Confirmed in 20w16a.

Affects 20w16a.

Affects 20w15a.

Confirmed in 20w15a.

Replication:
This bug can only be replicated when you join a remote server right after you freshly launched minecraft. If you've opened a local game or joined a server successfully, this crash won't be replicated.

Analysis:

Since 20w14a, tags have been refactored. As a result, tags, by default, are initialized with dummy entries that throw this IllegalStateException when called (before the tag container is set by the loaded local save). Because joining a local game or a remote server successfully previously would have set the tag container (no longer the dummy ones that crash), and as a result it won't crash.

When playing on remote servers, tags are sent by a Tag synchronization packet, yet the client starts rendering when it receives a Join game packet. As a result, when the game starts rendering fluids and checking tags, it might not have yet processed the tag packet if the network is bad, causing usage of dummy tags that throw exceptions and crash the game.

After another peek, I found the cause of the problem and has a solution for it.

This is the current code for locating structure in the superflat chunk generator (fabricmc yarn mappings):

public BlockPos locateStructure(ServerWorld serverWorld, String id, BlockPos center, int radius, boolean skipExistingChunks) {
   return !((FlatChunkGeneratorConfig)this.config).getStructures().keySet().contains(id.toLowerCase(Locale.ROOT)) ? null : super.locateStructure(serverWorld, id, center, radius, skipExistingChunks);
}

The problem is that some structure config keys, such as "oceanmonument" and "biome_1" as shown in the last comment's generator settings for server.properties, are not a direct mapping to structure names.

A suggested revision is as below:

public BlockPos locateStructure(ServerWorld serverWorld, String id, BlockPos center, int radius, boolean skipExistingChunks) {
   return !this.biome.hasStructureFeature(Feature.STRUCTURES.get(id.toLowerCase(Locale.ROOT))) ? null : super.locateStructure(serverWorld, id, center, radius, skipExistingChunks);
}

This way, we are querying the biome of the superflat world whether such a feature exists (the biome already has all the processed structure information), which is more reliable.

I have applied this patch as a mod, and it apparently works well (see the screenshot of it working), while other unintended features that may have been specified by "biome_1", such as "Swamp_Hut", still correctly reports "Could not find that structure nearby".

Confirmed in 20w14a with the water world preset, tested shipwrecks, ocean ruins, monuments, all three of which generates in the water world superflat preset.
Or with this generator config (water world superflat preset) in "server.properties"'s "generator-options" field:

{"structures":{"biome_1":{},"oceanmonument":{}},"layers":[{"block":"minecraft:bedrock","height":1},{"block":"minecraft:stone","height":5},{"block":"minecraft:dirt","height":5},{"block":"minecraft:sand","height":5},{"block":"minecraft:water","height":90}],"biome":"minecraft:deep_ocean"}

Confirmed for 20w13b.

Affects 20w13b. Reproduced with the exact same data pack.

So the plant is like the root of the vine, isn't it?

This isn't really a problem as the stack overflow only happens on the network thread than the server thread. and since the server is stopping crashing the network thread isn't a big problem.

This is working as intended.
When you push the cart with your bare hand or something like a wooden stick while the cart is powered, though the item isn't consumed, you can observe a change in the cart's moving direction. The animation is for changing of direction, not just for the consumption of fuel.

Some code analysis:
Old logic (FabricMC yarn 1.15-pre4 build 1)

protected int getPower(World world, BlockPos pos, BlockState state) {
      int i = super.getPower(world, pos, state);
      Direction direction = (Direction)state.get(FACING);
      BlockPos blockPos = pos.offset(direction);
      BlockState blockState = world.getBlockState(blockPos);
      if (blockState.hasComparatorOutput()) {
         i = blockState.getComparatorOutput(world, blockPos);
      } else if (i < 15 && blockState.isSimpleFullBlock(world, blockPos)) {
         blockPos = blockPos.offset(direction);
         blockState = world.getBlockState(blockPos);
         if (blockState.hasComparatorOutput()) {
            i = blockState.getComparatorOutput(world, blockPos);
         } else if (blockState.isAir()) {
            ItemFrameEntity itemFrameEntity = this.getAttachedItemFrame(world, direction, blockPos);
            if (itemFrameEntity != null) {
               i = itemFrameEntity.getComparatorPower();
            }
         }
      }

      return i;
   }

New logic (FabricMC yarn 20w08a build 6) with my comments:

protected int getPower(World world, BlockPos pos, BlockState state) {
      int i = super.getPower(world, pos, state);
      Direction direction = (Direction)state.get(FACING);
      BlockPos blockPos = pos.offset(direction);
      BlockState blockState = world.getBlockState(blockPos);
      if (blockState.hasComparatorOutput()) {
         i = blockState.getComparatorOutput(world, blockPos);
      } else if (i < 15 && blockState.isSimpleFullBlock(world, blockPos)) {
         blockPos = blockPos.offset(direction);
         blockState = world.getBlockState(blockPos);
         ItemFrameEntity itemFrameEntity = this.getAttachedItemFrame(world, direction, blockPos); // also the air check is now removed, most likely intended
         int j = itemFrameEntity == null ? 0 : itemFrameEntity.getComparatorPower();
         int k = blockState.hasComparatorOutput() ? blockState.getComparatorOutput(world, blockPos) : 0;
         i = Math.max(Math.max(j, k), i); // i = Math.max(j, k) may be a fix, but it still changes old behavior as previously only frames in air outputs, and has lower priority than outputing blocks
      }

      return i;
   }

The max out calculation is all new. The old logic is that it replaces the power obtained as a regular block with custom comparator output if i < 15.

Is maxing things out wrong?

This i < 15 statement makes me think that maxing out power later is the intended initial behavior (given if i == 15, extra check will not return a higher value and will waste cpu/memory when we are actually doing maxing out logic).

Is maxing things out right?

If it is, the getting power not through wall code probably should max with ambient block power as well, but it's clear that if the comparator outputing block has redstone output itself, things are clearly messed up.

My conclusion is that the final result is up to mojang to decide. In my opinion, the current status (i.e. in 20w09a) should be the most correct one (again this is only my opinion). The other side effects of the recent change (item frame) may be less noticed. If we do determine what should be regarded as "correct", we should determine what should be the power when both item frame and a comparator outputing block exists.

On a side note, the feature related to this bug has been first reported in MC-64394, which (the feature) has been resolved as working as intended.

Isn't this working as intended?