[Issue] Weird behavior with Thermal Dynamics Itemducts

[Meuterion]

Hello there,

I noticed while moving the content of my previous base by ender chest (ender pouch > ender chest > resonant servo > itemduct), that the servo was sending only one stack toward the controller, and waiting for the item to arrive to send another stack.

It even bypassed the dense itemduct, whatever the length of the dense section was (overflow buffer with golden chests behind some dense itemduct). So while the item stack heading towards the controller isn't , the remaining items in the ender chest pass the dense itemduct. Then after the stack is processed by the controller, the servo send another one toward it, then same thing again with the dense itemduct...

After some testing (screenshot of the setup), I did find that this behavior only occur if the full array of drawers are locked. If some of the drawers from the bank are unlocked, the items are arriving just fine (so at max servo speed). Only info / workaround that seemed similar I did found was this, but I didn't had time to test warp itemducts (need to sleep, already 7 am here), although I suppose this will effectively solve the issue.

So to summarize :

• No dense itemduct : one stack by one stack even with resonant servo, waiting for the previous to arrive to send the next.
• Dense itemduct : while the stack is traveling, the servo is working at full speed through dense itemduct, like if it doesn't recognize the controller as a valid storage (then send the item through the dense duct, as the priority list tells it).

Of course, enough storage left in the drawer to store all the items. Oh, and I'm using the FTB infinity Evolved 2.3.3 pack (so StorageDrawer 1.7.5).

PS : Awesome mod, btw :3

[jaquadro]

This is actually the behavior I would expect from Thermal Dynamics. TD has no knowledge of the "depth" of drawer inventories. Drawers can only report that they have up to 64 spaces available. Once the items are transferred and accepted by SD, it can report that the next 64 spaces are available. This is the limitation of working through Minecraft's standard IInventory interface.

Now, you might ask why this works with JABBA, caches, DSUs, and such. CoFH have embedded special support for IDeepStorageUnit inventories into their codebase, so all those blocks that implement it can tell TD what their real capacities are.

I can't implement IDeepStorageUnit in SD because it's only compatible with a single inventory slot. I guess it could technically be applied to the 1x1 drawers but then you'd have an inconsistency.

The only way to make this work would be for CoFH to embed support for my IDrawerGroup/IDrawer API into their mod. I don't know that they would have any inclination to do that.

[Meuterion]

Ah, I see. Was gonna say that locked / unlocked drawers were not behaving the same way (with only unlocked drawer connected to the controller, it seemed to accept the item at normal servo speed), but after some additinal testing and what you said, it seems the controller just says it has space (since multiple drawers are empty), then when the item comes in it, it check the normal "routing" thing into the drawer bank, then put them on the same drawer, instead of spreading through all the "64 spaces avaiable" reporting drawers. And it still gets through dense itemduct on ocasionnal time, so I guess it behave in fact the same way, in the end... Well, thank you for your time (and mod !), guess I have to work that around :3. Oh, for those who might get the same "issue", warp itemduct, or adding a "big" overflow buffer (ie. random chest hooked to the itemduct network) and a retriever on the SD Controller seems to do the trick.