Tags
Creators
Details
Licensed MIT
Published 9 months ago
Updated 5 months ago
All versions
3.1.0
Release
EzEconomy 3.1.05 months ago 77
Compatibility
Minecraft: Java Edition
1.21.11
1.20.6
1.19.4
1.18.2
1.17.1
Platforms
Bukkit
Folia
Paper
Purpur
Spigot
Changes

Added
- Velocity proxy support - New
ezeconomy-velocitymodule provides a Velocity proxy plugin for cross-server payment notifications and global player list broadcasting. Deployezeconomy-velocity.jaron your Velocity proxy alongside the main plugin on backend servers. - Cross-server messaging layer - New
MessagingService,MessagingTransport, andMessageTypeabstractions in core. Supports three transports: Velocity plugin messaging, BungeeCord plugin messaging, and Redis pub/sub. - Redis pub/sub messaging - New
RedisMessagingTransportin theezeconomy-redismodule enables proxy-independent cross-server messaging via Redis pub/sub. Ideal for multi-proxy setups or networks already running Redis. - Pending notifications - Payment notifications for offline players are now stored in the database and delivered on next join. Implemented in all four storage backends (YML, MySQL, SQLite, MongoDB).
- Player info persistence -
StorageProvider.persistPlayerInfo()stores UUID/name/display name on join, enablingresolvePlayerByName()for cross-server name lookups. - Configurable lock timing - New
lockingsection inconfig.ymlwithttl-ms,retry-ms, andmax-attemptssettings, replacing hardcoded values. - VaultEconomyImpl distributed locking - Withdraw and bank withdraw operations now acquire distributed locks (with local fallback) to prevent race conditions in multi-server environments.
- Cross-server documentation - New
docs/feature/cross-server.mdanddocs/integration/velocity.mdcovering all three messaging transports, configuration, and deployment. - Velocity CI workflow - GitHub Actions workflow for the
ezeconomy-velocitymodule. - MessagingComponent - Bootstrap component that initialises cross-server messaging during plugin startup.
- New message keys:
eco_give,baltop_footer,payment_cancelled,recipient_offline_queued. /payalias:ezpay.MySQLStorageProvider.persistPlayerInfo()implementation for explicit player data upserts.
Changed
- BungeeCord proxy overhaul -
EzBungeeProxyPluginnow implementsListener, registers bothezeconomy:locksandezeconomy:notifychannels, handles payment notification forwarding, sendsRECIPIENT_OFFLINEresponses, and broadcasts the global player list every 3 seconds. - BungeeCord proxy plugin.yml - Fixed
mainclass reference, addeddescription, enabled resource filtering for${project.version}. - All sub-module POM versions now inherit from the parent (removed explicit
<version>tags). - Updated README with cross-server messaging, Velocity integration, and distributed locking documentation links.
- Updated
docs/feature/proxy-network.mdanddocs/integration/bungeecord.mdto reflect Velocity support and cross-server messaging. StorageProvider.transfer()now uses configurable lock timing viaEzEconomyPlugin.getLockTtlMs/RetryMs/MaxAttempts().
Fixed
- BungeeCord proxy
plugin.yml- Main class was pointing to the wrong class (EzBungeeProxyinstead ofEzBungeeProxyPlugin). - BungeeCord channel mismatches - Unified lock and notification channels across server and proxy modules.
- PaymentExecutor cross-server notifications - Offline recipients now receive payment notifications via cross-server messaging instead of silently dropping the message.
- Cross-server
/payfailing silently - Payments to players on other backend servers failed because the recipient was looked up only in Bukkit's local player cache.PayCommandnow checksMessagingService.isNetworkPlayer()andStorageProvider.resolvePlayerByName()when local lookups fail. - Incorrect UUID for cross-server recipients -
PaymentExecutorwas usingBukkit.getOfflinePlayer(name)which generates an offline-mode UUID for players who have never joined the local server. It now resolves the correct UUID from the messaging service or shared database. MySQLStorageProvider.resolvePlayerByName()not implemented - The default no-op from theStorageProviderinterface was being used. Now queries theplayerstable by name to return the correct UUID.
Optional dependencies
Any compatible version
Supplementary resources
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:rQtkf57Y:64ghxe2V"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:rQtkf57Y:64ghxe2V"
}

