Description

Energy Acceptor is not accepting energy from RFTools power cells, nor Actually Additions energy laser relays. Another player tells me the same goes for the controller but I've not personally tested that.

It does accept from IE's capacitors directly and via LV/MV connectors

Environment

Large modpack; can provide a full list if you need.
SMP with about half dozen players. Nothing of note in client or server logs.

• Minecraft Version: 1.10.2
• AE2 Version: appliedenergistics2-rv4-alpha-11
• Forge Version: 2185
• compatlayer-1.10-0.1.7
• rftools-1.1x-5.76
• actuallyadditions-1.10.2-r97

As you already confirmed, it works perfectly fine with IE (and other mods like EIO). So the support for energy itself works.

Thus it is most likely a bug in how rftools detects a tile accepting energy and does not consider them as valid ones.

As I am not able to get it to run inside a dev environment, there is no way to actually debug. Maybe the mod devs can actually provide more information.

OK thanks. I'll report to ellpeck and mcjty.

Both (and Tesla/IC2). But neither works.

Can you point me to the code of where you are implementing this?

https://github.com/AppliedEnergistics/Applied-Energistics-2/tree/master/src/main/java/appeng/tile/powersink. For RF no change since 1.7.10 and it always worked fine.

And as pretty much anything else works fine, it should really be an issue with detecting valid tiles not the transfer itself.

Well I could say the same of the powercell. It has no problems sending power to other machines either

BTW. Here is how the RFTools powercell detects if a tile entity can accept power:

public static boolean isEnergyTE(TileEntity te) {
    return te instanceof IEnergyHandler || te != null && te.hasCapability(CapabilityEnergy.ENERGY, (EnumFacing)null);
}

Can it be that you don't implement hasCapability() with 'null' facing properly? 'null' is a valid value as can be seen from this comment here:

/**
 * Determines if this object has support for the capability in question on the specific side.
 * The return value of this MIGHT change during runtime if this object gains or looses support
 * for a capability.
 *
 * Example:
 *   A Pipe getting a cover placed on one side causing it loose the Inventory attachment function for that side.
 *
 * This is a light weight version of getCapability, intended for metadata uses.
 *
 * @param capability The capability to check
 * @param facing The Side to check from:
 *   CAN BE NULL. Null is defined to represent 'internal' or 'self'
 * @return True if this object supports the capability.
 */
boolean hasCapability(@Nonnull Capability<?> capability, @Nullable EnumFacing facing);

This is most likely the problem. Neither do we implement IEnergyHandler as it does not fit nor do we consider null/self/center as a valid side for the capability.

Well not implementing 'null' as a valid facing is problematic for several blocks in my mod. More specifically it is a problem for blocks that monitor RF storage in another block from a distance. In that situation there is no 'side'. It just wants to monitor the internal state.

BTW. IEnergyReceiver extends IEnergyHandler so you should support IEnergyHandler that way.
Unless of course you are using the outdated 1.7.10 COFH API. There is a new 1.8.9 COFH API made by KingLemmings that has changed this

Here is the link to the 1.8 and beyond RF API. The inheritance structure has changed. You should not use the 1.7.10 version as that one is no longer valid in 1.8 and beyond:

https://github.com/CoFH/RedstoneFlux-API/tree/1.8

RFTools Powercells distribute energy to any block that supports either the COFH RF API or the Forge energy API. It works fine for everything that I know so I'm uncertain why it would not work for this. How does the AE tile work? Does it implement the COFH API and/or the Forge Energy API?

BTW, rftools works fine in a debug env. Just put the right version of compatlayer, McJtyLib and RFTools in your run/mods and it works

Uh, Actually Additions does work in a dev environoment. Just download a version from Curse, you don't need deobfuscated mod versions anymore since late 1.8.

Ah my error. I did not do anything about the RF part for 1.10, when porting it. Thus not aware of the hierarchy change. Personally I would just scrap the support completely.
So that should actually not prevent it from working. Except some later checks for IEnergyConnection or IEnergyReceiver fail somehow.

But the Forge Energy part clearly will not work. While null can be a valid facing, it does not have to expose it. In other words it is implemented properly according to the contract. The only improperly implemtation would be crashing.

It is just improperly for your approach of detecting a valid energy tile. For AE2 it makes absolutely no sense to expose the self/internal side for transfer.
We could expose a monitor only version on null, but that would be pretty much useless for most cases due to how AE2 actually stores the power. As well as the additional memory cost for duplicating the handler object for every tile.

Both RF and FE support are desirable as not everyone (Actually Additions notably) have adopted Forge Energy.

So, is this my problem after all, or not? I don't check for any null sides, I just check for if a machine instanceof IEnergyReceiver.
This very much seems like an AE2 problem for me, as no other mod ever had a problem with Actually Additions machines transferring to their machines :(

I have no idea. All I can say is, that RF works perfectly fine with IE. Thus it is clearly not a does not work at all, but an issue between AE2 and rftools/Actually Additions. But neither work inside a dev environment to actually debug it.

RFTools works fine in a dev env. Just needs compatlayer+mcjtylib too (put all in run/mods). I do that all the time with my other mods