There is something funky going on with the energy consumption numbers of the digital miner. Possibly, base energy consumption is correct when you first load a world, but changing anything quickly gets things out of whack. For instance: standard ore filter, radius of 32, mining from 0-100, silk touch off, when you first log into the game and look, it lists a power usage of "96.41FE/t." Turn silk touch on, and it shows 3.71kFE/t. Turn silk touch back off, and it shows 232.38FE/t. Drop 10 energy upgrades in and nothing changes. Turn silk touch on and off, it now shows a usage of 23.23FE/t, which is a 10x (as expected from the energy upgrades) reduction from before. Log out and back in again, and it shows 96.41FE/t again. Cycle the silk touch button again, and it's back to 23.23FE/t.

All that said, the actual usage is in line with the "first logged in" numbers. Actual usage in the above configuration is 96.41 (or 9.64 with the energy upgrades) for no-silk touch. Actual usage with Silk touch on is 385.64FE/t, which jives with the "4x" cost for silk touch that I have in my config.

In summary, there are three issues:

1. Energy consumption doesn't properly update when upgrades are placed, until something in the main page changes it (e.g. silk touch toggling).

2. Silk touch is showing a 16x energy consumption increase, not a 4x increase (e.g. the square of my increase value). I tested this with a brand new config, and it did in fact go up to 36x with the default 6x increase.

3. Everything that is shown in the digital miner power usage is off by a factor of ~2.41 compared to actual consumption.

Steps to reproduce:

1. Place Digital Miner, energy source
2. Create a config, start the miner.
3. Observe disparities between actual and displayed consumption, observe silk touch causing a visual increase of (increase value)^2

Version:

Forge: forge-1.15.2-31.1.74
Mekanism: Mekanism-1.15.2-9.10.2.415
Other relevant version: MekanismTools-1.15.2-9.10.2.415, MekanismGenerators-1.15.2-9.10.2.415, MekanismAdditions-1.15.2-9.10.2.415

Is the issue just in the value it is displaying or is there also an issue in how much it actually is using compared to how much it is supposed to use?

I did a bit more testing. For instance, at the default values for radius, starting and end depths (10 radius, 0 to 60 depth), the displayed value and the actual usage are actually equal (40FE/t)! Silk touch usage is also correct (240FE/t), although displayed usage is wrong, as outlined above (it shows the square of the increase factor, 36x for the default value).

Once you get above the default values, things go wonky in terms of display of non-silk-touch usage as well, but actual usage seems to be correct. Using the formula outlined in the code here, everything seems to operate correctly in terms of actual usage.

I believe the display problem may be related to how you operate the method "setSilkTouch" from TileEntityDigitalMiner.java. This method (activated by toggling silk touch in the gui) calls "updateMinerEnergyPerTick()" (in MinerEnergyContainer.java)

That method starts by pegging the variable "minerEnergyPerTick" to "super.getEnergyPerTick()." This method (from the MachineEnergyContainer.java class file) sets the variable to current usage values.

When the container is first initialized (when creating / placing the digital miner), it is set to "baseEnergyPerTick" for the item (in this case, digital miner, presumably 40FE/t). As soon as any updates have occurred, though, "currentEnergyPerTick" is now = to whatever the current rate is. That new, higher number is then put through the silk touch, radius and depth / height calculations, essentially applying the silk touch and the radius / height factors a second time.

Basically, when you Toggle "Silk touch" in the interface, it calls "setSilkTouch." "setSilkTouch" directly calls "energyContainer.updateMinerEnergyPerTick()," thus feeding the current perTick value back through the silktouch/radius/height update. This is why everything is displaying higher values.

I believe "setSilkTouch" should be calling "energyContainer.updateEnergyPerTick()" (from MinerEnergyContainer.java), which both calls "super.updateEnergyPerTick()" and "updateMinerEnergyPerTick()". The former takes the base perTick value, and updates it for upgrades, the latter does the miner-specific silktouch/radius/height offsets. Directly calling "updateMinerEnergyPerTick()" is what is giving the false display values.

As an aside, when you add upgrades, nothing changes visually until something else updates the value (like toggling silk touch). The various upgrade trackers are updating the actual values for energy per tick, but the gui isn't updating the energy interface when you return from the config screen.

The evaluation of this is not quite right in terms of what the issue is. The issue has to do with some of those methods being called improperly on the client when they should only be called on the server, and then not properly updating the minerEnergyPerTick as well on the client when it gets told to update it from the server. Before I commit my changes I am going ahead and checking to see if there are any other energy containers we are also not properly updating.