Tags
Creators
Details
2.1.2
Compatibility
Changes
Highlights
A bugfix release for Minecraft 26.3.
- Sulfur vents work again on 26.3. On Paper 26.3, vanilla biome decoration ran after AcidIsland generated the sea and overwrote every vent cap. New worlds got plain sulfur caps with no bubbling, gas or geysers, and the server log showed one
ServerInternalException ... PotentSulfurBlockEntitywarning per vent. Vents are now placed after decoration, so they generate intact. Fixes #183 [PR #184]
šŗ Existing 26.3 worlds: this fix only applies to chunks generated from now on. Vents in chunks already generated on 26.3 keep their plain sulfur caps.
Because vents are placed at a later stage of generation, a given seed puts vents in different spots than it did in 2.1.1. Only newly generated chunks are affected.
The deaths settings in config.yml now have clearer comments explaining which of them affect island levels under Level 2.29.0 and later. No settings or defaults changed. [PR #182]
Compatibility
āļø BentoBox API 3.14.0 āļø Minecraft 1.21.5 ā 26.3 āļø Java 21
The sulfur sea and geyser features require Minecraft 26.2 or later and are inert on older servers.
Upgrading
- Stop the server and replace the jar.
- No config or locale changes are needed.
Legend
- šŗ ā special attention needed
What's Changed
- ci: bump publish-platforms pin to the multipart-JSON fix by @tastybento in https://github.com/BentoBoxWorld/AcidIsland/pull/181
- docs: clarify which deaths settings affect Level 2.29.0 island levels by @tastybento in https://github.com/BentoBoxWorld/AcidIsland/pull/182
- šŗ Place sulfur vents in a populator so 26.3 decoration can't overwrite them by @tastybento in https://github.com/BentoBoxWorld/AcidIsland/pull/184
Full Changelog: https://github.com/BentoBoxWorld/AcidIsland/compare/2.1.1...2.1.2
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:Q6dUFUcW:9NYCjsbI"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:Q6dUFUcW:9NYCjsbI"
}

