Speedmine for QuinnAddon

What was done

• Ported THM-Addons' Speedmine (branch 26.2, 1,507 lines) into QuinnAddon: Yarn mappings throughout, and every THM-only support class swapped for a Meteor equivalent or a local one.
• Fixed nine defects of the original. Kept as a separate file from the straight port, so the fixes can be reviewed on their own.
• Builds clean on Minecraft 1.21.11 — compileJava, jar, remapJar — and the jar carries the module and both accessors.
• Not run in-game. Runtime behaviour and anticheat response are still untested.
• Two mixins have to be registered, and THM's licence asks that the credit header stays. Both are covered below.

What you get

Builds

Built here from the source on this site, against Minecraft 1.21.11, Yarn 1.21.11+build.3 and meteor-client:1.21.11-SNAPSHOT. The hashes are there so you can tell the file did not change on the way to you; they say nothing about what is inside it, which is why the source is on the same page.

If you are the tester: take the first jar, put it in mods beside Meteor, and do not run the normal QuinnAddon at the same time — they share the Speedmine module even though the ids differ. Nothing here has been run in-game, so anything you see is new information. The part most worth hammering is speedmine, and the rebreaks in particular: turn on debug-rebreak and it reports confirmed rebreaks per second beside the module name, which is a number worth writing down and comparing against whatever you normally use. Worth saying out loud: breaking is the dangerous half of a packet miner, so test it somewhere you can afford to lose what you are standing on.

Inventory Cleaner and Auto Accept

Neither of these was asked for. They are Rei's, added on his own initiative because he wanted them in the test build. Speedmine does not depend on either, so they can be dropped without touching anything else — say so and they come out.

Both arrived as finished code. Neither compiled here, and both had something worth fixing before a tester runs them. The originals are on the source page beside the fixed ones.

• Neither built. Inventory Cleaner used Category.Misc, but Category is the class, not the list of them. Auto Accept imported an Addon class and a utils.Utils helper that QuinnAddon does not have. Auto Accept also called GameProfile.getName(), which is now a record accessor, name().
• Auto Accept answered anyone who typed the phrase. It matched the request text anywhere in chat, so another player could say "Someone has requested to teleport to you" and have you run the accept command at them. Messages shaped like player chat are now ignored, and the name has to belong to somebody on the player list.
• Auto Accept spammed. Servers re-announce a pending request every so often and it answered every announcement. There is a per-player cooldown now, 30s by default.
• Auto Accept read the name as the first word of the message, which breaks on any server that prefixes a rank. It now matches against the tab list instead, so the message format stops mattering. /tpy is a setting too — it is not universal.
• Inventory Cleaner threw container contents. It ran with a chest or shulker open, where those slot numbers address the container rather than your inventory. It now waits until no container is open, and leaves the slot you are holding alone by default, so the blocks you are placing with do not go out of your hand.

Still not covered: the offhand is outside the range Inventory Cleaner walks, and Auto Accept's chat check is a heuristic — a server with an unusual chat format could still get through it, which is what the player-list check is there to catch.

The code itself

Both versions, the diff between them and the two mixins are on their own page, in full, with a raw link beside each for copying.

Open the source →

Credit and licence

Install

Four files in, two files get a line each. Take Speedmine from fixed/, not port-only/ — same class name, so only one of them can sit in the repo at a time.

src/main/java/com/example/addon/
  modules/Speedmine.java
  mixin/ClientPlayerInteractionManagerAccessor.java
  mixin/ClientWorldAccessor.java
  mixin/PlayerMoveC2SPacketAccessor.java

// addon-template.mixins.json
"client": [
    "BetterTabPlusMixin",
    "ClientPlayerInteractionManagerAccessor",
    "ClientWorldAccessor",
    "PlayerMoveC2SPacketAccessor"
],

// QuinnAddon.java
modules.add(new Speedmine());

Two of the three mixins are required: vanilla's sendSequencedPacket is private and ClientWorld.getPendingUpdateManager() is package-private, and the miner needs both to put a sequence number on a dig packet and to keep rebreak rollbacks honest. PlayerMoveC2SPacketAccessor is only for the Air Miner — drop that settings group and you can leave it out.

Why it isn't a copy-paste

THM builds against Mojang mappings; QuinnAddon uses Yarn. Every Minecraft type and method differs, so not one line compiles as-is. On top of that, THM leans on its own support classes, none of which exist here. Each one had to be replaced — this is true even of port-only.

One of those is worth a second look. THM wrote the vanilla mining formula out by hand, in two places that had drifted apart; Meteor ships the same calculation, so the port is shorter and can't disagree with itself. The world-update mixin also disappeared, since Meteor fires BlockUpdateEvent for exactly that.

Where this differs from THM

All 35 settings are here; none dropped, none added. These are the behavioural differences, and each one exists because QuinnAddon does not have the system THM leans on. Worth knowing before you compare the two side by side.

