Recipe result detection through importers is lacking

[uhloin]

Issue type:

• 🐛 Bug

---

Short description:

Happy New Year! Here is my present! ;-)
It is possible to start some specific crafting job, but cannot finish it.

Steps to reproduce the problem:

1. Unpack minimal set of mods from mods.zip to .minecraft/mods
2. Unpack save from idbug.zip to .minecraft/saves/idbug
3. Run minecraft, load a world idbug
4. Go to crafting terminal
5. Start a crafting job with 10*4 Bronze Drills
6. Issue: After some time Crafting Job Terminal shows pictures like attached. The Job still works some time more. Сontent of the chest is changing, some intermediate ingredients from the job appears in it or disappears.
7. Issue2: The job finally deadlocked with status "Missing 1920" Bronze Ingots. And no, the job is not really need such ridiculous amount of them.

Possible causes and thoughts

1. Machines may generate some excessive stuff, for example 4 items instead of 2 necessary for a next step and rest 2 may be not ready to be used immediately.

2. Machines puts intermediate results to chest, but ID do not get then instantly and (may be) crafters compete for chest's content. It's potential possibility for other crafting jobs or exporters to steal those ingredients.

Looks like there should be some priority logic. Like this. If first crafting job is awaiting some ingredients then the same ingredients must be never exported or used by job with lower priority. All manually started jobs in the same network should be ranged with priority. All exporters with Craft checkbox should be next, with medium priority. All other exporters should be last with lowest priority. Job Terminal and may be exporters should explain situation with some status like "Crafting job #12 is waiting for this ingredient" or else players will confused and think the job is stuck with no reason.

idbug.zip
mods.zip

---

Versions:

• This mod: 1.4.0-433
• Minecraft: 1.21.1
• Mod loader version: NeoForge 21.1.217

Log file:

[rubensworks]

Thanks for reporting!

[uhloin]

Related bug with older versions ID and MI:
#125

[Jack-McKalling]

Could you please see if this also happens in the version of this mod just prior to your version? Your version involved a huge update yesterday specifically related to this issue, and it would be convenient to know if it introduced a regression or if this was already happening before (the same as it does now).

[uhloin]

OK, this was for version 1.4.0-133
Checking 1.4.0... yes, bug is there: on some step huge number of required Bronze ingots appears: "Missing 1848". In fact, it need only 153 ingots and from start have enough dust in the chest to produce it.
Checking 1.3.4... Job stuck in "Calculating crafting plan"
Also old issue was described in #125 for version 1.1.13-269

[rubensworks]

Without having looked into this in detail; are you directing machine outputs into the crafting interface (instead of an importer)? Crafting interface is the proper way, otherwise items may be missed.

If it's not this, this may be related to some underestimations in job planning.

[uhloin]

It's with importers. Chest has item interface, items are moving to machines, importers are getting results and putting them to the same chest for next round.

[uhloin]

May be importers (or any other blocks retrieving items to network) should first try to put items to hungry crafting interfaces in the same network instead of putting to any containers? I mean, think about crafting interfaces as about higher priority item/fluid interfaces. External containers are vulnerable to player intervention and if other transporting mod connects to the same container it would be hell of competition.

[rubensworks]

Can you let the machines output directly into the crafting interface?
Otherwise, the result may not be detected before it's exported or used elsewhere.
Emitting results into crafting interfaces is guaranteed to be resistant against such things.

(I'm even considering disallowing the use of importers for result detecting, to avoid these kinds of confusion)

For reference, the reason why importers are not good here, is because adding result detecting logic for them requires a lot of performance-impacting logic. In fact, we had this logic before this latest release, but I removed it due to performance issues. Requiring result detection through crafting interfaces is a good trade-off between performance and usability.

[Jack-McKalling]

The only idea I'm getting is a crafting importer part. A complementing part to the crafting interface, that specifically pulls the result of a job rather than anything else. But my insight about whether that solves anything is neither here nor there.

[uhloin]

I do not know, how to explain to crafting interface to which side put and from which side get results?
And what to do with multi-block machines with separate blocks to in and out?
And what to do with complex crafting mechanisms with many machines, hoppers etc and separate chests for in and out?

About performance. Imagine relative rare scanned item interface connected to huge storage with thousands of different items and frequently scanned importer with only 1 or 2 items from machine output. It's approximately the same. And importer may be connected to huge storage as well.

May be it would be good idea to set dynamic check period? If specific importer/interface spent N ms for check, then set next check not sooner than after 10*N ms. It may slow down crafting but gameplay without lags is more important.

In any case there is bug not related to performance. The bug cause wrong calculation of receipt items, because on start job needed 153 ingots and on deadlock it wants 1900.

[rubensworks]

I do not know, how to explain to crafting interface to which side put and from which side get results?
And what to do with multi-block machines with separate blocks to in and out?
And what to do with complex crafting mechanisms with many machines, hoppers etc and separate chests for in and out?

Many modded machines allow you to configure automatically pushing results to a certain side as output, so these would solve your problem.
But all machines support this (e.g. the vanilla furnace), so this would be a problem indeed...
So I'll have to think about a solution for this.