Tags
Creators
Details
2.0.0+mod
Compatibility
Changes
Structure Bounding Boxes
- All structure bounding boxes are kept, including custom structures
- Ocean ruins have a weird bug that cause some of the hitbox to generate at the bottom of the world
- All blocks in structures (generated in any step in or before
underground_decoration) are removed - All entities in structures (generated in any step in or before
underground_decoration) are kept, meaning flying mobs will likely survive- In vanilla structures, non-flying mobs are not generated in most structures (exceptions being the ones that don't use structure files, e.g. ocean monument and ocean ruins)
- Structures can be added into the world by putting them in one of the steps in or after
fluid_springs
Stronghold
- The entire stronghold bounding box with the end portal in the same location as a normal world (for some reason the number of eyes are not consistent with a normal world)
The End
- Exit end portals now generate at the correct height, matching the exact location it would generate in a normal world
- There is some sort of bug involving some of the obsidian pillars and end crystals to not fully generate, but respawning the dragon will properly generate the pillars
Terrain/Biome Datapacks
Datapacks that modify terrain using only density functions (e.g. tectonic, continents) are automatically compatible.
Datapacks that modify terrain via noise settings (e.g. terralith, lithosphere), modify biomes (e.g. nullscape, geophilic), or add custom biomes (e.g. incendium, terralith, nullscape) are not automatically compatible.
To add compatibility, an additional datapack can be created to patch/merge the changes between the two datapacks. There is a script in the source code to pull a datapack and create a compatibility pack. Compatibility packs have been added for Terralith, Nullscape, and Amplified Nether.
Loot Tables
The starter chest has been changed from hardcoded items to a loot table so it can easily be changed without modifying the structure file.
Optional dependencies
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:bbtyQ1Po:WHElTkyl"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:bbtyQ1Po:WHElTkyl"
}




