Description

https://i.imgur.com/x77eIcs.png

This is a completely valid recipe, as you can see. I have a 64k crafting storage compared to only 423 Bytes needed, and I have all of the necessary ingredients.

Upon pressing Start however, nothing happens, the window for the crafting plan stays open, and no craft request is placed.

This also occurs when attempting bulk crafts of some items, but not crafting single units.

The redstone and draconium ingots are inside a Black Hole Unit with a storage bus, but I have tried storing a certain amount of each of the Black Hole Unit items in a ME Chest hooked up to the system, but the recipes still did not work.

Environment

Pack is FTB presents Direwolf 20 1.12.2 on a server

• Minecraft Version: 1.12.2
• AE2 Version: rv5-stable-2
• Forge Version: 14.23.0.2531

does your system has enough power buffer? add some energy cells, maybe you are running out of power

(answer in advance, no offence, just experience ... no available power is irrelevant because input power is limited to system-capacity/tick)

you can use the networking tool to check your system capacity and throughput

Increased my power capacity by a factor of 45, and was still unable to craft

There were no compacting drawers attatched to the system, and when used with the ME chest, the only instances of the items were in that chest,

How unfortunate, so you have compacting drawers installed? They report more items available then there are causing autocraft to fail... When you tested with the me chest, die you make sure none of the items was storged anywhere else accidentially?

Does it say something in the console or any of the logs (server, client, etc?)

Nothing in the server or client logs that stand out.

In case anyone bumps into this thread like I did, calculator mod storage chambers cause the same problem.

This is caused by black hole units only allowing to extract 1 stack per tick. So any crafting request with more than 1 stack of a item stored inside them will fail. We have to extract everything at once to avoid stalling the crafting process later due to something else fighting over the required items.

There is pretty much nothing we can do about it. The only option would be splitting it over multiple ticks and that is simply not feasible. Extracting something around 100k items would literally take over an hour before it can even start. Something like crafting a octuple compressed cobblestone is a bit over 3 weeks and about 40 months is the upper limit to extract a filled one completely.

furiously taking notes

i am wondering if this DSU conflict topic will ever lead to an proper forge API in future :)

It's not really the old DSU issue. The MFR clone tries to mimic the old approach with using separate input/output slots for pretty much no reason. MFR did it because there was no IItemHandler to ensure no external user fucks with the internal amount via the old IIventory. Which is no longer true for IItemHandler which could easily wrap around the internal stack without having to use explicit inventories for input and output.

Why? I have no idea. It must makes it way more complicated. BH have to tick to refresh their input/output slots. Maybe even to cleanup the input and move it into the internal one.
It seems like one of newest version might have fixed it. But the implementation is ridiculuous. extract has 4 code paths or so for basically handling min(stored, requested) and all duplicated code to keep the inventory somewhat consistent. In a pretty convoluted way by extracting from the output and then trying to refresh the output from the internal for the next extraction. Plus the ticking refresh, querying the actual slot returns the internal state, while extract works against the explicit output slot and so on. So many code paths, which might have the usual copy&paste bugs.

And in terms of forge, I doubt we will ever see a good inventory approach. If you look at the proposed IItemHandler improvements, pretty much all are just bullshit. They solve nothing, make implementing them even harder and more error prone. Limit their use to a very narrow area, because that is the only area the dev cares about it. Or even have some serious side effects like comparators suddenly having to deal with 4 different code paths to fetch their info from a tile entity. And probably the issue that none of the forge contributors really deal with massive inventories and encounter the issues with it. (Plus even if there is better approach, it will be mostly undocumented, left to interpretation and so on.)