1.0.4
Compatibility
Changes
1.0.4 — Locking System & Major Fixes
This update brings a highly requested feature — a full parkour locking system — alongside a wave of fixes and improvements across the board.
🔒 Locking System
Parkours can now be locked behind a required permission node and/or the completion of another parkour. Both conditions are checked asynchronously when a player tries to start, so there's no performance impact. Locks can be toggled globally via config (locks.enabled) or on the fly with /parkour togglelocks. New commands /parkour setrequiredpermission and /parkour setrequiredcompletion let you configure these conditions per parkour without editing any files. Lock status is saved and loaded alongside the rest of the parkour data.
🛡️ Command & Teleport Exploit Fix
Players can no longer use commands or teleport during an active parkour run, closing a commonly abused loophole.
💀 Death & Respawn
Death handling now properly falls back to the last checkpoint, or the start if none is set. A toggle in the config controls whether this behavior is enabled by default.
🎒 Quit & Inventory Fix
Inventory restore and reset now only trigger when the player is actually in a parkour, preventing items from being incorrectly wiped when using Multiverse or similar plugins.
🛫 Leave & Flight
Forced flight is no longer enabled when leaving or finishing a parkour, which was causing unintended behavior for players without flight permissions.
📊 Actionbar Fix
Added a safe fallback to prevent a NoSuchMethodError crash on servers running 1.8.
🪨 Checkpoint & Iron Plate Detection
Iron pressure plate detection has been expanded so checkpoint plates are recognized more reliably.
📍 setEnd Fix
Corrected a location comparison bug in the /parkour setEnd logic that was causing incorrect end point behavior.
🧙 Parkour Creation Wizard
Sync and removal handling in the creation wizard has been adjusted for more consistent behavior.
🔧 Lite Fix
Restored the addcheckpoint command case in ParkourProLite — checkpoint setting was broken and is now working again.
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:i0Ccz6aS:CBSZ2wdC"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:i0Ccz6aS:CBSZ2wdC"
}

