Items do not always properly extract when using in conjunction with Refined Storage

[Martijnpold]

I have noticed that, when you attach an adapter to an interface, the extracting of items does not always work. When extracting stackable items like cables it functions like normal. However, when you attempt to use this system on non-stackable items (that's the items that it seems to struggle on, it might be some other property but I cannot be too sure) the extracting does not seem to work at all. It constantly returns a nil value with those specific items and works fine on any items that are stackable.

[payonel]

please give a specific example that does not work and the code you are using

[Martijnpold]

Bug encountered while using the following setup: Program: https://www.pastebin.com/rvjvgdPJ

Setup:

Input Chest (chest on left):

[Martijnpold]

Originally I encountered the issue when trying to extract specific items such as Dislocators from Draconic Evolution, those items do not seem to extract when they are bound to a location, whether they are renamed or not. Seems to be related to the NBT data in some way (is my guess).

[payonel]

testing this I found some non-stackables work fine. I'm using OpenComputers-MC1.12.2-1.7.4.153.jar and refinedstorage-1.6.12.jar

works: iron chest plate lava bucket

did not work: enchanted book

[payonel]

first of all, this appears to be a limitation or bug in refined storage's implementation of their block_refinedstorage_interface they provide for our adapter. none of the code at issue here is in our OC source, it is here: https://github.com/raoulvdberge/refinedstorage/blob/mc1.12/src/main/java/com/raoulvdberge/refinedstorage/integration/oc/EnvironmentNetwork.java#L288

It could be because some nbt data is lost "in translation" by design, we (OC) don't map every bit of data for any given item stack back to the lua side of the world (user code) in that table you get for an itemstack. We give the interesting bits, but we do not plan to add more to fix issues like this. For example, an enchanted book "Protection I" will be this table:

{
 maxDamage=0,
 damage=0,
 label="Enchanted Book",
 name="minecraft:enchanted_book",
 size=1,
 maxSize=1,
 hasTag=true,
 enchantments={{level=1,label="Protection I",name"enchantment.protect.all"},n=1}
}

But that doesn't necessarily detail every single bit of nbt data available. and there are bound to be some mod items (like from DE) that have more nbt data that we don't send between the two layers. And this is on purpose, we're not trying to make a true world save layer in this manner.

For problems like this, where we need to communicate with a mod about items that could be hard to describe we generally try to use api that refers to specific items using a reference slot, like, "see the item in this slot over here, that's the one i'm talking about"

Anyways, I'm not sure what RF is doing to fail to identify which items we're talking about in these tests, they seem simple enough. But they either need to fix their lookup code to consider the little bit of nbt we do send, or provide more api to do some of these harder things