Tags
Creators
Details
1.7
Compatibility
Changes
⚙️ TheMob v1.7 – Automation, Scaling & System Transparency (STABLE)
TheMob v1.7 is now officially released. This update marks a core system milestone for TheMob and replaces the previous v1.7 Beta.
v1.7 is not about adding more mobs. It is about making every spawn predictable, observable and safe under load — even on large, long-running servers.
This release unifies Automation & Scaling with Monitoring & Diagnostics into a single, stable framework designed for production environments.
🎯 Design Goal
Give server operators explicit, system-level control over spawning and performance:
Load-aware
Player-count aware
World-aware
Restart-safe
Exploit-safe
No silent spawn blocking. No guesswork under lag. Every decision is enforced by the system and visible to admins.
🧠 Core Focus in v1.7
Automation
Dynamic scaling
Transparency
Admin diagnostics
v1.7 is operator-first, not content-first.
⚙️ Automation & Scaling (v1.7 Core) 🌍 Global Spawn Budgets
Hard, system-level limits for:
Total mobs
Bosses
Minions
Optional per-world caps
Behavior
Budgets block new spawns only
No forced despawns
No entity flicker
Bosses and mobs are tracked independently
Use case Large survival servers, networks, event worlds, long uptimes
📉 Auto-Spawn Throttling (TPS-Aware)
Spawning adapts automatically to server performance.
Throttle states
NORMAL
WARNING
CRITICAL
HARD_STOP
Behavior
Spawn intervals slow down as TPS drops
HARD_STOP safely pauses spawning under critical load
No manual admin intervention required
Use case Peak hours, boss events, mass player activity
👥 Dynamic Scaling by Player Count
Spawn intensity scales with online players.
Behavior
Prevents over-spawning on full servers
Prevents empty worlds on low population
Scaling is global and predictable
Applied before spawn execution
Use case Servers ranging from a handful of players to hundreds online
⏱ Cross-Restart Boss Cooldowns
Boss spawns are now fully restart-safe.
Behavior
Cooldowns persist across server restarts
Prevents restart abuse and boss farming
Enforced at spawn-gate level
Use case World bosses, rare encounters, scheduled events
📊 Monitoring & Diagnostics (Integrated) 🧪 Admin Diagnostics Commands
New diagnostics commands provide live system insight:
/mob diag
/mob debug
Live data includes
TPS & MSPT
Current throttle state
Effective spawn interval
Player-based scaling multiplier
Alive mobs, bosses and minions
Spawn attempts vs blocked spawns (budget / throttle / cooldown)
No more “nothing is spawning” situations without answers.
📈 Live Spawn Statistics
TheMob now tracks:
Total spawn attempts
Successful spawns
Blocked spawns by reason
Boss vs mob separation
All values are live, system-driven and diagnosable in-game.
👑 Boss Performance Metrics
Boss encounters are fully observable:
Active boss tracking
Cooldown state visibility
Budget interaction
Phase-based combat modifiers
Boss fights can now scale without losing control or stability.
📡 System Transparency via bStats
v1.7 introduces official bStats integration to provide high-level, anonymous system transparency.
Collected data (anonymized)
Number of servers using TheMob
Player counts
Minecraft versions
Java versions
Server software
Custom metrics
Defined mobs
Active auto-spawns
Core system usage over time
No IPs. No player identities. No server names.
This data helps guide future development and ensures TheMob evolves based on real-world usage, not assumptions.
📊 Live stats: https://bstats.org/plugin/bukkit/TheMob
🛡️ Lifecycle & Safety Guarantees
All v1.7 systems share a unified lifecycle:
Spawn budgets are always enforced
Boss locks prevent duplicates
Cooldowns persist across restarts
/mob reload behaves like a full restart
No ghost mobs
No stuck BossBars
No duplicate HUDs
⚙️ Performance Notes
No per-tick world scans
No NMS usage
No forced despawns
Bounded chunk interaction
UUID-based entity tracking with fallback cleanup
Designed for long-running servers
✅ Release Status
v1.7 is a stable release.
No config migration required
Fully compatible with v1.6 setups
Safe for production servers
Battle-tested under real load
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:8hhaeY0e:3X8CJ3RZ"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:8hhaeY0e:3X8CJ3RZ"
}

