Hi, i created added a custom biome in minecraft 1.16.1 and works perfectly, but now updating to 1.16.3, all of the biome code is not working, like BiomeDictionary that is not present anymore. I know of the change made by Mojang in 1.16.3 for the data driven biomes, but how i can convert this biome to the new version?

27 minutes ago, jhonny97 said:

I know of the change made by Mojang in 1.16.3 for the data driven biomes,

You answered your own question. As for making it present in an existing dimension, I believe that's still done through BiomeManager. You would probably need to add it when server is about to start as the json will not be populated in the dynamic registries until then.

On 10/11/2020 at 6:36 PM, ChampionAsh5357 said:

You answered your own question. As for making it present in an existing dimension, I believe that's still done through BiomeManager. You would probably need to add it when server is about to start as the json will not be populated in the dynamic registries until then.

In 1.16.1 i used to add the biome using this code:

 

BiomeManager.addBiome(BiomeManager.BiomeType.WARM, BiomeManager.BiomeEntry(biome, 10))

 

but now BiomeEntry require RegistryKey instead of biome itself and in 1.16.3 don't spawn anymore.

1 hour ago, jhonny97 said:

but now BiomeEntry require RegistryKey instead of biome itself

Yes, that is true. All entries have a registry key of some kind which can be obtained from the specific registry it's within. They are all singletons, so it doesn't particularly matter that the biome entry is referenced as a key. You can still parse the name of the biome into a registry key with some parent.

1 hour ago, jhonny97 said:

in 1.16.3 don't spawn anymore.

The biome would still spawn. This is evident by their implementations across the versions. This can also be seen via Lex's comment on a post to reintroduce the BiomeManager. The only difference is that spawn biomes are specified in the spawn info of each biome itself instead in some list. So, this claim needs some base to be reviewed.

 

Once again, read what I wrote above. You would need to create a json biome and probably attach the biome via it's registry key to the layer on server start and remove on server stop. A registry key is just a concatenation of the registry and the object registered. You can grab both of these.

2 hours ago, ChampionAsh5357 said:

Yes, that is true. All entries have a registry key of some kind which can be obtained from the specific registry it's within. They are all singletons, so it doesn't particularly matter that the biome entry is referenced as a key. You can still parse the name of the biome into a registry key with some parent.

The biome would still spawn. This is evident by their implementations across the versions. This can also be seen via Lex's comment on a post to reintroduce the BiomeManager. The only difference is that spawn biomes are specified in the spawn info of each biome itself instead in some list. So, this claim needs some base to be reviewed.

 

Once again, read what I wrote above. You would need to create a json biome and probably attach the biome via it's registry key to the layer on server start and remove on server stop. A registry key is just a concatenation of the registry and the object registered. You can grab both of these.

Thanks for the explanation.

After a bit of testing, i managed to register and spawn the biome without using json, but now the problem is another.

In this biome i spawn a custom tree that worked until now. Instead of randomly place tree, like vanilla ones, they are placed in a grid (i attached a screenshot).

Nothing has changed in my code since 1.16.1.

 

This is the code that i use to add the tree to my biome

withFeature(
            GenerationStage.Decoration.VEGETAL_DECORATION, Feature.TREE.withConfiguration(MyTree.treeConfig)
                .withPlacement(Placement.field_242902_f.configure(AtSurfaceWithExtraConfig(9, 0.1f, 1)))
        )

 

And this is the tree code:

val treeConfig: BaseTreeFeatureConfig = BaseTreeFeatureConfig.Builder(
                SimpleBlockStateProvider(MyBlocks.log.defaultState),
                SimpleBlockStateProvider(MyBlocks.leaves.defaultState),
                BlobFoliagePlacer(FeatureSpread.func_242252_a(2), FeatureSpread.func_242252_a(0), 3),
                StraightTrunkPlacer(4, 2, 0),
                TwoLayerFeature(1, 0, 1))
                .setIgnoreVines()
                .build()

 

This happen with Forge 34.1.17, if i update to the latest Forge version they don't spawn at all.

Edited October 18, 20204 yr by jhonny97

1 hour ago, jhonny97 said:

Nothing has changed in my code since 1.16.1.

I'm pretty sure it has. That would be due to the placements. To make placements more versatile, they have been separated and allowed to chain on one another. This means that one placement might add more trees to generate, the other may spread them out, and another could change their height coordinate. Take a look at a tree ConfiguredFeature within Features to see what I'm talking about and replicate the chained placements. Note that their order does matter in how they decide to generate.

1 hour ago, ChampionAsh5357 said:

I'm pretty sure it has. That would be due to the placements. To make placements more versatile, they have been separated and allowed to chain on one another. This means that one placement might add more trees to generate, the other may spread them out, and another could change their height coordinate. Take a look at a tree ConfiguredFeature within Features to see what I'm talking about and replicate the chained placements. Note that their order does matter in how they decide to generate.

Your hint about the chaining placement was helpful, using this two placement i'm able to achieve the previous behavior

.withPlacement(Features.Placements.HEIGHTMAP_PLACEMENT)
.withPlacement(Placement.field_242902_f.configure(AtSurfaceWithExtraConfig(5, 0.1f, 1))