✯Kumandra's Economy[1.16-26.3]✯

Update 2.2 Hi guys. 2.2 is the security update. I went through every place money or items change hands and closed what I found, and a few of those could be used by any player on your server, so please update. Also built for Minecraft 26.3, and the documentation has a new home: https://www.jhprojects.dev/kumandras-economy One jar, 1.16 through 26.3. No config edits, no data migration, just drop the jar in. ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Trading Double click could take the other player's items for free. A double click in your own inventory grabs matching stacks from the open trade window, the other player's half included. The same trick after pressing "set" pulled your own offer back out while it still showed as for sale. Blocked, and so are drags into the wrong half. The seller was never paid. Buying the other side's offer took your money and gave it to nobody. It goes to the seller now. Closing the window deleted the other player's items. Both sides get their items back now. Anything that does not fit drops at your feet. One trade at a time. A second request or a second /ktrade accept could reset a trade halfway through. Not any more, and /ktrade deny works. ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Delivery Anyone could open someone else's delivery by right clicking the courier, and take what was in it. Now the sender packs it, nobody opens it in flight, and once it lands only the recipient can. Two deliveries could get the same id and the second wiped out the first, items included. Fixed. No fee if the recipient logged off before you paid. ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Shops Any player could set a shop's prices while an admin was pricing it, just by clicking an item in that shop. Only the admin who started pricing gets the prompt now. Some prices made items free. Typing NaN, or a number like -1.5, let players take the item out of the shop. A price is now a positive number, or 0 to lock the item, and nothing can be taken out of a shop window. ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Money NaN and infinity are refused everywhere. If another plugin passed along an amount a player typed, "NaN" could break a balance for good and "Infinity" was infinite money. Both are refused now, through the API and through Vault. Jobs no longer pay for blocked actions. Mining or building in spawn protection, a WorldGuard region or a claim still paid before. The exchange screen checks the other economy. If it refuses the payment, you do not get Kumandra money for it. Menus are read only. Dragging or shift clicking items into the balance, jobs and delivery menus and the shops is blocked. Junk dragged into a shop used to stay there. ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Also new /kumandra info shows your version and the documentation link. Works from the console. Update checks read the JHProjects site too, so you hear about a release as soon as it is up. The notice also stopped telling newer builds to "update" to an older one. Usage stats. Like Custom Enchantments 3, the plugin pings jhprojects.dev once an hour with its version, your server name, the Minecraft version, player count and error count. No player names, UUIDs or balances ever leave your server, and it never prints anything. Switch it off with Telemetry: false in config.yml. ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Compatibility - Spigot and Paper 1.16 through 26.3, one jar, no NMS - Java 8 and up - Vault, Custom Enchantments 3 and MySQL all still optional - config.yml gets the new Telemetry key on its own, your values are kept - No player data, shop or quest changes - Plugins using the API need no changes Documentation, questions and bug reports: https://www.jhprojects.dev/kumandras-economy

