You can change the world's generation via Add-ons. The needed folders in the Behavior pack for these are:
structures, features, feature_rules and biomes. It's quite self-explanatory: you can store your .mcstructure files from (or for) structure blocks in structures, biome files in biomes, terrain features, like ores, in features and the rules for their generation in feature_rules. Let's go over adding a custom biome first.
Note: it might be easier to create biomes using Bridge, a Visual software for Add-on creation (also linked in Links and Contact), since the official Documentation is rather incomplete. You can also generate all example files of vanilla biomes, features and feature rules for reference, like shown here:
However, Bridge is not required.
Set "format_version" to 1.13.0: it's the latest biome file version as of the current release.
"description" takes only one value: identifier". This requires NO namespace and MUST be the same as the file's name.
"components" is just what you'd expect: something applied to the biome at default. let's look through them:
"minecraft:climate" controls everything climate-wise:
"downfall" is how often it'll be raining or snowing. 0.0 is for absolutely no rain (like a desert) and 1.0 should mean constant rain.
"temperature" is used to define things like water freezing and rain turning into snow,
You can generate default biome files for reference using Bridge
"overworld_surface": controls blocks generated.
"floor_depth" is how deep down lakes and rivers go in blocks;
"floor_material" defines the material to be used when generating the river and lake's floor;
"foundation_material" is the material to be used approximately between y=5 and y=50. For a desert, for example, it's stone.
"top_material" defines the material for the highest level. E.g for Plains it's grass.
"mid_material" is the layer between 'top' and 'foundation'. For Plains it's dirt.
Next up is "overworld_height". This defines how the Biome will look terrain-wise.
DO NOT use both "noise_type" and "noise_params" at the same time, like shown in the example. "noise_params" is an array of the top level of noise and the lowest level of noise allowed in the biome.
< This picture shows a non-smooth transition between the same biome, generated with noise_params as [0.1, 0,1] and then [1.0, 1.0].
If you want to use "noise_type", however, you will be presented with a few pre-generated types of noise. You will probably know how some of them look from the Vanilla game. Here's the list:
beach, default, extreme, taiga, ocean, mountains, default_mutated, deep_ocean, lowlands, less_extreme, stone_beach, swamp, river, mushroom.
"minecraft_world_generation_rules" is the most important component of all, especially the "generate_for_climates" array. Basically, there are three climates in the game: "warm", "medium" and "cold". They are randomly thrown around every world when it's created [hard-coded]. Now, you can choose how often your custom biome will generate in every specific climate. If you do not provide anything in here, the default value is 0, for every climate, and the biome won't generate. In the example, the weight(the smaller the number, the smaller the chance of this biome generating instead of a vanilla one in the climate) for every climate is set to 100 for testing purposes: that makes the biome generate almost everywhere in the Overworld. Once I'm done with testing, however, I'll balance the weight how it's supposed to be. For example, the Vanilla desert has the weight of 3 for warm.
This component also takes Objects such as: hills_transformation, mutate_transformation, shore_transformation, river_transformation, but their meaning is unclear to me. Contributions are always appreciated. Same goes for the "surface_meaterial_adjustments" component.
And, last but not least, BIOME TAGS! They're very simple, but useful. You can set however many of the vanilla or custom tags you want, by adding them in this format in "components":
Then, you can test for your tag in environment_sensors, filters, has_biome tests, spawn rules, and more.
Your custom biome is now complete! Note: cold_biome as well as volcanic biomes are now included in the guide's files on GitHub.
Features and Feature RulesNote: in v.1.15Beta, it is possible to use .mcstructures from the structures folder instead of features to generate custom structures with feature_rules. More on that after the update arrives.
Features and Feature Rules are used to generate everything from ores to grass and flowers, vegetation to granite or clay patches.It is even possible to create custom structures using those, but as it is very grindy and will be much easier after the mentioned update, we won't talk about it just yet.
Now, it's worth to mention, that the easiest way to generate Custom Structures is this auto generator by MACHINE_BUILDER. However, we'll still learn some other manual feature generation here, because some things like Ores are much more fiicient to generate as ore_features and not structure_template_features.
Let's make our tut:blocky custom block generate as an ore for the tutorial's sake. I'll do it the easy way, like this:
Open Bridge, choose your Add-on;
Add new file>features>diamond_ore and Add new file>feature_rules>diamond_ore.
Now I'll save the files and open them in my Code Editor and make the necessary modifications.
You could've easily just written the files from scratch or copied them from somewhere without using Bridge in case you are having trouble installing it. One place to find the Vanilla Files are the Example Packs, another, a more complete one is Bridge's repository.
Features are located in bhv/features and are basically a group of blocks stored in the game's files, which can be placed with a feature_rule. The file name of a feature must match the identifier as well.
You can find their Documentation on bedrock.dev/c/Features
"minecraft_ore_feature" is type of the specific feature that places ores automatically. Each feature type has it's own specific syntax. (There's also "single_block_feature" that places a single block instead of an ore group, etc)
"identifier" doesn't require a namespace in this scenario. The namespace is optional, and is not to be added in the filename.
"count" is how big the ore "cluster" will be at maximum, or how many actual ore blocks will generate together.
"places_block" takes the identifier of the block to be placed as the value.
"may_replace" takes all the blocks that the feature can replace as arguments. If it generates over one of the blocks not included in here, the block will remain where it was without being replaced.
Feature Rules control where and how features (and, in the future, structures) are placed.
"identifier" needs no namespace, but the filename needs to match.
"places_feature" takes the identifier of the feature that is controlled by this rule as the value.
"placement_pass" HOW the feature will be passed;
"biome_filter" tests for biome tags where the feature will generate, exactly as a spawn rule;
"iterations" basically chance. I set mine to 100 to make it generate everywhere, but for a diamond_ore, this is set to 1.
The next four components show in which directions the ore will be 'dragged' towards.
Needs more clarification
The easiest way to test wether your ores generated is /fill ~15 ~5 ~15 ~-15 ~-15 ~-15 air 0 replace stone using this command at a low y level. it'll keep everything BUT stone in the selected area, like this:
And yes, 100 as "iterations" is definitely waaay too much ;)
It's a good idea to proceed checking out other feature and feature_rule vanilla files to learn further techniques. However, the ones you were just walked through are enough to create most of what needs to be generated.
Yes, as of MCBE v1.16.20, Custom Generated structures are possible. A simple way to generate Structures is this auto generator by MACHINE_BUILDER, mentioned earlier. It generates all three of the required files for your structure: feature_rules/mystructure.feature_rule.json, and structures/mystructure.mcstructure. You can learn more about defining .mcstructures with Structure Blocks in Minecraft itself here.
Writing a Feature is a tiny bit more complicated.
Remember that the namespace is not required and that the filename must match the identifier, excluding the namespace. So if you have a feature rule with the identifier tut:myfeaturerule or simply myfeaturerule, the file name can be be myfeaturerule.json in both cases.
Here's an code example from the Features Documentation:
structure_name is the structure's identifier, the one you saved via a Structure Block.
This article needs completion here:
Now for the Feature Rule, which will place the Feature containing your Structure in the World. Refer to the Ore placement Feature Rules above and to the Guide's files repository.
The Structure generator linked above will generate the files automatically. I prefer to generate my Structure Rules with it, but I tend to use my own .mcstructures, exported via Structure Blocks.
That's pretty much it! Now you're able to generate your own custom Structures in the world.
Your progress so far:
What you've done:
Created you very first biome;
Made your very first ore generate naturally;
Learned to use Bridge for vanilla files generation and referencing;
Learned about other Custom Generation methods;
Created custom Structures;
What are you to do next:
Be introduced to Scripting;