When a block or block entity changes in the world, CC refetches the peripheral from the adjacent block. If the peripheral has changed, CC detaches the current peripheral, and attaches the new one.
On NeoForge for Minecraft 1.20.4 or later, a new inventory object is returned every time we query the item storage capability. This means the new generic peripheral is not considered equal to the previous one, and so the peripheral is reattached.
This problem is made worse by 04900dc82f143e6342b7196a0126a939ead09609, as now peripheral methods will frequently return nil due to the peripheral frequently attaching and reattaching.
I can think of a couple of options here, but none of them feel especially good:
Add a custom equality for IItemHandlers, which checks for InvWrapper and CompoundContainers. This is sort of what we did in 9b63cc81b1765d566e8ce2872b655cd5712194ca for Fabric, but it feels like we're papering over the cracks rather than doing something sensible.
Refetch the capability on each method call. So instead of storing the inventory itself, we store the block capability. We'd have to have some special handling to check whether a particular method is still appropriate (so if the underlying class of the inventory has changed), and then somehow invalidate the peripheral then and requeue the method on the new peripheral?!
We'd also require all generic peripheral methods to be called on the main thread, which isn't a big restriction (it's the case anyway), but is annoying.
Some way to update the peripheral in-place. So when the peripheral is refetched, we swap out the existing target in the saturated methods. We'd need to then make the generic peripheral provider stateful, which I don't feel good about.
Minecraft Version
1.20.6
Version
1.110.3
Details
When a block or block entity changes in the world, CC refetches the peripheral from the adjacent block. If the peripheral has changed, CC detaches the current peripheral, and attaches the new one.
On NeoForge for Minecraft 1.20.4 or later, a new inventory object is returned every time we query the item storage capability. This means the new generic peripheral is not considered equal to the previous one, and so the peripheral is reattached.
This problem is made worse by 04900dc82f143e6342b7196a0126a939ead09609, as now peripheral methods will frequently return
nildue to the peripheral frequently attaching and reattaching.I can think of a couple of options here, but none of them feel especially good:
Add a custom equality for
IItemHandlers, which checks forInvWrapperandCompoundContainers. This is sort of what we did in 9b63cc81b1765d566e8ce2872b655cd5712194ca for Fabric, but it feels like we're papering over the cracks rather than doing something sensible.Refetch the capability on each method call. So instead of storing the inventory itself, we store the block capability. We'd have to have some special handling to check whether a particular method is still appropriate (so if the underlying class of the inventory has changed), and then somehow invalidate the peripheral then and requeue the method on the new peripheral?!
We'd also require all generic peripheral methods to be called on the main thread, which isn't a big restriction (it's the case anyway), but is annoying.
Some way to update the peripheral in-place. So when the peripheral is refetched, we swap out the existing target in the saturated methods. We'd need to then make the generic peripheral provider stateful, which I don't feel good about.