Tags
Creators
Details
Licensed MIT
Published 4 years ago
Updated last week
All versions
1.12-2.0.1
Release
lostcities-1.12-2.0.1.jar4 years ago 63
Uploaded by
Compatibility
Minecraft: Java Edition
1.12.2
Platform
Forge
Supported environments
Server-side
Singleplayer
Changes
2.0.1:
- allowedBiomeFactors and generatorOptions were in the wrong config category! Be careful when updating and make sure to move the options if you did custom changes!
- New strategy option to generate translated biomes in case you want to limit the biomes in a world. The default strategy is 'original' but if you select 'randomized' it will try a more random distribution so that more biomes get a chance to be selected. If you chose 'varied' then it will be more sloppy about detecting what biomes are the same or not
- Add sanity check in case a biome is not properly registered to the biome registry
- Registered the Lost City loot tables to the loot table registry
- New 'singleBiome' config option to specify that city spheres should only have a single random biome
- The monorail crossing will now correctly be empty too (no water/rubble in it). Just like the other monorail parts
- ILostSphere.getCenterPos() will now return the correct center position (with y level set correctly as well)
- If you set the 'spawnSphere' config to '<in>' then the player will always spawn in a sphere. If you set the config option to '<out>' the player will spawn outside a sphere
- If the 'debug' config option is set to true palette statistics as well as biome translation statistics are dumped to standard output (log file) at startup
- New 'manualBiomeMappings' configuration option to manually override how some biomes map to others. This can be used in combination with allowedBiomeFactors to get more control over the final distribution
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:8VDCUS3b:FuzP91SW"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:8VDCUS3b:FuzP91SW"
}

