All versions
1.1+26.2
Release
MobRules 1.1+26.222 hours ago 9
Uploaded by
Compatibility
Minecraft: Java Edition
26.2
Platform
NeoForge
Supported environments
Client and server
Changes
v1.1 Changelog
This update introduces a major refactor of the spawning logic to provide more granular control and better integration with modded mobs.
Changes
- Unified Mob Classification: Mobs are now classified into three distinct categories (Hostile, Farm, and Aquatic) based on their vanilla spawn category. This ensures automatic support for modded mobs.
- Improved Control Modes: Each category now supports three levels of control:
allow_all,block_all, andallowlist. - Category Overrides: Added a new
category_overrides.jsonconfiguration file, allowing you to reclassify any mob into a different category (e.g., treating a frog as an aquatic animal instead of a farm animal). - In-Game Commands: Introduced the
/mobrulescommand system (requires operator permission level 2):/mobrules status: View current control modes and allowlist sizes./mobrules reload: Reload configurations and allowlists from disk without restarting./mobrules allow <category> <mobId>: Add a mob to a specific allowlist in-game./mobrules disallow <category> <mobId>: Remove a mob from an allowlist in-game.
- Persistence: Allowlist changes made via commands are now automatically saved to their respective JSON files.
- Unified Config File: Spawn-control settings moved from a per-world
SERVERconfig to a single globalCOMMONconfig (config/mobrules-common.toml), so the same rules apply on both the client and the server. Note: existing per-worldserverconfig/mobrules-server.tomlfiles are no longer used. - Config Loading: Allowlists and category overrides are now loaded on client initialisation and on server start, rather than during common setup.
- Updated Dependencies: Updated Gradle wrapper to 8.14.5 and properties to reflect the latest project standards.
Fixes & Technical Improvements
- Refactored
MobSpawnHandlerto use a single evaluation point per mob, improving performance and consistency. - Standardized config file management in the
config/mobrules/directory. - Switched to atomic configuration reloads to ensure thread safety during spawn evaluations.
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:e3ZWj3LB:bOthJnA4"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:e3ZWj3LB:bOthJnA4"
}

