Description
While reviewing the code for ic2.core.block.machine.low.TileEntityMiner (the Miner's tile entity), I identified a potential issue that I have since confirmed through testing.
Problem Summary
The Miner's mine() method uses a short counter named miningTicker. When miningTicker exceeds 200, the Miner performs one mining operation and resets the counter to zero. The counter is incremented by a bonus derived from the drill material and enchantments, calculated in getExtraSpeed().
For the Diamond Drill, the speed bonus is level² + 4 (for the basic drill, it's level² + 1). In normal survival, the maximum legitimate Efficiency level is 5, so this poses no problem. However, if a player obtains an Efficiency level above 181 (e.g., via commands or other mods), the computed bonus overflows the short range.
Example
- Efficiency 182 → bonus = 182² + 4 = 33128
- Cast to
short → signed overflow yields -32407
This negative value is then added to miningTicker, preventing it from ever reaching the >= 200 threshold. Consequently, mineBlock() is never called, and the Miner stops mining.
Critical additional impact: The energy consumption check occurs before the miningTicker >= 200 condition. This means the Miner will continue to drain EU periodically without performing any mining operation, effectively wasting energy indefinitely.
Steps to Reproduce
- Equip a Diamond Drill with Efficiency 182 (using commands or a mod that bypasses the vanilla cap).
- Place a Miner and supply it with sufficient EU.
- Observe that the Miner consumes energy at regular intervals but never mines any blocks.
- Compare with Efficiency 181 (bonus = 181² + 4 = 32765, within
short limit) – the Miner mines extremely fast and reaches bedrock quickly.
Expected behavior
Mining speed should saturate at some reasonable maximum, and energy consumption should not continue when mining is impossible. Even with extremely high enchantment levels, the Miner should either mine at maximum speed or handle overflow gracefully.
Suggested Fix
A simple saturation mechanism would prevent the overflow:
this.miningTicker = (short)Math.min(200, (this.miningTicker + drill.getExtraSpeed((ItemStack) this.inventory.get(3))));
Similarly, getExtraEnergyCost() may should be capped to match the maximum effective speed, so that energy consumption does not exceed what is needed for a saturated miner.
Thank you for considering this fix.
Testing Picture
Description
While reviewing the code for
ic2.core.block.machine.low.TileEntityMiner(the Miner's tile entity), I identified a potential issue that I have since confirmed through testing.Problem Summary
The Miner's
mine()method uses ashortcounter namedminingTicker. WhenminingTickerexceeds 200, the Miner performs one mining operation and resets the counter to zero. The counter is incremented by a bonus derived from the drill material and enchantments, calculated ingetExtraSpeed().For the Diamond Drill, the speed bonus is
level² + 4(for the basic drill, it'slevel² + 1). In normal survival, the maximum legitimate Efficiency level is 5, so this poses no problem. However, if a player obtains an Efficiency level above 181 (e.g., via commands or other mods), the computed bonus overflows theshortrange.Example
short→ signed overflow yields -32407This negative value is then added to
miningTicker, preventing it from ever reaching the>= 200threshold. Consequently,mineBlock()is never called, and the Miner stops mining.Critical additional impact: The energy consumption check occurs before the
miningTicker >= 200condition. This means the Miner will continue to drain EU periodically without performing any mining operation, effectively wasting energy indefinitely.Steps to Reproduce
shortlimit) – the Miner mines extremely fast and reaches bedrock quickly.Expected behavior
Mining speed should saturate at some reasonable maximum, and energy consumption should not continue when mining is impossible. Even with extremely high enchantment levels, the Miner should either mine at maximum speed or handle overflow gracefully.
Suggested Fix
A simple saturation mechanism would prevent the overflow:
Similarly,
getExtraEnergyCost()may should be capped to match the maximum effective speed, so that energy consumption does not exceed what is needed for a saturated miner.Thank you for considering this fix.
Testing Picture