Tags
Creators
Details
Licensed MIT
Published 3 months ago
Updated 3 months ago
All versions
1.1.0
Release
PvPIndex Battles 1.1.04 months ago 19
Uploaded by
Compatibility
Minecraft: Java Edition
1.21.x
Platforms
Bukkit
Folia
Paper
Purpur
Spigot
Changes
What's Changed
Added
- Vault economy rewards (#15): battle winners now receive configurable currency payouts via the Vault API. Fully configured through
vault-rewards.ymlwith per-game-mode base amounts and an optional win streak multiplier. Vault is a soft dependency: if not installed, rewards are silently disabled. Closes #15. - New
vault-rewards.ymlconfiguration file. All settings live under a top-leveleconomy:key withenabled,rewards(per-mode amounts), andstreak_multiplier(enabled, increment, max, min_streak) sections. The bundled default ships witheconomy.enabled: falseso a fresh install does not pay out until opted in. - New
VaultRewardServiceinplatform-paperthat hooks into Vault, listens forPvPIndexBattleFinishEvent, and deposits rewards. - New
VaultRewardConfigrecord for parsing and validating reward configuration from theeconomysection. - New PlaceholderAPI placeholders:
%pvpindex_reward_last%(last reward received) and%pvpindex_streak%(current win streak). - New lang keys
reward.receivedandreward.received_streakin all 6 bundled locale files (en, de, nl, es, pl, zh). - Vault status line in the startup summary showing whether economy rewards are active.
Changed
- Console banner redesign: startup banner now displays a large ASCII art "PVP INDEX" with a Green-Yellow-Red gradient. Info line shows version, platform, and author (PVP Index).
- Shutdown message: updated to display "PVP INDEX has been disabled. Goodbye!" in red/grey styling.
- Paper 26.1.x adapter build: the
paper.26.1.xversion module now compiles against the stable Paper API26.1.2.build.57-stableusing the Java 25 toolchain, so the adapter builds cleanly across the supported 1.21.x to 26.1.x range. - Upgraded
maven-shade-pluginto3.6.2(bundles ASM 9.8+) so the relocated bStats and Jackson dependencies shade correctly against Java 25 bytecode.
Fixed
- Cross-server challenges from a lobby: challenging a player who was on a backend server (or behind another proxy) from a lobby silently timed out. Lobby servers relied on a player-location cache that went stale once a player moved to a non-lobby backend, so the challenge was routed to a node where the target was not present. The lobby now only uses the direct lobby-to-lobby Redis path when the cache confirms the target is on a live lobby node; otherwise it broadcasts the challenge over Redis to the proxies, which authoritatively resolve the target's current server and forward it. Challenges now work from any server to any server.
- Proxy challenge routing over Redis: Velocity proxies now handle inbound
CHALLENGE_SENDmessages over Redis (not only plugin messaging), resolving the target across all connected backends and forwarding the challenge. This removes the dependency on plugin messaging channels, which could break after a backend restarted independently of the proxy. - SMP challenge confirmation: accepting an SMP-mode challenge through the risk-confirmation dialog did nothing because closing the inventory cleared the pending GUI state before it was read. The mode and challenge target are now captured before the inventory closes.
- Return-to-origin after a cross-server battle: players transferred to another server for a battle were left waiting on the host server for two seconds before being returned, which looked like a double teleport. They are now sent straight back to the server they came from once the battle ends.
Downloads
| JAR | Target |
|---|---|
PvPIndexBattles-1.1.0.jar |
Paper 1.21.x / 1.21.4+ |
PvPIndexBattles-velocity-1.1.0.jar |
Velocity 3.x |
PvPIndexBattles-bungeecord-1.1.0.jar |
BungeeCord / Waterfall |
Full documentation: https://docs.pvpindex.com
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:oRvmxM8N:9pFUaGeC"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:oRvmxM8N:9pFUaGeC"
}

