
VillageAI
Intelligent village defense system. Villages centered on bells automatically detect nearby villagers. Friendly players gain reputation by trading. Hostile players lose reputation by attacking villagers. When hostile players are nearby reputation drops belo
3.1.0
Compatibility
Changes
[3.1.0] - 2026-04-24 โ Stability & Architecture Improvements
๐ Bug Fixes
Critical
- Dangerous save command removed โ
/villageai savepreviously calledonDisable()followed byonEnable(), which could corrupt game state. Now uses safe synchronous save without reloading the entire system. - Economy config ignored โ
economy_config.ymlexisted but was never loaded. Fixed:VillageEconomy.analyzeVillageNeeds()now reads village needs fromvillage_needs.daily_needsandvillage_needs.daily_productionsections in economy config.
High
- Code duplication in trade logic โ Trade execution was duplicated between
TradeGuiandEconomyCommand. Created newTradeServiceclass that centralizes all trade validation and execution logic. Both GUI and command handlers now use the shared service. - Hardcoded raid wave definitions โ RaidWave.forWave() contained hardcoded mob types and counts. Config now supports raid wave customization.
Medium
- Missing validation in trade execution โ Improved trade validation to check material availability more robustly before executing any trades.
๐ Improvements
Architecture
- TradeService: Centralized trade validation and execution (replaces scattered logic in TradeGui and EconomyCommand)
executeTrade()โ Validates items, emeralds, and executes trade atomicallyhasItems()โ Unified item checking logicgetReputationMultiplier()โ Centralized reputation tier calculation
Configuration
- Economy config loading: Village needs now fully loaded from
economy_config.yml- Daily needs section with material demands
- Daily production section with supply generation
- Emergency needs configuration for raids
- All hardcoded Material definitions removed from code
Code Quality
- Reduced God Class burden: Separated concerns with TradeService
- Eliminated code duplication: Single source of truth for trade logic
- Better separation of concerns: Services now handle specific domains
๐ Performance Notes
- No performance regression from 3.0.0
- Config loading happens once per economy update (not per trade)
- Trade validation still O(n) but with reduced overhead from centralization
๐ Migration Notes
For existing servers:
- The new
economy_config.ymlis auto-generated on server start - Existing village data is fully compatible
- No manual migration required
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:QkbM4VXn:qXcKS6Se"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:QkbM4VXn:qXcKS6Se"
}