• Pause and priority. THM arbitrates through its InventoryManager, so eating and other modules holding the inventory can pause mining. Here it is isUsingItem(). If AutoTotemPlus and Speedmine end up fighting over the hotbar slot, that is where a shared lock belongs.
• Packet-send confirmation. THM watched its own dig packet leave and refused to mark a block as started if it never went out. This port sends through vanilla's sendSequencedPacket and assumes success. Nothing in QuinnAddon cancels those packets today, but a module that did would make the miner believe it had started.
• Packet-limiter awareness. THM detects a limiter blocking hand swings and warns that bedrock will silently fail to break. No such module here, so the check is gone.
• Mining speed. Meteor's getBreakDelta does everything THM's hand-written formula did except the BLOCK_BREAK_SPEED attribute, which THM multiplied in. That attribute is 1.0 unless something changes it, so it costs nothing on a normal server.
• Friends. THM also skips its own clan list. Only Meteor's Friends list is consulted here.
• Per-option help text. THM shows a line of help under each enum option through its own interface. QuinnAddon has no equivalent, so that text was folded into each setting's own description instead — nothing was lost, it just reads in one place.
• Settings migration. THM's fromTag() rewrites its own older configs. There is nothing here to migrate.

The nine fixes

1. A declined click did nothing at all

   The break event was cancelled before deciding whether to mine the block. With multitask off and an item in use, left-clicking a block neither packet-mined it nor fell back to vanilla mining. handleBlockClick now reports whether it took the block, and the event is cancelled only then.

2. requestBreak could stall the whole module

   It only checked for air. An unbreakable block passed in by another module produced a context with zero progress that the removal check never cleared, so the primary slot stayed occupied forever. It now validates the block, and any context making no progress for 3s is dropped. The original's unused startMs field looks like this timeout was planned and forgotten — it is used now.

3. One queue insert stored a mutable BlockPos

   Three of the four inserts called immutable(); one didn't. Harmless with today's callers, and silent corruption the day a MutableBlockPos reaches it.

4. A replaced block kept being mined as the old one

   The context holds the BlockState it started on while the removal check reads the live world, so swapping the target block left it mining with the old hardness and firing the old block's break particles.

5. Surround ring sat one block too high

   Math.round on the enemy's Y, so standing on a slab, snow layer or soul sand shifted the whole ring up. Floored now.

6. Dead players were still targeted

   isSpectator was checked, isAlive was not, so the picker kept digging around a corpse for the whole death animation.

7. The tool search could never return "no tool"

   It started at -1, which an empty hand already beats, making every no-tool branch dead code. Ties also went to the lowest hotbar index, so it swapped away from an equally good tool already in hand. It now starts from the selected slot, which also means fewer slot packets.

8. One timeout, written twice

   The rebreak deadline existed as 2000 ms in one place and 2_000_000_000 ns in another. One constant now, the other derived.

9. Outline ignored rebreak-mode Off

   Every other rebreak check tested the mode; the "last broken block" outline didn't, so it drew with rebreaks disabled.

Left alone on purpose

• anti-surround only runs when no enemy yields an anti-phase target. One phaseable enemy therefore suppresses everyone else's surround. The original's own comments show this is deliberate, so it's a design call for you, not a defect for me.
• tps-sync still defaults off. With it off, progress is timed as wall clock × 20 ticks, so STOP goes out too early on a lagging server. Deriving break-threshold from measured ping, or syncing automatically below ~19 TPS, is the real answer — but that's a feature, not a fix.

Build check

On the insta rebreak question

The idea post asked whether this is on FutureClient / Mio speedmine level, specifically at insta rebreak. Having read the whole file: the rebreak path is the most worked-on part of it.

• Four modes. Strict waits for server confirmation between rebreaks. Strong skips the confirmation wait and the TPS start delay entirely. Bypass runs Strict until one rebreak is confirmed and then switches to Strong, which is an anticheat-aware ramp rather than a flat setting.
• Packet-triggered. With rebreak-trigger on OnPacket it reacts to the server's block update as it arrives instead of waiting for the next client tick. That is where the speed comes from.
• It ships its own measurement. debug-rebreak counts server-confirmed rebreaks per second and shows the figure beside the module name. Whoever wrote it was tuning against a number, not a feeling.

Whether it actually matches those clients is measured, not read, and none of this has been run in-game. But the answer is one setting away: turn on debug-rebreak, run the others the same way, and compare.

Worth doing in QuinnAddon

Three things I ran into while porting. None of them block this module; the first will bite eventually.

• Nothing arbitrates the hotbar. SurroundPlus and LogStripper each swap slots on their own, and Speedmine now tracks its own server slot too, because there is no shared place to ask. In a fight those run at the same time — placing while mining is the whole point of the module — so sooner or later one swaps out from under another, and in cpvp that is a death rather than a glitch. THM handles it with a single InventoryManager that every module asks before swapping. It is also the one difference in this port that cannot be fixed from inside the module.
• The mod id is still the template's. fabric.mod.json carries "id": "addon-template", so any other addon built from the unmodified Meteor template collides with it. sources still points at MeteorDevelopment/meteor-addon-template as well.
• The version strings never got bumped. Tag v0.4.0 points at eb508f9, and at that commit build.gradle.kts and libs.versions.toml both still say 0.2.3 — so building the v0.4.0 source gives you a jar called QuinnAddon-0.2.3.jar. You have probably already worked around it when cutting the release; it is only a problem for anyone building from source.