The bug
If a block with no facing state (like quartz bricks) is added to #wall_corals block tag the game will crash when attempting to generate a coral reef.
[^(1.16.5) crash-2021-05-06_00.27.53-server.txt]
Description: Feature placement
java.lang.IllegalArgumentException: Cannot set property cfb{name=facing, clazz=class gc, values=[north, south, west, east]} as it does not exist in Block{minecraft:quartz_bricks}
at cej.a(SourceFile:114)
at ciy.b(SourceFile:51)
at ciz.a(SourceFile:58)
at ciy.a(SourceFile:27)
at ciy.a(SourceFile:19)
at civ.a(SourceFile:55)
at cku.a(SourceFile:20)
at cku.a(SourceFile:11)
at civ.a(SourceFile:55)
at cjb.a(SourceFile:23)
...Reproduction steps
Add the attached datapack
to a new world.
Wait for the world to generate.
If the game instantly crashes, that means that a warm ocean was right by the spawn point.
If not, locate the biome and teleport to the coordinates it gives you.
/locatebiome minecraft:warm_ocean❌ The game crashes
Attachments
Comments 9
I attached the datapack I was using when I found the issue. It adds quartz_bricks to all block and item tags.
@unknown I have updated your description of the report. Please don't make descriptions "see title" as those are not helpful.
Thanks for the datapack. However, there are two important things to consider:
The crash report you had attached was from a modded Minecraft installation (OptiFine). In general we do not accept reports about modded games since often bugs are caused by the mods. Though in this case this also affected unmodified (vanilla) Minecraft.
Please try to reduce datapacks to a minimum necessary for reproducing the bug. Your datapack contained a lot of changed block tags, and it appears it is not
#coral_plants, but#wall_coralswhich is causing the issue. I have attached a datapack only containing that.
I have updated the report accordingly, I hope that is alright for you.
Seems to be another instance of MC-203332. It has the same error and the same replication steps, minus the features and block_state that are affected.
Personally I think for now it would be good to have separate reports for all these cases since they all have to be fixed individually, unless the developers wan't to solve this by silently ignoring calls trying to change non-existent block state properties.
No, I'm not saying that. What I am saying is that, from a programmer's standpoint, it's probably better to plan for this type of thing in advance. If each type of configured_feature is made configurable, then they're going to need to make sure they have a system that only sets properties where they are needed. For example, it should simply not modify the block states when it detects that a block does not have them, and just place them normally. Of course, in this case, it isn't bothering to detect these things at all, which probably means that Mojang didn't add any checks for that - probably because they didn't predict that people would use different blocks for this type of thing. Unfortunately, that is not the case. People want to make unique designs, and using the same types of blocks every time gets boring. So, even from a design standpoint, this should have been addressed before the features were released. Not that I'm saying they aren't trying - they definitely are, which is the reason custom world-gen is labeled experimental - it's just that they will need to correct this oversight at some point or another if they want to leave these particular types of configured_feature in the game.
Interestingly, SlicedLime started working on correcting what I think is the same bug as this one in the following issue: MC-200009
Seems like my work here is done, at least until the fix comes out. At that point, I'll probably check if the bug is fixed for each individual feature type.
Could you for simplicity please attach a small sample datapack which allows reproducing this?