Links
Tags
Creators
Details
2.0.0
Compatibility
Changes
Vein Miner Revival
Vein Miner Revival brings the classic vein mining back to modern Forge, rebuilt from the ground up with a strict client/server authority model - hosts and server admins stay fully in control, while every player keeps their own personal preferences. Break one ore, log, or configured block, and the whole connected vein comes with it (within the limits the server allows).
Server-Authoritative Settings (Host/Op Only)
These settings apply server-wide and can only be changed by the host or an op with permission level 2+. Clients can see these values in the config screen, but never override them:

Player Preferences (Client-Side, Server-Validated)
Every player tunes their own experience. The server validates and clamps everything against its own limits before anything takes effect, so a misconfigured or modified client can never exceed server rules:

Safety Features
- Tool-swap protection - if you switch your held item mid-vein (different item type), the job safely stops rather than continuing with a different tool than you started with
- Hunger safety - configurable soft-stop at low hunger, plus an unconditional hard stop at zero hunger that no setting can override
Built for Multiplayer
Every rule that matters for fairness and server stability - block caps, break delay, hunger penalties, tool requirements - is enforced authoritatively on the server, re-validated independently of whatever a client sends. Per-player preferences sync automatically on join and whenever you save changes in the in-game config screen (bound to Right Shift by default).
Whether you're hosting a small SMP with friends or running a public server, Vein Miner Revival gives you the controls to make vein mining feel exactly the way you want it to.
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:Df9eFxJU:M4JrQham"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:Df9eFxJU:M4JrQham"
}

