Itemsadder Items workaround?
I’m using Networks together with ItemsAdder, and ran into an issue:
Some ItemsAdder items (like sushi) are technically minecraft:cooked_porkchop with CustomModelData — but Networks seems to only filter based on the base item ID. So both the vanilla porkchop and the custom IA sushi end up in the same chest, even though they’re totally different.
➡️ Would it be possible to add support for filtering by:
• CustomModelData
• or full NBT (optional)?
• or maybe even ItemsAdder’s namespaced ID (like itemsadder:sushi_nigiri)?
Would be amazing for custom-item setups!
Thanks a lot 🙌
– Daniel
12 Replies
Hey rwolupo,
This is already possible by using the "Strict Filter" mode on the Network wand instead of the regular "Filter" mode.
Regular filter mode adds the item type as a filter.
Strict filter mode adds the specific item with it's full meta data as a filter.
Just left-click with the wand once in the air to cycle between modes.
oh thx .. but .. when i left click with the wand it switches between FILTER and PRIORITY. Is that the right function?
What version of Networks are you using?
In the older versions, the strict filter mode doesn't yet exist
omg .. .apex serves a really old version. 2.1.19
Ah, they use Curseforge probably...
My plugin is only available on Modrinth, but older versions used to be on Curseforge too
I'll remove the outdated files from curseforge, so this can't happen again
ok thx
Hey! Quick update and a follow-up question 😊
I’ve successfully updated Networks to the latest version from Modrinth – everything runs fine now, thanks again for the help!
Here’s what I did:
• At first, I left the old chests from my Networks 2.x setup in place – but as expected, that didn’t work because the whole logic is different now.
• So I broke all the old chests and placed fresh, regular chests.
• I added them to the network using the frame item, and then tested item routing using both Filter and Strict Filter modes.
But now I’m seeing some weird behavior:
• Items are not going into the chests I assigned them to.
• Instead, they always seem to end up in the oldest chest I added to the network, no matter what filter I set.
🤔 So I’m wondering:
• Should I have deleted the old network data from the 2.x version first?
• And if I do that now, will that just remove the network logic – or will it also delete the actual items in the chests?
I want to make sure that if I delete the old network config or files, the items inside the chests will remain untouched.
Thanks a lot in advance for any insights! 🙏
– Daniel
or is there any other solution for this @Kwantux
(gern auch auf deutsch)
Hey, thanks for reporting this!
There was indeed a bug in the way, strict filters were applied in 3.0.11
The bug should be fixed by the latest snapshot
Hey again! Just wanted to give you a quick follow-up report after updating to the latest version.
✅ Most things are working now – thanks!
After switching to the latest beta (as you suggested), the major issues are mostly resolved. Most of the chests now sort items correctly.
⸻
🐛 However, I’ve noticed two remaining issues:
1. ItemsAdder items with shared base item types
• Some ItemsAdder items (like a “Nest” and a “Nest with Eggs”) are internally based on the stick item (minecraft:stick).
• I set up filters using Strict Filter mode.
• But when I try to sort them:
• The custom nest item ends up both in the chest for sticks and the chest for nests.
• This happens even when both are filtered separately.
• So either:
• The metadata isn’t being respected fully when sorting, or
• There might be something odd in how these ItemsAdder items are defined (maybe wrong tags?).
⸻
2. Sorting containers need an empty slot
• It seems that sorting chests must have at least one free slot (completely empty).
• If all slots are occupied (even if the stacks are not full), no items get routed into that chest.
• That feels like a bug, as you’d expect items to be added to existing partial stacks.
⸻
Let me know if you’d like me to do further testing or send logs/examples. Thanks again for the great support!
– Daniel
To point 2:
That's actually an option in the config file.
Just checking a slot should require less performance, but not alot.
If you set
complexInventoryChecks = true that should be resolved.
To point 1:
I'll look into that, perhaps that plugin stores data outside the vanilla item meta (which is used to set filters)point 2 worked fine ... just waiting for point 1 😉