2.3.2
Compatibility
Changes
SentientMobs v2.3.2
True Compatibility
A plugin isn't truly compatible simply because it compiles. It has to behave properly under pressure, across every supported version, without falling to pieces the moment reality gets involved.
Bug Fixes
- Eliminated ten long-standing bugs affecting memory tracking, housing management, village politics, and Community Chest operations.
- Fixed villager memory lookups that could produce incorrect movement detection.
- Corrected housing cache initialisation and introduced automatic cleanup to prevent stale data from lingering indefinitely.
- Standardised double chest cache keys for reliable village storage management.
- Prevented leadership effects from being applied to invalid or dead entities.
- Improved Community Chest diagnostics when storage is full.
- Reworked personality generation to use deterministic, entity-based randomness instead of unpredictable timing.
- Reduced redundant entity lookups and cleaned up several internal systems for improved efficiency.
True Compatibility
- Introduced a proper particle compatibility layer covering Minecraft 1.20.x through 1.26.2.
- Replaced hard-coded particle references with adaptive lookups that gracefully handle Mojang's naming changes.
- Improved cross-version handling of legacy Bukkit APIs while preserving backwards compatibility.
- Better support for Paper and compatible server software with fewer version-specific quirks.
Under the Hood
- Refactored the villager housing system for greater reliability and easier maintenance.
- Improved internal architecture across several core managers.
- General code cleanup, structural refinements, and stability improvements throughout the project.
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:8no5Rtgr:1L9C5zxi"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:8no5Rtgr:1L9C5zxi"
}

