GregTechCEu Modern

GregTechCEu Modern

Mods
6M Downloads

Incorrect behaviour with a custom multiblock part cabability trait and RecipeRunner

Vazde opened this issue ยท 1 comments

commented

Checked for existing issues

  • I have checked for existing issues, and have found none.

Tested latest version

  • I have checked that this occurs on the latest version.

GregTech CEu Version

v7.1.4

Minecraft Version

1.20.1 Forge

Recipe Viewer Installed

EMI

Environment

Singleplayer

Cross-Mod Interaction

Unsure

Other Installed Mods

GT, EMI, KubeJS, ComputerCraft, Jade, Cucumber, ProbeJS

Expected Behavior

I wrote a mod that adds a new multiblock part. It has an inventory of fluid cells, and works as a fluid hatch. Expected to be able to have the large chemical reactor output to it.

Actual Behavior

Recipe handler for the output is never called

Steps to Reproduce

  • Create a new MultiblockPartMachine.
  • Instantiate a custom NotifiableItemStackHandler and NotifiableFluidTank in the constructor. Provide IO.OUT as parameter.
  • Have the tank use a list of custom fluid tanks for storage
  • Try to run the LCR. Notice how nothing happens. When breakpointing RecipeRunner.handleContents observe how during the output recipe: capabilityProxies lists the tank as BOTH, instead of OUT, and exists early.

So not only is that code ignoring BOTH (and looking only for OUT), my cabability is registered as BOTH, instead of just OUT.

Additional Information

The somewhat ugly code I was testing with: https://bitbucket.org/Vazde/minecraft-cells/src/07284356/mod/src/main/java/fi/dea/mc/deacells/common/machine/CellOutputHatch.java?at=master

commented

It seems that my code was mixing IO directions for the item and fluid handler, and that in turn changed the caps of the whole part to their sum. When having both handlers as IO.OUT the thing worked as expected.

But there is a reason the handlers have different caps. I only want the part to participate in fluid recipes of the multiblock, yet have the items there for persistance and such, without recipe handler caps for them. Optionally have the items interactable with hoppers and such, and/nand fluid pipes.

I also may be misunderstanding the machine traits, and this problem may be solvable in another way (implementing fluid handling as described, but using non-traits for items).