Fix Robot Arm Transfer Exact exceeding the configured rate

[Cyber1551]

What

Robot Arm covers set to "Transfer Exact" can move items up to 4 times faster than their rated transfer rate.

For example, a LV Robot Arm (8 items/s) can act like an MV one (32 items/s), assuming it is supplied with enough items to satisfy "Transfer Exact"

In Exact mode the cover only ever moves a full batch at once, so if it can't move a full batch right now it holds back and saves up its unused transfer rate until it has enough for one.

The bug: while it's saving up, it does so several times faster than the rate should allow, and once it has enough it sends a batch. Because saving up costs it nothing, it keeps sending batches far more often than the rate permits.

This only shows up when a batch size leaves leftover rate to save, such as any size that doesn't divide evenly into the per-second transfer rate (including any size larger than it). Sizes that divide evenly leave nothing to save and stay correct.

For example, with an LV Robot Arm it should be capped at 8 items/s:

• Transfer Exact 2, 4, or 8: these are correct, and average out at ~8 items/s
• Transfer Exact 3: Too fast, at ~9 items/s.
• Transfer Exact 5: Too fast, at ~12 items/s
• Transfer Exact 64: Moved a stack every 2 seconds, equaling ~32 items/s, which is the speed of an MV arm.

The Fluid Regulator already handles this same feature correctly, this just brings the Robot Arm in line with it.

Implementation Details

update() reduces the per-second transfer rate by whatever doTransferItems returns

int totalTransferred = switch (io) {
    case IN -> doTransferItems(adjacent, self, itemsLeftToTransferLastSecond);
    case OUT -> doTransferItems(self, adjacent, itemsLeftToTransferLastSecond);
    default -> 0;
};

// RIGHT HERE
this.itemsLeftToTransferLastSecond -= totalTransferred;

doTransferExact (and consequently doTransferItems) returns the wrong amount in two cases:

• While buffering, nothing actually moves, so itemsTransferred is still 0 and the method returns
  Math.min(0, maxTransferAmount) = 0. This means the rate is never decremented in update(), so the next tick buffers again against the full rate. update() runs every 5 ticks (4 times a second), so itemsTransferBuffered grows ~4× faster than intended.
• When a buffered batch finally moves, the same Math.min caps the reported amount at maxTransferAmount even when more was moved, undercharging the rate again.

Together these let exact batches move items numerous times faster than the configured rate.

The fix makes doTransferExact report the right number back to update() in both cases:

• When it moves a batch, return the amount it actually moved (not a Math.min-capped value)
• When it only saves up, return the amount of rate it used that tick (not just 0).

Once the rate is charged correctly, the cover can no longer save up faster than its rate allows...which is how FluidRegulatorCover.transferExact already works. TRANSFER_ANY and KEEP_EXACT are unaffected.

AI Usage

• Yes AI driven tools were used for this pull request.

Agent Used

Claude Sonnet 4.6 Chat

Agent Usage Description

Used to help write this PR description in a cleaner way. This code is actually from an addon mod I built where I already fixed this bug, so no AI was needed for coding purposes as the work was already done.

Even with AI's help, I still feel like I did a poor job explaining the specific mechanics of what causes the bug in the code and how my change fixed it, so hopefully it's simplified enough. If not, I'm happy to explain anything specific in more detail.

Outcome

Fixes Robot Arm covers exceeding the configured transfer rate in Transfer Exact mode.

How Was This Tested

Tested in game with an LV Robot Arm exporting from a stocked source to a void target, comparing "Transfer Exact" against "Transfer Any" across several batch sizes.

Additional Information

Players relying on the current (too-fast) exact behavior will see exact transfers slow to the rated rate. Because the rate is now enforced, a large exact batch on a low-tier cover has to save up before it fires

For example, a LV Robot Arm (8 items/s) set to Transfer Exact 1024 waits ~2 minutes, then moves all 1024 at once, and repeats. That's the honest cost of "move exactly 1024 at a time" at 8 items/second (1024 / 8 = 128 seconds), not a freeze, and it matches how the Fluid Regulator already behaves. Before this fix it would move the 1024 items every 32 seconds (4x faster)

Potential Compatibility Issues

None. I made no API, recipe, or block changes. Behavior only.