1.2.0
Compatibility
Changes
[1.2.0] — Bug Fix Release
Fixed
🔴 Critical
-
HomeManager/TeamManager—save()not synchronized → homes/teams lost on server shutdownsaveAsync()dispatches aBukkitRunnableto a worker thread. When the server stops,onDisable()callssave()on the main thread while that worker thread may still be executing a previoussave(). BecauseYamlConfigurationis not thread-safe, the two threads interleaved theirdata.set(…)anddata.save(…)calls, producing a corrupted or empty file. The result was that all personal homes (and team data) were silently wiped every time the server restarted. Bothsave()methods are nowsynchronized. Additionally,onDisable()callsgetScheduler().cancelTasks(this)before saving, eliminating the race window entirely. -
HomeService.getPlayerMaxHomes()— wrong config key → home limit always 2 The method readsettings.default-max-homesbut the actual key inhome-config.ymlisdefault-max-homes(root level, nosettingsprefix). The missing prefix causedgetInt()to always fall back to its hardcoded default of2, capping every player at two homes regardless of what was configured. Fixed to read the correct keydefault-max-homes.
🟡 Medium
-
HomeService.teleportHome()— wrong path and wrong type fordisabled-worlds→ world blacklist never enforced via GUIgetString("settings.disabled-worlds", "")was wrong on two counts: the path prefixsettings.does not exist inhome-config.yml, and the value is a YAML list, not a plain string. The method always received an empty string and silently skipped the world check entirely, allowing players to teleport intoworld_netherandworld_the_endthrough the GUI regardless of the blacklist. Fixed to usegetStringList("disabled-worlds")at the correct root path. -
HomeHandler.handlePlayerSetHome()—player.getLocation()not cloned before storagehomeManager.setHome(…, player.getLocation())stored a direct reference to Bukkit's mutableLocationobject. Bukkit may reuse this object internally, meaning the stored coordinates could silently change after the call. Fixed by passingplayer.getLocation().clone()instead. (HomeService.setHome()already cloned correctly; this aligns the two code paths.)
Changed
- Version bumped
1.1.0 → 1.2.0.
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:G9WejUAk:F75IYFC8"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:G9WejUAk:F75IYFC8"
}

