From f6faf2fffaee2e499c33ca9a2cac5881f4fe6783 Mon Sep 17 00:00:00 2001 From: Lukas Rieger Date: Sun, 11 Oct 2020 22:27:10 +0200 Subject: [PATCH] Updated Configuring mods (markdown) --- Configuring-mods.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Configuring-mods.md b/Configuring-mods.md index 6a4cf0d..514d70f 100644 --- a/Configuring-mods.md +++ b/Configuring-mods.md @@ -31,7 +31,7 @@ After that you might need to do some more configuration. Go through the chapters } ``` -This is the most annoying part, but it is only needed with worlds (chunks) stored in the 1.12.x format! So if you have a minecraft world with only 1.13.x and above, you don't need to do this. +This is the most annoying part, but it is only needed with worlds (chunks) stored in the 1.12.x format! **So if you have a minecraft world with only 1.13.x and above, you don't need to do this.** Before 1.13 and [the flattening](https://minecraft.gamepedia.com/Java_Edition_1.13/Flattening), blocks are stored by their numeric-id and a meta-value. So the andesite block for example has id `1` and a meta value of `5`, this is usually written like so: `1:5`.
If a mod now adds a new block, this new block is being assigned to such an id. Forge then stores a mapping of the numeric-id and the literal-id of this block in a table in the world-files *(`level.dat`)*. Now BlueMap needs to know for each id:meta combination what block-state to render.