Logistical Transporter stop transfering items before the output storage is really full (With Ender Utilities Handy-Chest)
Fireztonez opened this issue ยท 12 comments
Issue description:
The Logistical Transporter stop transfering items when the contener (Ender Utilites Handy Chest Extended) contain about 5120 of that item (1 stack 1/4 on the chest...). If I remove 1 stack, the logistical transporter will immediately take and send 1 more stack, bot still stop at the same amount...
I have try the same setup with EnderIO Item Conduit and Thermal Dynamics pipes and both works none-stop. So, it look like the problem is from Mekanism (Or compatibility issue, not sure)...
Steps to reproduce:
- Place an Ender Utilites Handy Chest in the world
- Place a memory card in it (In my case I use a 12 B memory card...)
- Place a storage with a big amount of a specific item (In my case a Storage Drawer withg Creative Vending Upgrade)
- Connect the Storage Drawer, to the Handy Chest and extract from the Storage Drawer...
Version (make sure you are on the latest version before reporting):
Forge: 14.12.5.2824
Mekanism: 9.7.1.371
Ender Utilities: 0.7.12
Thank's
Fireztonez
I see, I can probably open an issue and link place a link to this issue question to try having that issue fix... For what I understand, with the response of an issue I have open to EnderUtilites, the mod doesn't use the Forge IInventory method, so, this is possibly a cause of that issue, and the dev doesn't want to change that... After, I'm not really a Java programmer, so this is a little bit outside my field of expertise...
We don't use IInventory any more either at least for logistical transpoters. We use IItemHandler which is probably what they use, as that is the new standard.
Mainly putting this here for our use when we look into it more, but it seems that this has to do with our on route partial simulated insert. As for each slot in the inventory of the handy chest they report 64 items can fit into it, and that each stack has the 64 items in it.
Our method in question:
https://github.com/mekanism/Mekanism/blob/1.12/src/main/java/mekanism/common/content/transporter/TransporterManager.java#L67
I see, yeah for sure 4096 items stack is not really common thing in minecraft, EnderUtilities do weird thing I think sometimes... Do you think this is something you can fix without causing too much issue or caused more lags?
No idea yet I only did some initial poking around. And the issue isn't as much 4096 items per stack as that they claim there are only 64 per stack. But given a vanilla hopper works it is probably something we have to deal with more than something EnderUtilities would have to fix.
Was getSlotLimit()
the method that was added to the IItemHandler
interface somewhat recently? If that is the case, then I probably simply haven't added support for that method yet in my inventories. And if that is the issue, then I can easily fix it on my side by making it call my own equivalent method I use in some of my inventory interfaces.
The problem is now fixed with the dev version of EnderUtilities, for the Handy Chest. So this is not a problem anymore...
For the transporter I knwo you work hard to optimized everithing, so, I don't know if you you whant to keep this issue open for the profiling informations or no.
@Fireztonez please re-check this with the updated code from maruohon
@thiakil There have no new update availiable for Ender Utilities and no body send me a Dev Version to test, so, what do you whant me to test?? I really don't know how to change that code manually into the the mod and build a jar...
Unless you talk about the new version of mekanism, in that case, I just tests and it still doesn't work, exactly the same issue with the version 9.7.2.373 of mekanism...
If it is fixed then I am going to close this for now. And it is known that Logistical Transporters at times still end up using a decent amount of processing though it is a lot less than it used to be and my guess here is it may just have to do with how many slots the handy chest has for it checking to make sure that it really cannot accept any more slots. (I don't fully remember how dizzy's back off logic works or what it checks to see if it should back off)