opencomputers api extractItem() fails when item has NBT data

[JheregJAB]

Issue description:

Using opencomputers api, extractItem() returns nil and fails to function.

What happens:

I can read item stacks in the network and correctly identify the items I wish to extract. However, calling the extractItem() method always returns nil and nothing happens.

What you expected to happen:

When calling extractItem(), the stack should be extracted from the network.

Steps to reproduce:

1. Create a refined storage network with a terminal, controller, storage disk, and interface.
2. Below the interface, place a container of some kind (I used an actually additions crate, but I also tested with a vanilla chest and that did not work either).
3. Connect an opencomputers computer with an adapter touching the rs interface.
4. Add some number of Gendustry "Bee Samples", more than 2 of several types. These are the genetic samples for forestry bees.
5. Try the following lua code, observe that it does not function.

local component = require("component")
local sides = require("sides")

local rs = component.block_refinedstorage_interface

for i,stack in ipairs(rs.getItems()) do
  if string.find(stack.label, "Bee Sample") then
    if stack.size > 2 then
      print("Found Stack " .. stack.label .. " With size " .. stack.size)
      extracted = rs.extractItem(stack, stack.size - 2, sides.down)
      if extracted == nil then
        extracted = 0
      end
      print("Put " .. extracted .. " " .. stack.label .. " into crate")
    end
  end
end

In my case, I get output stating that the program found stacks, but always extracted 0. There is also nothing in the chest. No errors appear either in the lua output or in the server log.

Version:

ATM3: Remix 1.3.0

• Minecraft: 1.12.2
• Forge: forge-1.12.2-14.23.5.2825-universal.jar
• Refined Storage: refinedstorage-1.6.14.jar
• Refined Storage Addons: refinedstorageaddons-0.4.4.jar
• OpenComputers: OpenComputers-MC1.12.2-1.7.4.153.jar

Does this issue occur on a server? [yes/no] yes

If a (crash)log is relevant for this issue, link it here:

[pastebin/gist/etc link here]

[JheregJAB]

I've been doing some more troubleshooting with this, and I have come to realize that it seems to be a problem with the gendustry samples only. I tested again with putting some cobblestone into the system and trying to extract that and it worked fine.

I also walked the code approximately line by line in the interactive lua prompt. When I do it this way, extractItem returns nil "could not extract the specified item".

[JheregJAB]

I have further refined (pun intended) my understanding of what is happening.

It appears that the extractItem() method will fail (as in, not extract) whenever an item has NBT tags. I tested with a variety of items, including a vanilla enchanted pickaxe. any time the item had an NBT tag, the extract would fail.

[balloman]

Has anyone found a fix for this bug yet?

[raoulvdberge]

1.12 is no longer maintained and since OpenComputers still hasn't ported to 1.16.x, closing.

[tth05]

@balloman This is not a bug. You just have to enable allowItemStackNBTTags in the OpenComputers config. Otherwise the NBT tag is not sent to your script which means it's not sent back when you're trying to extract something.

[JheregJAB]

@tth05 At no point in the script do I attempt to view, modify, or use NBT data. All I do is read the label (name) of the item, and then try to extract it. This works fine for items not containing NBT tags, such as cobblestone. As soon as an item has NBT data, such as an enchanted pickaxe, it fails. Seems like a bug to me.

Are you telling me that if I tested using an opencomputers robot to extract from a vanilla chest, that it would also not be able to operate on items with NBT data?

If it isn't a bug, then how is one expected to interact with items containing NBT data? Is there a way to work around this I am unaware of? I gave up on making it work when I posted the bug report and no one replied.

[tth05]

The fix is to enable the config option I mentioned.
Here's what's happening:
Refined Storage gives all items to OpenComputers. OpenComputers then converts those to lua tables, but leaves out the nbt tags because that config option is disabled by default. Then you call the extractItem method, where you give the table back to OpenComputers which converts it to an ItemStack and then gives it to Refined Storage. Here the nbt tag is already gone.

[JheregJAB]

Still sounds like a bug to me. Maybe a bug in open computers instead of refined storage, but a bug nonetheless. Leaving out the NBT data shouldn't break interaction with non-NBT data, but it does. At the very least there should be some method of workaround that isn't "enable the config option". In a multiplayer, server environment this may not be feasible. I don't know how it would work on the backend, but it seems like anything open computers can do with a vanilla chest should be doable with refined storage, but it isn't in the case of an item with NBT data. Again, I don't even want to interact with the NBT data. just the item as it exists.

All that said, your description makes sense and I'd like to thank you for the explanation, even if we disagree on whether it is intended behavior.

[uecasm]

The problem is that Refined Storage has to treat items with different NBT tags as unique items, because various mods use these for all sorts of weird and wonderful purposes.

When you ask for an item without NBT data, that is a different item from an item with NBT data (or an item with different NBT data). So RS is correctly saying that the item that you requested isn't in the storage, because you're not giving it enough information to determine which item you actually wanted.

For a simple example, imagine that you have three different diamond picks in storage -- one is enchanted with fortune, one with silk touch, and one is unenchanted. They all have the same item name, but they have different NBT data and they are different items, and when you ask for one you don't want to get the wrong one just because it happened to be first or the others happened to be missing from storage at the time.