Update 2.1 A smaller update than 2.0. This is the Custom Enchantments 3 release. If you run both plugins, CE3 1.6.0 already talks to Kumandra’s Economy 2.0 and works fine. Nothing in this update is meant to fix that. What 2.1 does is finish the job on Kumandra’s side: the balance screen now shows both currencies, you can convert between them without leaving the command you already use, and any money taken by another plugin now shows which plugin took it. If you do not run Custom Enchantments 3, none of this affects you, except for the transaction list, which works on its own. Two currencies, one balance screen If your server runs both plugins, your players have two wallets but only one balance screen. /kumandra balance listed Custom Enchantments as a supported plugin, but only showed the name and not the actual number, which is the part people actually need. The CE3 balance now appears directly under the Kumandra balance, using CE3’s configured currency sign, so renamed currencies show up correctly. If CE3 is not installed, the line simply does not appear and the screen looks exactly the same as it did in 2.0. /kumandra convert <amount> Buys Custom Enchantments currency using Kumandra currency. The amount is in CE3’s currency, just like CE3’s own exchange screen, so you always end up with a whole number of coins instead of whatever your Kumandra currency divides into. /kumandra convert 40 This command does not do its own math. It calls CE3’s conversion system directly. The rate, the fee, the supply cap, and the refund behavior all come from CE3’s config. If I reimplemented them here, both plugins would match perfectly until the first time you changed a number in CE3’s config, and then they would quietly disagree forever. Converting through this command and converting through CE3’s screen use the exact same code path, so they cannot drift apart. If CE3 is not installed, the command tells you. If conversion is disabled in CE3’s config, the command tells you that instead of failing silently. Where did my money go Money taken through the API made your balance smaller but left no explanation. If another plugin charged your players, you could see the balance drop and that was all. /kumandra balance now has a Recent Movements panel showing the last six movements on your account, what each one was for, and how long ago it happened. The interesting part is what happens when the plugin doing the charging does not provide a reason. Every integration written for the 2.0 API calls a two‑argument withdraw and has no way to pass a reason. CE3 1.6.0 is one of them, which is why this feature was requested. Kumandra now detects which plugin made the call and records the movement under that plugin’s name. Attribution works immediately, without waiting for every integration to update. Plugins can provide better descriptions if they want to. There are new overloads that take a reason string, and that reason is shown instead of the plugin name: Code (Text): api.withdraw(player.getUniqueId(), price, "Bought a Sharpness V book"); What appears in the list: everything through KumandrasAPI, everything through Vault, and /kumandra pay and /kumandra economy. What does not appear: job wages. They drop a few coins at a time for every block you break, and six of those would push all the useful entries off the list before you even got back from mining. The list holds twenty movements per account, lives in memory, and starts empty after a restart. It answers “where did my money just go,” which only needs the last handful of entries. It is not an audit log and is not meant to be one. For plugin developers Everything in 2.1 is additive. Every method from 1.x and 2.0 keeps its exact signature and return values, and code compiled against either version links against 2.1 without changes. getApiVersion() returns 2. Check it once instead of probing for methods, and treat its absence as 1.x, before the UUID overloads existed. It returns 2 for both 2.0 and 2.1 because the API contract did not change shape. deposit(UUID, double, String) and withdraw(UUID, double, String) behave exactly like the two‑argument versions and additionally record what the movement was for. getRecentTransactions(UUID) reads the list back. getCustomEnchantmentsBalance(Player) and getCustomEnchantmentsCurrencySign() read CE3’s currency for display. The developer guide has a new section on CE3 integration: which nine methods CE3 resolves reflectively, why changing any of them silently disables the integration, that CE3 calls on the main thread, and why CE3 never creates Kumandra currency out of nothing. Notes CE3’s currency stays inside CE3. It is capped at 1,250,000 with a price curve based on how much is in circulation. Kumandra’s currency has no cap. Kumandra reads CE3’s balance for display and asks CE3 to move it. It never keeps a copy, because a cap enforced by two plugins is a cap enforced by neither. Nothing here can break your startup. Every CE3 lookup resolves by name, once, through CE3’s class loader, and is allowed to fail. A future CE3 that renames something only removes a line from the balance screen and shows a message from the command. It does not throw an exception on a screen a player just opened. Both plugins remain standalone. Neither depends on the other, and neither includes types from the other in its jar. That is intentional on both sides. Your lang.yml is fine. The new lines fall back to English if your file does not have the new keys, so nothing shows up as “null.” Add them if you translate. Upgrading Drop the new jar in. There are no config changes and no data migrations.

