
[AE2 & GTM] Input Hatches/Busses do not expose contents to storage busses - Breaks AE2 blocking mode on subnets.
Ghostipedia opened this issue ยท 1 comments
Checked for existing issues
- I have checked for existing issues, and have found none.
Tested latest version
- I have checked that this occurs on the latest version.
GregTech CEu Version
1.2.0a-build_688
Recipe Viewer Installed
JEI
Environment
Singleplayer
Cross-Mod Interaction
Yes
Other Installed Mods
AE2
Expected Behavior
Blocking Mode from a pattern provider into a subnet with an interface & storage busses should read the contents of the busses/hatches so AE2 knows to block the next payload of the pattern
Actual Behavior
Intput Hatches and Busses should expose their contents to AE2 storage busses on subnets, allowing blocking mode automation to properly work. This seems to be an explicit issue with how GTM does its own containers
Here's some screenshots from a setup I made to test this issue
The GTM Inputs
A Video Example to show this is in action, queuing recipes, the lack of exposure to the subnet
https://www.youtube.com/watch?v=_ZfFUCLfGpk&feature=youtu.be
Steps to Reproduce
Make a Pattern provider with any GTCEU recipe
face pattern provider into a interface on a subnet
place storage busses facing into your input bus/hatch or both
set pattern provider to blocking mode
start the recipe
watch as it sends multiple payloads through to the machine due to this bug.
Additional Information
While I'm not sure entirely if this is on GTM or AE2's side, but due to AE2 reading chests and other tanks properly its pretty safe to assume this is on GTM's side. - I would also like to note this works fine for Singleblock machines it is only the Input Bus/Hatch that seems to carry this issue. I will note I did not try with the output hatch/bus as I have multiple on my main network that I can see the contents of without issue.