Routed Request Pipes requests items, spits out correct item, but decreases the amount of the wrong item with same parent id
czzarrr opened this issue · 12 comments
EDIT: This occurs in the latest update 4.3.2.26.
When requesting any item that uses the same parent id (ie wood blocks, saplings, etc.) the routed request pipe will pull from the closest chest that has the same parent id, no matter if it is the EXACT item.
For example,
Three different types of wood is present in the system in three separate chests, like so:
Request pipe - Chest (Oak Wood) - Chest (Spruce Wood) - Chest (Birch Wood)
When requesting the oak wood, it pulls out the Oak from the system as intended. The routed Request pipe's gui updates with the correct amount of oak that is left in the system. But if Spruce Wood is requested, the system will spit out Spruce Wood, BUT will be decreasing the number of Oak Wood by as many Spruce Wood is Requested. The same goes for if Birch Wood is requested, wherein the system spits out Birch, but the number of Oak Wood is decreased.
The system has basically turned into Equivalent Exchange where items are being "transmuted" into other blocks with the same parent id according to which item is closest to the request pipe.
I'm no programmer, nor can i make/read any code from Minecraft or mods, but it seems to me like the system is not checking for the damage values for the blocks that are being requested. I do not know if this is intended but personally it seems like a bug.
I use this mod as part of the Attack of the B-Team modpack from Technic, and others from that modpacks' forum have reported planks and witchery saplings, and basically any other item that uses a parent id, has this same issue.
I don't understand.. Items don't 'transmute', they only go from one place to another. So is the GUI wrong, or are the wrong items coming out?
The correct item that is requested from the gui is pulled from the system, but the wrong item is being taken out of the chest. Chest 1 has 64 of Spruce Wood, and Chest 2 has 16 of Birch Wood. when requesting 16 Birch, 16 Birch spits out of the request pipe, but when looking into the request pipe gui again, 48 Spruce wood and 16 Birch wood appears in the system. none of the birch was taken out, but 16 spruce has, even though 16 birch was requested in the first place.
This only happens if the Chest with the spruce wood is closer to the request pipe than the chest with the birch wood. when requesting spruce wood, the system works as intended.
Yes, but when making a request does the right item come out? As in, is it just a GUI problem? Or does the closer wood come out, regardless of type?
On Mar 17, 2014, at 8:49 PM, czzarrr [email protected] wrote:
This only happens if the Chest with the spruce wood is closer to the request pipe than the chest with the birch wood. when requesting spruce wood, the system works as intended.
—
Reply to this email directly or view it on GitHub.
yes the closer wood does come out. its not a problem with the GUI. when physically checking the items in the system, the GUI shows the correct amounts before and after the request is made. I get the item that i requested, but the wrong item is pulled from the storage chest.
Chest 2 - 1 Birch Wood
Chest 1 - 4 Spruce Wood (There is also a third chest further than the chest with the Birch wood that has 64 Spruce Wood)
1 Birch in the system
68 Spruce in the system
Requesting 1 Birch
Requesting 3 Birch in total
3 Birch in output chest
1 Spruce in Chest 1 closest to the Request pipe
65 Spruce and 1 Birch Remaining in system
After requesting 3 Birch from the system, 3 Birch was received, but 3 Spruce was lost, while the original 1 Birch remained.
Just for completion sake, this was originally reported on the Attack of the B-team modpack tracker on the technic website. http://forums.technicpack.net/tracker/issue-892-project-red-routing-pipe-dupe-bug/
Sounds like a metadata problem, is the metadata getting compared when routing items?
I'm using version 4.2.2.19 and I was not able to reproduce the bug. If I have time later I'll try using your version.
Fixed via dcc2ce2. As per the newest version when ore dictionary matching was introduced, Broadcasters defaulted to using this behavior (because it isn't configurable for them).