Update 2.0 Hi guys, this is a big update. Kumandra's Economy was written for 1.16 and it has quietly been falling behind ever since. If you have been running it on 1.19 or later, you have been running a version of the plugin that thought your server was older than 1.16, and turned things off because of it. This release fixes that at the root, and while I was in there I went through the whole plugin. One jar, 1.16 through 26.2. No separate builds, no NMS, no packet work. Same as always, just actually correct now. The bug that started all of this The old version checked your server version like this: does the version text contain "1.16", "1.17", or "1.18"? A 1.19 server contains none of those. Neither does 1.20, 1.21, or 26.2. So the plugin concluded it was running on something older than 1.16, and silently switched off: · the entire quest system · nether logs for the Lumberjack, so warped and crimson stems paid nothing · the Fisherman's rare-catch effects Nothing in the console said so. If you have been wondering why quests never appeared on your 1.19+ server, that is why. 2.0 reads the version as numbers and compares them properly, so a Minecraft release that did not exist when I built this jar is still correctly treated as newer than 1.16. That is what makes the whole 1.16 to 26.2 range work from one file, and it is what keeps it working for the next release after this one. Vault is optional now You no longer need Vault to install this plugin. That was a hard dependency before, which meant installing a second plugin just to use Kumandra's own currency on a server that had no other economy. · Vault installed, Kumandra primary. Registers as the Vault economy provider, exactly as before. Every Vault-aware plugin sees Kumandra money as the money. · Vault installed, Kumandra secondary. Reads the primary economy, and the in-game exchange screen converts between them, exactly as before. · No Vault at all. Everything works except the exchange screen, which needs a second economy to exchange with. And if Separate_Economy is true but nothing has actually registered a primary economy, the plugin now tells you in the console and runs as primary for that session, instead of half-working in silence. For the record: VaultAPI 1.7.1 really is the latest release. That project has not shipped since 2021. That is a large part of why this plugin no longer requires it. The Vault side was badly broken, and is fixed If you run Kumandra as your server's main economy, other plugins talk to it through Vault. Here is what they were getting from the old version: · format() returned null. Most shop plugins print that value straight into a message, so prices showed up as the word "null". · createPlayerAccount() always returned false, so any plugin that creates an account before paying decided the economy had refused the player. · Every bank method returned null instead of a proper "not supported" answer, which is a crash in any plugin that reads the result. · Looking a player up by name used a Java assert for its null check. Assertions are turned off on a live server, so an offline or misspelled name threw the error out into whichever plugin had called Vault. · Asking for a balance "in world X" returned zero if the player happened to be standing in a different world. Balances here are server-wide, so a player's money appeared to vanish and come back as they walked through a nether portal. All rewritten. If you have had strange money bugs with shop or reward plugins, this is very probably the reason. Custom Enchantments 3 support If you run my Custom Enchantments 3 plugin, Kumandra's Economy now notices. · CE is detected at startup and listed as an integration on the balance screen. · The Custom Enchantments quest pack that has always shipped inside this jar finally loads, but only when CE is actually installed. Quests can hand out CE gear again. · Without CE, the pack stays unloaded on purpose. Handing someone a sword whose abilities nothing on the server understands is worse than not offering the quest. This is a soft integration in the strict sense: not one line of CE code is imported. A CE update cannot break this plugin's startup. MySQL is easier and safer Still optional, still off by default, but: · The driver is bundled. Nothing to download, nothing to drop in the server folder. · It is relocated into the plugin's own package, so it cannot collide with another plugin's copy of the MySQL connector. That is a classic source of "works alone, breaks together" bugs. · Connections are closed on every path. The old error path leaked one connection per save. · Values go through prepared statements instead of being pasted into SQL text. · Saves are one batched write instead of a round trip per player. · A failed save now reports failure, so your data falls back to the local file. Before, a failed database save could be reported as successful and the data went nowhere. Connector/J is updated to 26.7.0. Jobs fixes Three of these have been costing you money the whole time. Ore income never worked. The default ore list was being appended to the mining- block list by mistake, so the ore list started empty and every ore paid at the plain-block rate instead of the ore rate. Builder income could silently be zero. The check that reads the Builder value was looking at the wrong config key. VillagerRadius was ignored. It has been in config.yml all along, and the Guardian job always used a hard-coded 20 blocks regardless of what you set. Also: Every job timer was running seven times. Job state is shared between the seven job listeners, but the timers were being started from a constructor that all seven call. Seven copies of the income task ran every tick, which meant your action bar was being written seven times per tick and income entries expired seven times faster than intended. Job listeners crashed for players with no record. First join on a database-backed server, or a mid-session /reload, and the first block that player broke threw an error. Trading and delivery Trade sessions leaked. When a request expired, one map was cleared. When someone closed the trade window, a different map was cleared. The trade inventory, the participant list and both sides' trade data stayed in memory for the rest of the server's uptime. Every trade that had ever happened, still resident. All of it is torn down together now. Delivery couriers could be stranded. The shutdown cleanup walked the courier list and stopped at the first courier whose chunk had unloaded, leaving every courier after it standing in your world as a named animal with no AI and nothing tracking it. Shutdown steps are also independent now, so a problem saving shop data no longer skips entity cleanup and the Vault unhook. Data safety A whole-number balance in playerData.yml used to destroy the file. If you ever edited it by hand and wrote balance: 500 instead of balance: 500.0, that record threw a type error and took every player's record down with it. It reads both forms now. Config upgrades work properly. The upgrade step wrote its backup to a hard-coded plugins/<name>/ path, which is wrong on any server started with a different plugins directory, so the backup went somewhere unrelated and the merge read nothing. Its key matching also compared every new line against every old line and kept overwriting, so the wrong old value could win. It now reads from the plugin's real data folder, indexes your settings by key, carries list settings across as whole blocks, and keeps all the comments in the shipped config intact. I tested this specifically by upgrading a customised 1.7 config: every changed value and the customised mining-block list came through, the comments survived, and

· Fixed null issue on currency exchange

· Updated API to 1.19 (report some issues if found in discussion)

· Enabled quests for 1.18 · Removed custom enchants 2 quests

Update 1.4 Translation · Added lang.yml, not all configuration can be translated, mostly it effects on GUI API · Kumandra's API was updated to support EpicMobs 1.1 and Custom Enchantments 2.1.5

slight patches -Added [ EssentialsX, CraftConomy3, GemsEconomy ] in plugin.yml -Modified Support List

-Fixed Quest disable not working -Added Config.yml auto Update [For those who are using 1.1 and below, backup and delete your old config.yml]

Update 1.1 -Added SQL connectivity [Beta] I'll provide a tutorial for SQL Connectivity soon -Added 5 more Quests

-Added Version checker, initial release1.0