All versions
2.0.0
Release
Battle Only Capture 2.0.02 months ago 142
Compatibility
Minecraft: Java Edition
1.21.1
Platform
Fabric
Supported environments
Server-side
Singleplayer
Changes
Battle Only Capture 1.1.0
Added
- Added a Poké Ball selection menu when using the Catch action in compatible wild single battles.
- Added live, server-calculated capture probabilities for every available Poké Ball.
- Added combined Poké Ball counts from the player inventory and supported Sophisticated Backpacks.
- Added optional support for the Sophisticated Backpacks Fabric port, including carried and equipped backpacks.
- Clicking a Poké Ball now automatically throws it at the current wild opponent.
- Added a confirmation prompt before using guaranteed-capture or epic-rarity Poké Balls.
- Added recall-style particles and sound when a wild Pokémon is removed after battle.
- Added pagination for players carrying many different Poké Ball types.
- Added English and German menu translations.
Improved
- Poké Balls are now sorted by capture probability, with the highest chance shown first.
- Capture probabilities account for the Pokémon's HP, status condition, Poké Ball effects, battle conditions, level bonuses, critical capture progress, and Cobblemon catch-rate events.
- Custom capture calculators are detected and shown as unavailable instead of displaying an inaccurate percentage.
Security and Performance
- Added server-side validation of the battle, target, and Poké Ball ownership before every throw.
- Poké Balls are consumed using atomic transactions, with automatic rollback if the throw cannot be created.
- Limited players to one active capture throw at a time to prevent duplication and race-condition exploits.
- Uses event-driven processing without a continuous server tick loop.
Optional dependencies
Unavailable version
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:q9spqyQC:cUHSFkOi"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:q9spqyQC:cUHSFkOi"
}

