VillageAI

[3.3.1] - 2026-05-16 — Critical Bug Fixes

🐛 Bug Fixes

🔴 Critical — Thread Safety Violations

• Autosave called buildVillagesConfig() on async thread — startAutosaveTask() used runTaskTimerAsynchronously, which meant buildVillagesConfig() (and the VillageSnapshot constructor it invokes) accessed Village.getCenter().getWorld() — a Bukkit API call — off the main thread. This could cause race conditions, corrupted snapshots, or NullPointerException under load. Fixed: the scheduler is now changed to runTaskTimer so the config snapshot is always built on the main thread; the file write still runs asynchronously via saveVillagesAsync().

• loadVillages() restored villages on async thread — The thenAccept() callback of loadVillagesAsync() ran on the common ForkJoinPool thread. Inside it, snap.restore(getServer()) called server.getWorld(UUID) — a Bukkit API that is not thread-safe off the main thread. Fixed: the restore logic is now scheduled back onto the main thread via Bukkit.getScheduler().runTask(), while the file read remains async.

🟡 Medium — Incorrect Logic

• Raid reward silently capped at 64 emeralds — RaidManager.onRaidComplete() passed Math.min(totalEmeralds, 64) to Inventory.addItem(), so players completing a 5-wave raid (320 emeralds) received only 64 while the chat message correctly announced the full amount. Fixed: the full reward is now distributed across multiple 64-stack inventory adds, with any overflow dropped naturally at the player's feet.

• decayReputation(boolean passiveGain) ignored its parameter — The passiveGain argument was accepted but the method body never read it. When passive_gain: false in config, positive reputation was supposed to decay toward 0 symmetrically with negative decay, but instead stayed frozen forever. Fixed: when passiveGain is false, positive reputation now decrements by 1 per decay cycle (matching the existing negative-decay behaviour).

• VillageEconomy.analyzeVillageNeeds() read file from disk on every economy update — updateEconomy() called analyzeVillageNeeds(), which called YamlConfiguration.loadConfiguration(new File(...)) — synchronous disk I/O on the main tick thread — once every 24 hours. While rare, this blocked the server thread for the duration of the file read. Fixed: economy_config.yml is now loaded once into a cachedEcoConfig field at construction and can be refreshed via the new reloadEconomyConfig() method (called automatically by /villageai reload). No disk I/O occurs during tick.

🟢 Low — Defensive Code Quality

• openGuis in EconomyCommand used a plain HashMap — Event handlers (GuiListener) and command handlers both access this map; using ConcurrentHashMap is consistent with every other map in the plugin and eliminates any theoretical ordering hazard. Changed from HashMap to ConcurrentHashMap.

🔧 Technical Details

Thread Safety

• VillageAIPlugin.startAutosaveTask(): runTaskTimerAsynchronously → runTaskTimer; file write remains async
• VillageAIPlugin.loadVillages(): restore logic wrapped in Bukkit.getScheduler().runTask() to guarantee main-thread execution
• EconomyCommand.openGuis: HashMap → ConcurrentHashMap

Economy Config Caching

• VillageEconomy now holds a cachedEcoConfig field populated once in the constructor
• New public method reloadEconomyConfig() allows hot-reload without restarting the server
• analyzeVillageNeeds() reads cachedEcoConfig in memory — zero disk I/O during tick

Reputation System

• decayReputation(false): positive reputation now correctly decays by 1 per decay interval
• decayReputation(true) (default): behaviour unchanged — positive reputation is stable

📊 Performance Impact

• Autosave: eliminates risk of main-thread lag from VillageSnapshot construction racing with async writes
• Economy tick: removes all disk I/O from the tick path — measurable improvement on servers with slow storage
• No performance regression on any other path