Hi guys,

First up, to let you know in Galacticraft (1.11.2 and 1.12.2 versions) we now fully support the Buildcraft API and MJ energy, with energy flow from mod to mod in both directions, and also our "Sealed" versions of various Buildcraft pipes. We have had a long tradition of supporting Buildcraft MJ, and it seems important that that should continue :)

We do not allow direct energy transfer from our Aluminium Wires to Buildcraft Kinesis pipes for two reasons: first, that connection looks ugly visually, second, a line of Aluminium Wire blocks parallel to a line of Buildcraft Kinesis pipes would produce a lot of unwanted mod-to-mod energy connections, with a risk of loops, lag etc. So if any players in future report an issue like "Kinesis Pipe does not connect to Galacticraft wire" that is intended behaviour.

We do allow direct energy transfer from our Aluminium Wires to Buildcraft machines - and direct energy transfer from Kinesis Pipes to our machines and Energy Storage Module. This also means that players can use Galacticraft wires to interface between Buildcraft energy and the other energies we support (RF, IC2 and Mekanism as well as our own Galacticraft joules which are derived from the original Universal Electricity mods.)

In implementing all this in our code, I've encountered one issue which I wanted to let you guys know about:

When our machines return the value I think they should return on a call to IMjReceiver.getPowerRequested() - that's to say, the maximum amount of energy which our machine can accept next tick - then Buildcraft pipes fill our machines with energy rather slowly. Seems to be only 1 tick in 50 (or something like that) when energy is actually attempted to be transferred from the Buildcraft Kinesis pipe to our machine. As a workaround we now return a falsely high amount of PowerRequested

Also I noticed that a lot of your pipes and machines do not have the correct breaking particles, you can fix this easily by adding a line like this:

    "particle": "buildcraftcore:blocks/engine/wood/back",

in the "textures": section of each block's model .json file.

Thanks for looking into this, although please be aware that we will be breaking the MJ API in the future (which means either small or large changes will be necessary for compat).

MJ is based around pulses, which means that engines only emit power approximately once per second. This mechanic isn't finalised yet (most machines use up power at an constant rate instead, something like this:

Just a minor thing, are the 1 million float values meant to be equal to MjAPI.MJ? If so then you probably wan to refer to the field directly, as that value probably won't always be 1 million in the future (at least not during alpha, it will ofc not be changed after beta)
https://github.com/micdoodle8/Galacticraft/blob/a65df34646026fdf84a043e264fc10a74aa59463/src/main/java/micdoodle8/mods/galacticraft/core/energy/tile/TileBaseUniversalElectrical.java#L505-L507.

I'm not sure adding "particle": "..." to pipe block models will help (as their model is more complicated than that, and mostly defined in code), however I know it defiantly won't help for engines as we use a custom model format for the animations (as shown in the parent file for the redstone engine, here: https://github.com/BuildCraft/BuildCraft/blob/8.0.x/buildcraft_resources/assets/buildcraftlib/models/block/engine_base.json. However it should help for any of the other models. As far as I know all of the other blocks have the correct particle texture.

Thanks, this is very helpful.

If you remember, I would really appreciate if you guys can @ notify me for any major changes to the MJAPI in future, so that we can pick them up as quickly as possible. (Obviously its easiest for us if the changes are not breaking changes...)

If you are looking at significant API changes, one which would actually help me is to change the method name IMjReceiver.canReceive() to some other name, because there's a method name+signature clash with the similar Forge energy capability class net.minecraftforge.energy.IEnergyStorage which makes it a pain for me to implement both capabilities in the same class as I want to. But please don't change this "for me" if you are not making large scale changes to the API. My preference is for no breaking changes at all.... :)

Changing the method name seems reasonable. I guess canReceivePower? Obviously it's annoying for everyone already using the method (addons) though, so it probably won't be changed yet.

canReceivePower or canReceiveEnergy or canReceiveMJ are all good names.

(canReceiveEnergy is the same name as a Mekanism method in the interface mekanism.api.energy.IStrictEnergyAcceptor but the method signature would be different so that's OK - Mekanism's method has an EnumFacing parameter.)

Thank you :)

If you need us to implement different mechanics please give me guidance in future. Right now, we have limited our Aluminium Wire to supply a maximum of 16 MJ / t (standard wire) or 64 MJ / t (heavy wire). I think this corresponds with the intended behavior of Sandstone Kinesis Pipe and Gold Kinesis Pipe.

If things do change, I guess the main thing for us is to have an easy way to identify which version of Buildcraft we are dealing with, because obviously some players could have a current release of Galacticraft with a future release of Buildcraft (or the other way around). Normally I would do this by looking to see if a specific named class is present or absent, as that is more future-proof than looking at version numbers.

BTW we also make use (by reflection) of TilePipeHolder.onPlacedBy() - that's how we produce functional "sealed" versions of Buildcraft pipes.

i'll try to let you know if things change, do keep in mind there are mechanics planned for MJ so some changes to this integration might be needed later to make sure this kind of integration is not abused by people to just bypass these mechanics

we might want to see about opening that up for usage, and the mod version should be future proof enough, maybe a easy workaround would be IMC? if you add an IMC listerer for a specific message could later send that message to kill said integration (up until a new GC version is present or we move to a new MC version)

as for the values for now as kinesis pipes themselfs are buggy and not implemented things are fine as is i think, i made a note to poke you whenever we move towards the new MJ mechanics

We don't like IMC, sorry - have not had much success with it in the past :(

We are totally happy to use Java reflection, it's been working fine this way since both mods' Minecraft 1.6.4 versions at least. Now that it's working in 1.11.2 and 1.12.2 I'd honestly prefer it if you don't change anything, except what you need to change for Buildcraft's own future plans of course :)

I have found the integration with Buildcraft fine, as your mod is open source and your code structure is very logical. IC2 on the other hand ...