Upstream/BlueMap
1
0
Fork 0
mirror of https://github.com/BlueMap-Minecraft/BlueMap.git synced 2025-02-16 20:41:57 +01:00
Code Issues Projects Releases Wiki Activity

Updated Configuring mods (markdown)

Lukas Rieger 2020-10-11 22:27:10 +02:00
parent 9c7fc70a74
commit f6faf2fffa
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
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`.<br> 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`.<br>
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. 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.