Colossal Chests / Integrated Dynamics / Silent Gear compatibility issue

[uhloin]

Issue type:

• 🐛 Bug

---

Short description:

Cannot get silent gear converted item from colossal chest via ID terminal

Steps to reproduce the problem:

1. Create colossal chest
2. Connect item interface and terminal
3. Craft iron chestplate
4. Convert it to Silent Gear chestplate (by putting to crafting grid)
5. Put Silent Gear chestplate to terminal
6. Try get it to inventory - impossible
   Similar issue with other converted items like swords, boots etc. You can get it to mouse cursor but not put to inventory. Also you can find it in colossal chest itself and get from it without use ID terminal, So may be it's ID issue.

---

Versions:

• This mod: colossalchests-1.21.1-neoforge-1.8.8.jar
• Minecraft: 1.21.1
• Mod loader version: neoforge 21.1.68

Other:
IntegratedDynamics-1.21.1-neoforge-1.23.9.jar
IntegratedTerminals-1.21.1-neoforge-1.5.2.jar
IntegratedTunnels-1.21.1-neoforge-1.8.28.jar
IntegratedCrafting-1.21.1-neoforge-1.1.10.jar
silent-gear-1.21.1-neoforge-4.0.5.jar
silent-lib-1.21-neoforge-10.3.0.jar

[rubensworks]

Thanks for reporting!

[rubensworks]

Does this problem also occur when storing that item in a regular chest, and connecting that up to an ID network?

For reference, sounds related to CyclopsMC/IntegratedCrafting#17

[uhloin]

Just checked - yes
And in both tabs (Item Storage, Item Crafting) and with normal terminal and portable version

Here is minimal list of mods I used to reproduce:

CommonCapabilities-1.21.1-neoforge-2.9.5.jar
cyclopscore-1.21.1-neoforge-1.25.1-630.jar
IntegratedCrafting-1.21.1-neoforge-1.1.10.jar
IntegratedDynamics-1.21.1-neoforge-1.23.9.jar
IntegratedTerminals-1.21.1-neoforge-1.5.2.jar
IntegratedTunnels-1.21.1-neoforge-1.8.28.jar
silent-gear-1.21.1-neoforge-4.0.5.jar
silent-lib-1.21-neoforge-10.3.0.jar

[rubensworks]

Hi @SilentChaos512 👋,

I'm looking into this ID-SilentGear compat issue, and it looks like the root cause is items not matching.

Concretely, if the player wants to extract an item from the terminal, a packet is sent to the server, which contains the item to be extracted (serialized using the normal ItemStack codec).
Then, this item is looked up server-side by checking equality.
This equality check includes checking data components, but it looks like the client-side and server-side components are different, which causes the equality check to fail.

Below, I have a screenshot that shows this difference:

I suspect that the ItemStack codec may be serializing client-side only data components (such as base_properties?), which then incorrectly end up server-side.
But I could be wrong.
Do you have an idea what could be going wrong here @SilentChaos512?

[SilentChaos512]

Both the base_properties and bonus_properties are network serialized, but not persistent. That could be the problem.

[rubensworks]

Thanks for the input @SilentChaos512!

I've done some more digging, and it looks like my code is failing on an equality check on two silentgear:construction data component values, which looks like they should be equal, but return false for #equals.

I've looked at the implementation of GearConstructionData, and since it's a record, #equals and #hashCode should be generated correctly.
However, it looks like PartList is not a record, and AFAICS, it has no override of #equals and #hashCode, even though this is required for custom data component values.
Could this be a problem on your end @SilentChaos512, or am I missing something?

[SilentChaos512]

I will update PartList with the missing methods. Hopefully that helps.

[rubensworks]

Thanks @SilentChaos512!
I'll have a look soon to see what the impact is on my end.

[rubensworks]

@SilentChaos512 The GearConstructionData now apears to be comparing correctly on my end.

However, there silentgear:properties seems to be another data components that has a missing equals and hashCode implementation, with GearPropertyValue and GearProperty (and classes such as NumberPropertyValue and NumberProperty).
I suspect this to be the only remaining one, because if I manually skip it from comparison, the bug described in this issue goes away.

[SilentChaos512]

Cool, I'll get those addressed in the next update! Thank you for taking the time to debug this and work with me.

…

On Fri, Oct 25, 2024, 09:27 Ruben Taelman ***@***.***> wrote: @SilentChaos512 <https://github.com/SilentChaos512> The GearConstructionData now apears to be comparing correctly on my end. However, there silentgear:properties seems to be another data components that has a missing equals and hashCode implementation, with GearPropertyValue and GearProperty (and classes such as NumberPropertyValue and NumberProperty). I suspect this to be the only remaining one, because if I manually skip it from comparison, the bug described in this issue goes away. — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLU6XL5WTHPHKSP6N6LEODZ5JILTAVCNFSM6AAAAABQDYRF2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZXHE3DSMJQGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rubensworks]

Thanks @SilentChaos512!
With the latest Silent Gear update, this problem seems to be fully resolved!

Note to self, I thought this change was necessary, but this was not the case in hindsight:

diff --git a/src/main/java/org/cyclops/commoncapabilities/ingredient/DataComparator.java b/src/main/java/org/cyclops/commoncapabilities/ingredient/DataComparator.java
index b36f4870..3224197c 100644
--- a/src/main/java/org/cyclops/commoncapabilities/ingredient/DataComparator.java
+++ b/src/main/java/org/cyclops/commoncapabilities/ingredient/DataComparator.java
@@ -43,8 +43,8 @@ public class DataComparator implements Comparator<DataComponentMap> {
         Set<DataComponentType<?>> k1 = o1.keySet();
         Set<DataComponentType<?>> k2 = o2.keySet();
         if (ignoreDataComponentTypes != null) {
-            k1 = k1.stream().filter(k -> !ignoreDataComponentTypes.contains(BuiltInRegistries.DATA_COMPONENT_TYPE.getKey(k))).collect(Collectors.toSet());
-            k2 = k2.stream().filter(k -> !ignoreDataComponentTypes.contains(BuiltInRegistries.DATA_COMPONENT_TYPE.getKey(k))).collect(Collectors.toSet());
+            k1 = k1.stream().filter(k -> !k.isTransient() && !ignoreDataComponentTypes.contains(BuiltInRegistries.DATA_COMPONENT_TYPE.getKey(k))).collect(Collectors.toSet());
+            k2 = k2.stream().filter(k -> !k.isTransient() && !ignoreDataComponentTypes.contains(BuiltInRegistries.DATA_COMPONENT_TYPE.getKey(k))).collect(Collectors.toSet());
         }

         // Check if keys are equal

[uhloin]

Thank you both, bug disappeared with new release of SG.