AE2 Integration is not working properly
mcsaboteur opened this issue ยท 4 comments
Minecraft Version
1.12.2
Forge Version
14.23.4.2760
Mod Version
1.12.2-0.8.3-299
Describe your problem, including steps to reproduce it
AE2 integration with a requester frame is not working properly. Items will appear in the AE2 inventory and then disappear when your close and reopen the inventory. When attempting to request/craft items stored in the logictics system, the request will sometimes work properly, sometimes tell you there are no craftable items when there are items available and sometimes the request works, but gets sent 5 times, i.e. requesting 10 blocks, you are sent 5 stacks of 10.
I tested this with a small creative test system a couple times and received the same result. The problem seems to be consistent.
Any other comments?
I understand this one may be outside your control, but thanks for taking a look.
Confirmed. I tried this:
- Requester frame on an interface
- Provider and/or storage frames on other inventories nearby
- Enabled AE2 integration on the requester
- Open an ME Terminal - I can see "craftable" items from my provider/storage chests OK
- Request e.g. 1 white wool & close terminal
- My Logistic Drone went and fetched 1 white wool as expected
- Opening terminal again, and "craftable" items were no longer visible
- In addition, once the Logistic Drone had deposited the wool in the interface, it immediately went back and got more wool, and repeated this (1 wool at a time) until all the wool was gone from my providing chest
However, the behaviour isn't consistent. I tried something similar with a nearby chest full of snowballs, and the drone behaved perfectly well.
Unfortunately, I don't understand the integration code or the AE2 API well enough to figure out what's going on here. @yueh - a request for assistance, please? :)
If I request something from AE2, then ICrafterWatchingHost#onRequestChange()
adds the items to the requester's wanted list as expected, the logistics drone goes and fetches the item, but by the time IStackWatcherHost#onStackChange()
gets called, the drone has already fetched 2 or 3 of the item.
Update: with some IDE watchpoints, I determined that IStackWatcherHost#onStackChange()
does get called when the requested items get deposited, but grid.isRequesting()
continues to return true for longer than it should:
onRequestChange: add request for 1xitem.snowball@0 @ 1123430 - slot 0
onRequestChange: add request for 1xitem.snowball@0 @ 1123430 - slot 0
onRequestChange: add request for 1xitem.snowball@0 @ 1123501 - slot 0
onRequestChange: add request for 1xitem.snowball@0 @ 1123501 - slot 0
onStackChange: 1123501
onStackChange: 1123501
onStackChange: 1123501
onStackChange: 1123582
onStackChange: 1123582
onStackChange: 1123582
onStackChange: 1123663
onStackChange: 1123663
clear requested item 10xitem.snowball@0
onStackChange: 1123663
onStackChange: 1123663
The numbers there are World#getTotalWorldTime()
, so in ticks. I requested 10 snowballs at 1123430. onRequestChange
gets called twice at 1123430, and twice again at 1123501, which I believe is when the drone dropped off the first 10 snowballs. Not sure why it's getting called multiple times, but the "slot 0" indicates that it's always putting the request in the same requester frame slot, i.e. not adding it multiple times.
Then the drone drops off another 2 lots of 10 snowballs, even though only 10 were requested. And only on the third consignment does onStackChange
clear the request in the logistics frame. So onStackChange
gets called reliably it seems, but the grid.isRequesting()
call appears to be returning true when it shouldn't.
ICrafterWatchingHost#onRequestChange()
is not called until the item is actually reaching the crafting cpu. Usually the interface should push it out the next tick, but no guarantees about it. Like insufficient power could delay it further.
Duplicate events are probably caused by erring on the side of caution and better send them twice instead of never. Or the effort to guarantee it's send exactly one is not worth it (e.g. we need to detect looping updates etc).
Neither method is probably ideal to depend on for perfect requests. The best approach would probably be to add something like ICrafterWatchingHost#requesting(ItemStack)
and call it with the exact amount needed, and only send it again once it actually needs more items. E.g. crafting planks from logs might send a request for 1 log everytime it crafts 4 planks. But that might have to wait until 1.13.