0000495: Trade-o-mat puts/gets item into other trade-o-mat - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0000495	Industrial-Craft²	machines	public	2013-07-25 21:22	2014-06-26 15:22

Reporter	flugsio	Assigned To
Priority	normal	Severity	minor	Reproducibility	always
Status	closed	Resolution	open

Summary	0000495: Trade-o-mat puts/gets item into other trade-o-mat
Description	2 Trade-o-mats (TOM) on top of each other, chests to the side. When booth TOMs is using the same currency (Dirt in the pics), the top TOM will put the payment into the bottom TOMs payment slot, producing a second buy. Then the bottom will output to the top, until all items are gone from the chests. If the other TOM is using something else as payment, it will not receive the dirt from the top... ---- Maybe another issue, but very related: Trade-o-mats next to each other can Offer items that are in the other trade-o-mats 4 different slots.
Steps To Reproduce	Place 2 trade-o-mats next to each other Use the same item in the private "Want:" slot Put some offers in the slots and chests next to the trade-o-mats Put a payment in one of them See that the payment wrongly goes into the other trade-o-mat
Additional Information	I speculate that this was introduced in the code when the TOM was to allow to put payment items in any surrounding chest, instead of the one that it took the offering item from. Maybe double chests started working around the same update. A solution might be to exclude trade-o-mats as targets. Since the item gets return to the "public" side.
Tags	No tags attached.

Minecraft Version

flugsio 2013-07-25 21:22 reporter	2013-07-25_23.00.44.png (68,172 bytes) 2013-07-25_23.00.44.png (68,172 bytes)

flugsio 2013-07-25 21:23 reporter	2013-07-25_23.00.52.png (54,105 bytes) 2013-07-25_23.00.52.png (54,105 bytes)

Torden 2013-10-26 18:08 reporter ~0001854	This happens because TileEntityTradeOMat extends TileEntityInventory which implements IInventory, which is found by the first trade-o-mats call to StackUtils.getAdjacentInventories and the next thing to happen is the call to StackUtils.distribute which places the input item from the first trade-o-mat to the inputSlot of his neighbour, beacuse inputSlot has added itself to TileEntityInventory's invSltos in InvSlot constructor, and two other preceeding slots (demandSlot and offerSlot) are full already Do you realy need TileEntityTradeOMat to be fetchable/distributable? If not, a check can be made for (source instanceof TileEntityTradeOMat) in StackUtils.fetch and StackUtils.distribute, or maybe even in StackUtils.getAdjacentInventories. The bug reproduces in IC2 Experimental 2.0.280 also

Torden 2013-10-27 16:37 reporter ~0001858	sorry, not (source instanceof TileEntityTradeOMat) but (!(target instanceof TileEntityTradeOMat)) and this should be added to (target instanceof IPersonalBlock) check

Thunderdark 2014-06-26 15:22 viewer ~0002499	cleanup campaign close all reports > 6 months

Date Modified	Username	Field	Change
2013-07-25 21:22	flugsio	New Issue
2013-07-25 21:22	flugsio	File Added: 2013-07-25_23.00.44.png
2013-07-25 21:23	flugsio	File Added: 2013-07-25_23.00.52.png
2013-10-26 18:08	Torden	Note Added: 0001854
2013-10-27 16:37	Torden	Note Added: 0001858
2014-06-26 15:22	Thunderdark	Note Added: 0002499
2014-06-26 15:22	Thunderdark	Status	new => closed