Issue type:

• 🐛 Bug

Short description:

When using Entity Item to map an Entity to an Item with certain item types, the resulting Item is not equivalent to an Item variable created directly from the Item.

The same Item object is not considered equivalent to itself when one side of the comparison is read from an Entity List Entity Reader aspect mapped using Entity Item, due to misbehaving Forge Capabilities not being correctly ignored, for some reason.

Steps to reproduce the problem:

Items which can have the offending Forge Capabilities are affected. For this, try e.g. a Golden Pickaxe.

A mod which provides a misbehaving Forge Capability is also required, such as Astral Sorcery.

1. Entity Reader, pointed at Golden Pickaxe item thrown from inventory onto the floor
2. Use Entity Item to map the Entity List aspect to a List<Item> object
3. Attempt to compare the Item in the resulting List to an Item created directly from the LP.
   For example, try to append the Item and then uniq the list, or create a List<Item> and Relational Equals compare it.

Almost all attempts to consider the two Item objects as "equal" will fail.

Investigating the NBT of the materialized cards reveals the following:

Materialized Entity Item

{
  _type:"valuetype",
  typeName:"valuetype.valuetypes.integrateddynamics.itemstack.name",
  _id:47,
  value:
  "
    {
      ForgeCaps:
      {
        \"astralsorcery:cap_item_amulet_holder\": {AS_Amulet_HolderLeast:-8648566478292736409L,AS_Amulet_HolderMost:5174540350827416327L}
      },
      id:\"minecraft:golden_pickaxe\",
      Count:1,
      tag:
      {
        ench:[{lvl:1s,id:16s}],
        RepairCost:1
      },
      Damage:0s
    }
  "
}

Materialized Regular Item

{
  _type:"valuetype",
  typeName:"valuetype.valuetypes.integrateddynamics.itemstack.name",
  _id:48,
  value:
  "
    {
      ForgeCaps:
      {
        \"astralsorcery:cap_item_amulet_holder\":{}
      },
      id:\"minecraft:golden_pickaxe\",
      Count:1,
      tag:
      {
        ench:[{lvl:1s,id:16s}],
        RepairCost:1
      },
      Damage:0s
    }
  "
}

Expected behaviour:

The two items should be considered equal.

Versions:

• InDy: 1.12.2-1.1.1
• CommonCapabilities: 1.12.2-2.4.4
• Astral Sorcery: 1.12.2-1.10.19 (provides misbehaving Forge Capability)
• Minecraft: 1.12.2
• Forge: 14.23.5.2838

I looked into this a bit, it seems like the special NBTBaseComparator from CommonCapabilities, that ignores Astral Surgery's NBT values, isn't used by ValueItemStack#equal

That does indeed sounds like it may be the cause of the problem. Changing that should have no unintended consequences AFAIK.

This apparently isn't completely replicable. Further investigations pending.

Discovery: it's misbehaving Forge Capabilities e.g. Astral Sorcery. Sigh.

This seems to be because nothing being used to compare the items is actually using the CommonCapabilities comparator that ignores the misbehaving Forge Capabilities.

I looked into this a bit, it seems like the special NBTBaseComparator from CommonCapabilities, that ignores Astral Surgery's NBT values, isn't used by ValueItemStack#equals.
@rubensworks Do you see any side-effects if that were to be changed?

I have seen other NBT effects on items like this where the NBT will disappear entire lines if the item is removed and reinserted into anything.
Also if you take out the items that is effected into your inventory the NBT is replaced with new info, so you can not use the programmer to make the item variable.

@Pultex mixing issues makes it harder to keep track of them.
This issue is specifically about items not being equal to themselves due to attributes that are in S:general.ignoreNbtPathsForEqualityFilters in Common Capabilities' config file and should thus be ignored, but... aren't.

If you're referring to an unreported problem, please create a new issue for it.