Crafting interfaces act as fluid and item importers but don't register crafting results. #252
Description
Issue type:
- 🐛 Bug
Short description:
I have a crafting setup where all results of crafts of all machines go through a logistical network node first to end up in a general chest, from there multiple item importers import everything into the network.
Same setup for fluids, works great.
However, not all crafting results were registered, specifically when doing large batches where machines produce multiple stacks per tick it broke down.
At one point unrelated to this I discovered that crafting interfaces actually behave as general item and fluid importers and decided to see if I could use that instead, but then I also discovered that importing items and fluids this way don't register them as crafting results.
So, what was happening on big batches the logistics network could not handle the volume and the machines started exporting items directly into the crafting interface.
Now, this is actually a very handy feature/bug. Most machines do support just pushing out to a specific side, so if the crafting interfaces can act as importers, that would make hooking up machines a lot simpler (no need for separate fluid/item importers, just a crafting interface and an energy exporter).
Steps to reproduce the problem:
Put a hopper pointing at any crafting interface and the crafting interface will import the items.
Expected behaviour:
Well, I guess according to the documentation crafting interfaces shouldn't do this.... But maybe they should? ;-)
Versions:
integratedcrafting-1.21.1-neoforge-1.8.0
integrateddynamics-1.21.1-neoforge-1.38.1
integratedterminals-1.21.1-neoforge-1.11.1
integratedtunnels-1.21.1-neoforge-1.13.0
Minecraft: 1.21.1
Mod loader version: NeoForge 21.1.150
ATM10 TTS 2.2.0
Activity
rubensworks commentedon Oct 24, 2026
Thanks for reporting!
Vampyric-OC commentedon Oct 24, 2026
Followup, intermod related.
This is definitely a problem with machines/processors which always push to neighboring inventories.
Example would be an Ars Nouveau jar containing aN occultism processing spirit.
That will always also push to the crafting interface so their crafts do not get registered.
ps.
The mechanical squeezer has an option to push fluids to neighboring fluid tanks.
Enabling that option also causes it to push its fluid crafting results back into the interface so they won't get registered.
rubensworks commentedon Oct 24, 2026
I'm unable to reproduce this myself.
Could you share a minimally reproducible example? (ideally without other mods installed)
Vampyric-OC commentedon Oct 24, 2026
This is the setup that demonstrates crafting interfaces importing items. No mods except latest ID.
Anything put in the hopper ends up in the chest.
(and as said, this in itself is a nice feature, but only if they would also register the items as crafting results then)
Add game test for a hopper pushing results into a crafting interface
rubensworks commentedon Oct 24, 2026
I will need more details, as i still can not reproduce any problem with such a setup.
Vampyric-OC commentedon Oct 24, 2026
I build the test you added with the furnace in vanilla too, and yes, there it does work.
I will try and find out why it doesn't in the modpack then.
rubensworks commentedon Oct 25, 2026
Not sure what to do here. Based on the info you provided, everything seems to be working as intended on my end.
The crafting interfaces correctly accept any ingredients, and correctly register them as crafting results.
If you have a case where a crafting job fails due to crafting result detection, please give me detailed steps on how to reproduce this problem.
Vampyric-OC commentedon Oct 25, 2026
Yeah, not entirely sure either now. In my modpack factory it fails.
Don't worry about it, I'll figure it out and find a fix or patch and I'll report back ;-).
Vampyric-OC commentedon Oct 26, 2026
Hi again, I got a small update, but apparently I am hitting 2 bugs.
Please bear with me please while I try to explain.
First this apparatus:
In this, the upper ID network is a crafting network, it has a recipe to turn dirt into cobblestone.
Dirt gets deposited in the center chest where the bottom network picks it up and distributes an equal amount of cobblestone in the top chest.
It then recycles the dirt and cobblestone from the left chest.
The redstone part is an alarm and the crafting writer in the top network is set to produce 128 cobblestone.
So in principle this thing should craft forever. In practice it does not.
It takes a very long time to break though and I have not yet established when exactly it does (the alarm is recent).
When it does however the crafting job is just permanently broken.
Canceling and restarting it breaks it immediately again and the only way to get it going again is destroying the crafting interface and replacing it.
I have not tried this in vanilla as I need to keep the game running for hours to trigger it.
Second this one:
This is a test setup to craft something with a lot of intermediate steps (mekanisms ultimate induction provider takes around 8000 crafting steps).
This fails when using non-blocking mode. In blocking mode it works fine, in non-blocking mode it fails to register the crafting results and after this happens the whole system is broken until the crafting interfaces get replaced.
And this might be related (I also checked the code a bit), but when this happens and I restart the game the broken crafting interfaces are deleted from the world.
This might maybe be related to oversized nbt tile data, which might come from the craftingjob serializer serializing the entire crafting queue?
But I have no idea yet why in game itself the crafting immediately fails in non-blocking mode with big crafts like this though.
As for the bug of this report, I guess that is invalid.
I was hitting both bugs at the same time so that left me kinda confused and I suspected the wrong thing, sorry.
I will try and set up both bugs in a more vanilla setting when I got more of an opportunity to keep it running a few hours and file them under separate reports if I have more information or a smaller (and foremost faster ;-)) test setup to reproduce these.