Description

When trying to use the P2P tunnel to transfer power out from the AE system the cable from Mekanism does not connect (when it's linked to another tunnel) it does connect however on the input side. But output it seems to not work.

Screenshots of a setup here along with the issue we log with Mekanism.

Power does not transfer out into the cable as seen in the linked images but when using another mod for pulling the power it works as intended. Not sure who is to blame here but Mekanism seem to think it's an issue with AE.

However there is a log printed out

[AE2:C]: Problem detected when processing IMC add-p2p-attunement-forge-power from mekanism

Which I belive could be the issue but as power is going into the network I would assume the output should be valid also. If you need more information I'm happy to test other configs or give more details.

Environment

• Mekanism: 9.4.6.341

• Valid in SP & MP.

• Minecraft Version:

• AE2 Version: rv5-stable-11

• Forge Version: 14.23.3.2675

This is a mekanism issue as they rely on conditions completely unrelated to basic FE functionality to create a connection. Basically they only accept something operating in pull mode to be a valid connection, while FE can either push or pull, thus neglecting the push approach some mods rely on completely.

That log message occurs whenever we receive an IMC message from a mod that isn't actually correctly named.
In case of the P2P attunement in our codebase it's called fe-power, not forge-power.

It should maybe be called forge-power or clarity sake, but that would be something for rv6?

Nevertheless that's something on Mekanism's side

Thanks, guys for looking at this one. I had a gut feeling from the start it was a Meka issue.

Also keep in mind that this will not only affect AE2 but any mod which uses a push approach. E.g. some generators might only allow to push by default for various reasons. An obvious one would be performance reasons. Which to some degree also apply to AE2 in certain cases. As the transfer over P2P always costs a percentage of the transfered amount as AE energy costs. Which in some rare cases could get a bit expensive once something decides to pull many small packets every tick compare to a single big one being distributed over all outputs.

Further there is no contract about the mutability of any can method. It would be perfectly fine to tie them to the internal storage amount. E.g. something like amount > 50% for it to allow extracting.
Combine this with caps being uncachable by design, mek would have to constantly scan it every tick and then flip the cable between connected and unconnected. If ingress and egress is even, it would potentially trigger a chunk rerender every single tick.