0.8.2
Compatibility
Changes
Molten Veins 0.8.2
A fix release. The important one is that on newer Minecraft versions the NeoForge build could mine straight through claimed and protected land. If you run a server with a claim mod, this is the update you want.
Minecraft: 1.21.8, 1.21.9, 1.21.10, 1.21.11, 26.1, 26.1.1, 26.1.2, 26.2, 26.3 Loaders: Fabric and NeoForge
Fixes
Vein mining ignored claim and protection mods on NeoForge. This is the one worth updating for, and it is my fault in an irritatingly avoidable way.
When another mod blocks you from breaking a block, say a claim mod protecting someone else's base, it cancels the break. Molten Veins is supposed to notice that and stay out of it, and on the older versions it did. On the newer ones it did not. The block you actually hit stayed put, correctly protected, and then Molten Veins happily mined the whole vein, tunnel or layer around it anyway. So the protection looked like it was working while the land got dug out from under it.
The reason is dull. Minecraft renamed the event in question for the newer versions, I copied the code over to match the new name, and the check got dropped on the way across. It is back now.
This affected NeoForge on 26.1, 26.1.1, 26.1.2, 26.2 and 26.3. The NeoForge builds for 1.21.8 through 1.21.11 always had the check and were never affected. Fabric handles this differently and is not affected either.
Blocks with contents could drop the wrong loot when mined one at a time. Vein mining was
fixed for this a few releases back, but the single block path never got the same treatment, so
it was throwing away information the loot table needed. In practice you would only have hit this
if you added a container-like block to extraBlocks in the config yourself, but it could have
dropped the wrong items or nothing at all, and on an unlucky loot table it could have crashed
the break outright. Both paths now behave the same way.
Your settings could quietly stop applying partway through a break. A safeguard rather than a confirmed sighting, so I will be straight about it. The mod keeps track of whose settings apply while it is working through a break, and because it also hands control to other mods during that window, a mod that started its own break inside ours could knock that tracking over. Once that happened, the rest of the break silently used the server's settings instead of yours. I could not get it to actually happen on demand, but the hole was real, so it is closed.
The NeoForge builds refused to load on point releases. The 26.2 and 26.3 NeoForge jars were pinned to exactly those versions, so if Mojang shipped, for example, a 26.3.1, the jar would have refused to start rather than just working. They now accept point releases within the same version. The Fabric jars already did this correctly, so nothing changed there.
NeoForge 26.3 is on a much newer beta
26.3 support shipped in 0.8.1 built against 26.3.0.6-beta, which was current at the time.
NeoForge has put out around fifty builds since, so this is now built against
26.3.0.52-beta.
Nothing in the mod needed changing for it. I read every NeoForge change in between and then rebuilt the whole lot to confirm it, and none of it touches anything Molten Veins uses.
The 26.3 NeoForge jar now needs 26.3.0.52-beta. If you are on an older 26.3 beta, update
NeoForge or stay on 0.8.1. If you are on a newer one, read the next section, because right now
.52 is the one you want.
Heads-up: avoid NeoForge 26.3.0.53, .54 and .55
I built against .52 rather than the newest beta on purpose, and it is worth explaining why,
because if you are on one of those three builds you will hit this whatever mods you run.
NeoForge .53 moved its update checker into a different package, and on the way it changed how
it looks up a mod's version-check result. It used to fall back to a safe placeholder when a mod
had no result yet. Now it returns nothing at all, and the code that reads it never checks for
that. The upshot is that the Mods button on the title screen falls over while drawing itself, and
the game crashes before you ever reach the menu.
It is not caused by any mod, and no mod can work around it. The very first entry in the list it
walks is Minecraft itself, so it happens with an empty mods folder too. .53, .54 and .55
are all affected.
If you are on 26.3 NeoForge, use .52 until they ship a fix. I will move Molten Veins onto
a newer beta once that lands. And to be clear, none of this touches the Fabric builds or any
Minecraft version other than 26.3.
Which jar do I want
| Minecraft | Fabric | NeoForge |
|---|---|---|
| 1.21.8 | moltenveins-0.8.2-mc1.21.8.jar |
moltenveins-neoforge-0.8.2-mc1.21.8.jar |
| 1.21.9 | moltenveins-0.8.2-mc1.21.9.jar |
moltenveins-neoforge-0.8.2-mc1.21.9.jar |
| 1.21.10 | moltenveins-0.8.2-mc1.21.10.jar |
moltenveins-neoforge-0.8.2-mc1.21.10.jar |
| 1.21.11 | moltenveins-0.8.2-mc1.21.11.jar |
moltenveins-neoforge-0.8.2-mc1.21.11.jar |
| 26.1 / 26.1.1 / 26.1.2 | moltenveins-0.8.2-mc26.1-26.1.1-26.1.2.jar |
moltenveins-neoforge-0.8.2-mc26.1-26.1.1-26.1.2.jar |
| 26.2 | moltenveins-0.8.2-mc26.2.jar |
moltenveins-neoforge-0.8.2-mc26.2.jar |
| 26.3 | moltenveins-0.8.2-mc26.3.jar |
moltenveins-neoforge-0.8.2-mc26.3.jar |
Grab the one matching your version and your loader, drop it in mods, done.
Fabric: Fabric Loader plus Fabric API. NeoForge: the matching NeoForge version. On 26.3
use 26.3.0.52-beta, and avoid .53 through .55 for the reason above.
Java: 21 for the 1.21.x jars, 25 for the 26.x jars.
Your config carries straight over and no settings changed this release.
Found something broken? Come tell me, I'd genuinely rather know.
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:XvxD0SDK:xITWzKg2"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:XvxD0SDK:xITWzKg2"
}

