Legacy Combat Experience (LCE) brings classic Minecraft 1.8-style PvP behavior to modern Paper servers.
LCE is built for PvP, practice, minigame, and competitive servers that want the speed and feel of legacy combat while staying on current Minecraft versions. The project is open source so server owners, developers, and community members can report issues, suggest improvements, and contribute fixes.
- Stable releases: Modrinth
- Dev builds: Moonrise CI
- Issues and feature requests: use the GitHub issue templates
- Contributing: see CONTRIBUTING.md
- Loader: Paper
- Minecraft version: currently built against Paper
1.21.4 - Java: 21
PacketEvents is required. PlaceholderAPI and WorldGuard are optional integrations.
- Block or remap modern combat sounds and particles
- Tune knockback values by knockback cause
- Restore legacy-style projectile interactions for snowballs, eggs, ender pearls, fishing rods, and more
- Optional bow boosting and legacy potion physics
- Optional bridging speed behavior for shift-backward movement
- Configurable sword blocking damage reduction and old sharpness/axe damage behavior
- World and WorldGuard region support for scoping legacy combat behavior
Use Java 21.
./gradlew buildThe shaded plugin jar is written to:
build/libs/If the Gradle wrapper is not executable on your machine:
chmod +x ./gradlewRun the unit test suite with:
./gradlew testPull requests should include tests for behavior changes when the code can be tested without a live server.
/legacycombatexperience
/legacycombatexperience reload
/legacycombatexperience sound <sound> [volume] [pitch]
/legacycombatexperience knockback
/legacycombatexperience knockback <x> <y> <z>
/lce
/lce reload
/lce sound <sound> [volume] [pitch]
/lce knockback
/lce knockback <x> <y> <z>
/giveblockhittingswordlce.command
combat.command.giveblockhittingswordCommunity contributions are welcome. The default branch is protected, so all changes should go through a pull request.
Before opening a pull request:
- Create a branch from the latest default branch.
- Keep the change focused.
- Run
./gradlew test. - Update documentation when behavior, commands, permissions, or configuration changes.
- Fill out the pull request description with what changed and how it was tested.
For more detail, see CONTRIBUTING.md.