I have a setup with LP and Storage Drawers and I have a Provider and an Item Sink upgrade (default: true) on the controller. When I route an item to the controller, it does not put the item into a drawer where already a same item (actually a bunch of it) but automatically finds a new empty drawer for it.

I am not sure it is a problem on Logistic Pipes or on Drawers side, so I think I mention @davboecki and @thezorro266 here, but I guess it's about controller routing logic problem since the LP can route items correctly to the controller, but controller places it wrong.

I can reproduce it with compacting drawers and normal drawers, and also a drawer that can accessible only over a slave or directly (without slave, diagonally connected with the controller via another drawer).

Placing items from player's inventory (by right clicking on the controller) routes the item to the correct drawer.

Storage Drawer: 1.5.9
LP: 0.9.1.133

I ran into this bug just now. It looks like LogisticsPipes has some integration that ignores your sorted list of slots, going straight for the drawers provided by IDrawerGroup. A pity, because its default slot-based transactor is smart enough to try full slots before empty ones.

There doesn't seem to be a way to disable LP's integration.

I manually disabled LP's integration by removing the relevant lines from its SpecialInventoryHandlerManager, and now items delivered into drawer controllers are sorted as expected. However, the Provider Pipes are no longer able to provide the controller's inventory to the network!

Whoops, never mind. I used LP 0.10 by mistake, and SD integration seems to be half-broken in that version - I can send items to a drawer controller via default route, but they don't show up in the requester GUI.

I'm relatively sure that this wasn't included or affected by any of the changes I've made.

What would be required to implement this on LP's side?

@1n5aN1aC made several enhancements to the LP support recently. I'm not sure where those fall into the LP versions. I think this issue must still be outstanding though, because I didn't extend the API.

For the record, the issue is still present with LP 0.9.3.68 and SD 1.6.2.

I think we're waiting for the StorageDrawers API to provide a priority list of drawer slots on the IDrawerGroup. If you want to whip up a quick-fix, it looks like all that's needed is to copy the priority logic from TransactorSimple and put it into StorageDrawersInventoryHandler.

I meant to do this over the weekend, but I got distracted with new content for Garden Stuff.

I added a new interface, IPriorityGroup, which exposes a single method to get the slot order. Controllers and slaves implement this interface in addition to IDrawerGroup, so check if your IDrawerGroup implements it. I updated the AE2 integration to take advantage of it (c0790b4).

It should be straightforward to update the LogisticsPipe integration. If you do use the interface, make sure the version check is updated for Storage Drawers 1.7.4, or people's games will crash.

1.7.4 is available now.

That's okay. Thanks for the rest of the work you've done to improve interaction between the two mods.

Just thought I'd say that I don't have the time to work on this or similar projects for a while, in case anyone was wondering....

The manual placement only got smarter in the last couple versions. It too used to pick the first available drawer based on discovery order, even if empty. I bet the other integration on my end like AE2 and Refined Relocation are similarly dumb.

The API is not designed in a way that I can just make this work behind the scenes, though that would have been nice. I think I'm going to need to extend the API to offer a list of slots sorted on priority, and then LP and all that other integration will need to be updated.

Ohh, I guessed accepting items is handled in one big inventory and items became routed later like how FZ routers work.

Anyway, thanks for your information, I hope it will be fixed soon.

Issue is still present in logisticspipes-0.9.3.114 StorageDrawers-1.7.10-1.9.7.

Seems to have been fixed after your PR, and then broken again by commit f098b67f4e86c96a827da37d8626470c530e9603 which uses a BitSet to throw away the ISmartGroup's insertion order.