Integrated Crafting

Integrated Crafting

37M Downloads

Multiple crafting jobs with shared ingredients can deadlock each other

rhullah opened this issue ยท 10 comments

commented

Issue type:

  • ๐Ÿ› Bug

Short description:

If multiple crafting jobs are started that share ingredients, they can deadlock each other when one crafting job "takes" ingredients from the other.

Steps to reproduce the problem:

To test this, I crafted 32 jobs each of Oak Fences (96 total fences) and Oak Doors (96 total doors) at the same time.

  1. Prep the recipes for both the fences and the doors with only Oak Logs in the network. So a recipe for each: Planks, Sticks, Fence, and Door.
  2. Start a crafting job for 32 fences (which will produce 96 total fences)
  3. Then quickly start a crafting job for 32 doors (which will produce 96 doors)

What happens is the fences will start to craft planks in preparation to craft the sticks and then fences. In the mean time, the doors are waiting for it's inputs which is planks but think the ones being crafted for fences are for the doors. Once enough planks are crafted for the door, the doors will start crafting. In the end you'll get a deadlock because they both think the planks were for themselves but ended up being shared so it won't craft anymore planks even though it could.

Expected behavior:

An ongoing crafting job should be able to craft any prerequisite dependencies at any time. That way if another crafting job consumes it's dependencies it can craft more so that it can complete it's job.


Versions:

  • This mod:
  • Minecraft: 1.21.1
  • Mod loader version: NeoForge 21.1.73

Log file:

N/A

commented

Perhaps a new option in the Item Interface for "Crafting Cache" or something similar that dedicates the connected interface to crafting storage. This provides some balancing limitations, as you would need large enough cache to do large crafting jobs (in the same vein as crafting CPUs in AE2). It also keeps the general feel/approach of IT by still relying entirely on external storage.

Though, considering that fluids and energy are applicable ingredients, as well, I suppose we would need cache options for each interface, and multiple fluids makes me miss the TC Tinker's Tank.

commented

Thanks for reporting!

commented

Note to self: one way of handling this is to extract all requirements (also for dependencies) as soon as the root job starts execution, and keep it around in a dedicated reserved storage space.
In this way, each job will have its own storage space.

This will require job cancelations to flush this dedicated storage space into the storage (or to dependent jobs) again.
And if there's not enough storage space to flush, then jobs may not be canceled!

This would also fix issues where external interactions with storage chests would cause issues with running crafting jobs.

Note to self 2: this will require a precise calculation of what needs to be fetched from storage, because the "In storage" value has slightly different semantics. (see the test case added for #125 where "in storage" is 10, while the actual value to be extracted from storage is 8, due to surplus items from other crafting jobs)

Note to self 3: To avoid jobs in the same graph using inputs from each other, we will probably need to have crafting storages per crafting job separately, which can be flushed to storage or dependent jobs on completion (or partially when partially done in bulk mode). Required for things like #125.

Note to self 4: Make sure I have an easy way of debugging, so I can easily inspect crafting storages.

Note to self 5: Scope per sub crafting job, to avoid sub jobs stealing from each other.

commented

Other mods specifically implemented storage components to keep all items that have been or are being processed, separate from the general storage. AE2 for example has crafting processors that include crafting storage blocks of varying data sizes. I don't know however, how they handle full storage when cancelling. I also think it's smart to keep this data separate.

commented

The main challenge here will be to determine where this dedicated storage space should exist, since ID/IT/ICr are purely based on external storage. And I would prefer to not introduce a new block/part for this functionality.

Maybe it could exist as hidden storage in the crafting interface of the root crafting job... (we already have a temporary storage inventory there for other things)

commented

Maybe it is possible to mark a storage as a dedicated storage for crafting, so that the network would know to use the given chest for that purpose? Could be a new type of interface or something similar.

That way it would still be conceptually done a modular way, so that there is an interesting choice involved. And then, if a crafting job is cancelled for any reason it could simply leave the items in the crafting chest(s) for further reviews by the user :)

commented

I think in the crafting interface is is likely the best "place" for it. Maybe a new screen in the crafting interface part where you add stacks of chests to expand crafting storage or something similar? I don't think items of the crafting storage should be accessible to the user as I feel like that just gives more opportunity for messing something up. But, being able to view what's in the crafting storage and for which job would be interesting.

commented

Is there a way to port these changes to older versions of MC so this fix would work in packs like atm9?

commented

All The Mods 9 is on Forge 1.20.1, we do still support that version.

commented

May be it is off-topic, but I want just warn about this feature may be really critical for competition between ID, AE2 and RS2.

Currently among 3 only AE2 can handle complex recipes, but has issues with energy cost and channels hell, so still is not absolute winner.

RS2 has issues with crafting, but development is in progress and may become leader,

ID is indisputable the best for tiny subnets, but will fall behind as main storage system for big bases.

I'm really sorry for bad predictions, do not kill me.