Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Energy Acceptor not accepting Iron Furnace power on 1.21.1 #8204

Open
OceanSnipe17 opened this issue Sep 28, 2024 · 4 comments
Open

Energy Acceptor not accepting Iron Furnace power on 1.21.1 #8204

OceanSnipe17 opened this issue Sep 28, 2024 · 4 comments
Labels
bug Self explanatory?

Comments

@OceanSnipe17
Copy link

OceanSnipe17 commented Sep 28, 2024

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.
2024-09-28_17 16 17
2024-09-28_17 16 34
2024-09-28_17 16 57
2024-09-28_17 20 39

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

https://pastebin.com/Kpjysswc

I cross posted on Iron Furnace's page as well.
Qelifern/IronFurnacesNeoForge#11

@shartte
Copy link
Member

shartte commented Sep 28, 2024

Now that is odd, the acceptor definitely implements the corresponding cap.

@Mithi83
Copy link
Contributor

Mithi83 commented Sep 30, 2024

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.

@Mithi83
Copy link
Contributor

Mithi83 commented Sep 30, 2024

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.

@Mithi83
Copy link
Contributor

Mithi83 commented Sep 30, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Self explanatory?
Projects
None yet
Development

No branches or pull requests

3 participants