Energy Acceptor not accepting Iron Furnace power on 1.21.1
OceanSnipe17 opened this issue ยท 4 comments
Describe the bug
When using the Iron Furnace mod as a power source for AE2, the Energy Acceptor does not take power from a furnace in "generator" mode.
How to reproduce the bug
Use any Iron Furnace with the Generator Augment so it produces power instead of acting like a furnace. Try to have an Energy Acceptor pull power from it for an ME system.
Expected behavior
To use the Energy Acceptor as the intake for power and not the ME Controller as recommended in the AE2 guide.
Additional details
The ME Controller does work with the Iron Furnace despite the Energy Acceptor not.
Which minecraft version are you using?
1.21
On which mod loaders does it happen?
NeoForge
Crash log
I cross posted on Iron Furnace's page as well.
Qelifern/IronFurnacesNeoForge#11
I ran a small test with a debugger attached: A small AE network (drives, wireless AP etc) with a ME Controller consisting of two blocks, one of them directly next to a Diamond Furnace with Augment: Generator installed and powered by blocks of coal, also configured to output to the relevant side, auto output off. This initially powered the network and kept it running. With some break points I could verify that ControllerBlockEntity.funnelPowerIntoStorage
was called regularly, coming from ForgeEnergyAdapter.receiveEnergy
.
Then I put down an Energy Cell in the network which instantly filled up but afterwards the debugger did not trigger on any of the breakpoints anymore. My initial intuition was that somehow drawing massive amounts of energy broke the output behavior of the Diamond Furnace.
I then broke the controller adjacent to the furnace, placed it down anew and received exactly one trigger of the ForgeEnergyAdapter.receiveEnergy
breakpoint. This could be repeated multiple times.
I then broke the controller adjacent to the furnace, placed an energy acceptor (full block) there and it did not trigger the ForgeEnergyAdapter.receiveEnergy
breakpoint at all. Replacing the energy acceptor with another controller block (as before) led to the same behavior of getting the breakpoint exactly once.
I then waited to the energy stored in the controller and the energy cell to be depleted. During that time no breakpoint was triggered and the energy generation displayed in the controller GUI was 0. After reaching a stored power of 16.56 kAE (which is close to what the two controller blocks can store when the energy cell is empty) when watching the controller GUI I noticed a breakpoint trigger (which was only just then installed) of ControllerBlockEntity.emitPowerStateEvent(RECEIVE_POWER)
, followed by a trigger of ForgeEnergyAdapter.receiveEnergy
, after which the energy cell was filled up again and the energy draining started anew.
I then replaced the controller adjacent to the furnace again with an energy acceptor (full block), waited until the energy drained and got the ControllerBlockEntity.emitPowerStateEvent(RECEIVE_POWER)
at 16.68 kFE (note the changed unit of power measurement here). Continuing did not trigger any further breakpoints, in particular not the ForgeEnergyAdapter.receiveEnergy
one, the power drain continued and the network eventually ran out of power.
In this state I removed the energy cell from the network, replaced the energy acceptor with another controller and received a ForgeEnergyAdapter.receiveEnergy
breakpoint trigger, followed by a ControllerBlockEntity.emitPowerStateEvent(PROVIDE_POWER)
trigger, followed by a series of (ControllerBlockEntity.emitPowerStateEvent(RECEIVE_POWER)
trigger, ForgeEnergyAdapter.receiveEnergy
trigger).
I then removed the controller adjacent to the furnace again, let the network drain completely, installed an energy cell again, then placed down an energy acceptor which did not trigger any breakpoint. Replacing it with another controller triggered ForgeEnergyAdapter.receiveEnergy
, then ControllerBlockEntity.emitPowerStateEvent(PROVIDE_POWER)
, then ControllerBlockEntity.emitPowerStateEvent(RECEIVE_POWER)
and started the power draining cycle again.
So for my next test I used energy pipes from pipez between the diamond furnace and the controller. In this scenario, ForgeEnergyAdapter.getEnergyStored
and ForgeEnergyAdapter.getMaxEnergyStored
was not called, but ForgeEnergyAdapter.receiveEnergy
was called frequently, slowly (since I installed not upgrades on the energy pipe) the energy cell began to fill up. This also worked for the energy acceptor.
My current hypothesis is that Iron Furnaces is responsible for that behavior and somehow tries to be clever to not actually call ForgeEnergyAdapter.receiveEnergy
if there is no free space in the block itself without considering that the block could use the energy for something else than just storing it internally.
Also I could see that ForgeEnergyAdapter.receiveEnergy
is called with simulate = true
and simulate = false
alternating by Pipez, whereas Iron Furnaces only calls ForgeEnergyAdapter.receiveEnergy
with simulate = false
. The fix might be for Iron Furnaces to replace the manual check via ForgeEnergyAdapter.getEnergyStored
and ForgeEnergyAdapter.getMaxEnergyStored
with a proper call to ForgeEnergyAdapter.receiveEnergy
with simulate = true
. But I'm no expert in this, maybe some more qualified comes to a better conclusion.
Maybe it is also a question of push vs pull?
I removed all breakpoints and installed one for StoredEnergyAmount.sendEvents
. For simplicity I reduced my setup to only have one instead of two controllers, the remaining one being the one adjacent to the furnace. The energy cell was already somewhat drained (289 kFE) when I armed the breakpoints. I could see that the StoredEnergyAmount
for the energy cell had a state of (isReceiving = true
and isProviding = true
) the entire time while the controller switched back and forth between (isReceiving = true
and isProviding = true
) and (isReceiving = false
and isProviding = true
), depending on whether it was full (i.e. maximum = stored) or not. This leads to a frequently emitted event of GridPowerStorageStateChanged.PowerEventType.RECEIVE_POWER
by the controller.
I then added breakpoints for ForgeEnergyAdapter.getEnergyStored
and ForgeEnergyAdapter.getMaxEnergyStored
which were triggered frequently. Since the sink
in that code refers to the controller and the controller is fully charged at that time I would imagine that someone (neoforge itself? Iron Furnaces?) decides that no power can be put into the controller at that point in time and decides not to do so. I would guess this is effectively a race condition between the energy cell topping off the controller and the furnace checking if the controller is full. Maybe the code should ask the entire grid if it is full, not the particular controller?
Since the energy acceptor always has an internal storage of 0 (max and current), it will never receive any power if this assumption is correct.