Issue type:

• 🐛 Bug

Short description:

When Thermal machines completely fill up, they seem to stop pulling from the energy network entirely. This causes energy importers (such as the one attached to my dynamo) to error because there seems to be ambiguity on whether to still send power to the machine or not. I'm actually not entirely sure on which side this issue lies, but this is the error printed in the importer's interface:

Steps to reproduce the problem:

1. Attach a Thermal dynamo and any Thermal energy consumer to an IT energy network.
2. Overproduce power such that the consumer is filled up completely.
3. The connection will reset and fail until you manually re-add the variable card to the importer.

Expected behaviour:

Since there is no energy storage attached to the network, I would have expected the machine to stop requesting energy from ID, and/or the energy interface to stop sending it as there are no targets to send energy to. I'm aware this would cause "flickering" behaviour where the machine would then need to be given energy again next tick, however since other energy networks, even those without internal storage aren't suffering from this issue, I'm assuming that that is not the problem here.

Versions:

• This mod: 1.5.0-38
• Minecraft: 1.16.5
• Forge: 36.0.22

Thanks for reporting!

Something funky is also going on with the error display...

Since there is no energy storage attached to the network

Are you sure about this, even no energy batteries?
Because if you don't have any energy storage for your network, then the energy transfer will in fact never work.

Yep, nothing at all. The only "storage" in the network are the internal buffers of the Dynamo and the machines, respectively.

Maybe I should explicitly mention I'm using interfaces on the machines and an importer on the dynamo, but I don't remember this being a problem in 1.12

I'm using interfaces on the machines and an importer on the dynamo

Ah, this is very important information to have.

This problem is in my opinion not a fault of Integrated Tunnels. You're using the dynamo incorrectly. Dynamo's don't actually have an internal buffer, what you see in their GUI is really just a throttle and you should put a redstone flux cell between the dynamo and your energy consumer. Attach your energy intefaces/importers to the cell, and not the dynamo directly. Just saying!

However, if you want the energy production to stop when the targets are full, you can still make that work with energy storage. Read out the energy level, and activate the production dynamically when appropriate (e.g. start when below 1000RF, stop when above max minus 1000RF).

@Jack-McKalling the thing is, after a bit of experimentation, it also doesn't work with thermal cells, despite the cell itself being configured properly...

The cable does fill up as you can see, but the machines don't seem to want to take energy from the system.

Obviously, I'm still "technically" not using Integrated Tunnels as intended here since interfaces are meant for buffers so the technically correct implementation would be this (which, interestingly enough does work by the way):

However, this is still at the very least a regression from 1.12 behaviour where Tunnels networks were perfectly capable of working with just importers / interfaces (or exporters and interfaces)

From the last image, try and remove the Energy Importer and cable that are attached to the Dynamo, and then rotate the dynamo into the cell directly. And configure the cell to input on the side of the dynamo. See if that will work.

That last one works flawlessly as I said, the problem I'm referring to is transferring energy from the cell into machines, which doesn't work with just an importer and interfaces (image 2) like it did in 1.12

I can't reproduce this myself unfortunately based on your provided description.
This is the setup I'm using:

I can however reproduce your first energy cell failure. This seems to be fixable by enabling input and output mode on the cell for the required side.

There's not much more I can do about this issue on my end though. TE doesn't seem to be open-source (anymore?), and I'm unable to deobfuscate the mod and load it into my dev environment. So it's basically impossible for me to debug this atm.

I would suggest reporting this to TE, and linking back to this issue here.

TE doesn't seem to be open-source (anymore?)

It's still visible source at https://github.com/KingLemming/1.16, though that said I will probably be relaying this to Lemming as the issue DOES seem to be on Thermal's part? Either way, thanks for the help!

Also, as for reproducing my original issue, I gotta admit I described it a bit poorly, sorry about that:
Basically, my dynamo would fill up while no machines were processing / drawing energy, and as soon as a consumer started to ask for energy again, then the connection seemed to fail. I'll try to get this to fail in a Creative world again when I get the chance to ^^

GitHub

KingLemming/1.16

Contribute to KingLemming/1.16 development by creating an account on GitHub.

I replied in the issue on my own GitHub (which tbh...I use Discord for issues these days but meh, it's fine for now.)

The TL,DR of it is that RF/FE was never designed for pull-based energy transfer. Dynamos don't support it and Cells frankly aren't supposed to; bit of an oversight on my end that you can extract from I/O mode at all.

@KingLemming Thanks for the reply!

So ID does in fact support push- and pull-based energy transfer.
The IT importers will actively try to extract energy, and try to move them to other places in the network, which will not work with TE as expected.
However, IT importers also support other machines to push energy into them (via receiveEnergy), which they will then forward to other places in the network, such as TE furnaces.
This second mode should in fact work with TE, unless I'm misunderstanding something?

Yeah, the second mode should be just fine, as long as you're using caps correctly, which I would believe you are.

Ok, thanks for the input! Closing this issue then as everything seems to be working as intended.