Describe the bug

We are playing All The Mods 10(4.2) on our dedicated Server, and currently I am working my way through Oritech and I am automating it allong the way with AE2 and it's pattern providers. The Oritech Machines don't push their outputs out, back in to the pattern provider, so an import bus is needed. I used it with an inverter card in which I blacklisted different fluids(vanilla and modded, both same behavior) but every time i do, the import bus stops importing/working. It works fine when I use the import bus without the Inverter Card for Fluids and Items, or when using an Inverter Card and then blacklisiting only Items or Items and fluids .
Tested it with different mods, e.g: the Dissolution Chamber from Industrial Foregoing and the behavior ist the same.
I also have to notice that the ouput of the Machines, both Chiller and Dissolution Chamber are items again. For Example, Chilling Lava to Obsidian: I put Lava in the filter of the import bus with an inverter card(in my understanding blacklisting the lava from being imported and importing everything else instead) but then this import bus will not import the Obsidian, it works when I instead take the inverter card out and put Obsidian in the Filter(in my understanding saying only obsidian will be imported)

Maybe i'm understanding the inverter card wrong?

How to reproduce the bug

1. Place any Machine that works with different fluids (e.g. Dissolution Chamber from Industrial Foregoing or the Industrial Chiller from Oritech)
2. Place an import bus with an inverter card and only blacklist fluid(s), when blacklisting fluids and items, it works as expected
3. Import bus will stop importing

Expected behavior

As said above, I expected the import bus to not import the blacklisted fluids, but still import everything else, instead of just discontinuing to work.

Additional details

For the Crash log I added the the server debug log when I was trying around and testing after noticing it, it will not help you because there a no entries from AE2 but i was forced to add one in order to create this issue.

Which minecraft version are you using?

1.21

On which mod loaders does it happen?

NeoForge

Crash log

https://mclo.gs/KrP86Bj

Filters in ae2 have the quirk that they are inverted when empty, i.e. an empty import bus imports everything (which would match an empty blacklist), however with some items in it it becomes a whitelist of those items.

Similarly, with an inverter card, an empty filter will result in not importing anything.

Combine this with the fact that filters are treated per individual resource, this results in your observed behavior.

For a more intuitive result, it should probably be changed so filtering any one resource will make it behave like it would if every resource would have a non-empty filter (so it would behave like you expect it to).

Ohhh ok, I think I understand what you mean.
If I understand your comment correctly the import bus basically divides between items and fluids. So I have the import bus with an inverter card, and only blacklisted fluids, the bus will import only fluids that are not blacklisted. For items on the other hand the blacklist filter is still empty, so everything is blocked and no items will be imported. Did I understand that correct?

So in theory, if I would add any item to the blacklist, especially one I could never produce e.g. Bedrock, the bus would start importing Items again...
...and it worked! Just tested it, Thank you very much, this is quite an easy hotfix while the problem persists.

Or at least I would hope that it will be implemented/fixed in to the more intuitive way like you said. I think I can cofidently guess that every player reading the description of the inverter card for the import bus would expect the behavior I expected.

Sounds like a duplicate of #8068 to me

I've identified the exact cause of this bug. When using an Import Bus with an Inverter Card to blacklist fluids, the bus stops importing items entirely.

The Problem

The issue is in StackTransferContextImpl constructor (lines 39-42):

this.keyTypes = new HashSet<>();
for (AEKey item : filter.getItems()) {
    this.keyTypes.add(item.getType());
}

The keyTypes set is populated only with the types present in the filter. When you put only fluids in the filter (to blacklist them), keyTypes contains only AEKeyType.fluids(), not AEKeyType.items().

Why It Fails

1. In StorageImportStrategy.transfer() at line 34:

   if (!context.isKeyTypeEnabled(conversion.getKeyType())) {
       return false;
   }

2. isKeyTypeEnabled() in StackTransferContextImpl at line 81:

   return keyTypes.isEmpty() || keyTypes.contains(space);

3. When the Import Bus tries to import items with a filter containing only blacklisted fluids:

   • StorageImportStrategy.createItem() is called
   • conversion.getKeyType() returns AEKeyType.items()
   • context.isKeyTypeEnabled(AEKeyType.items()) returns false because keyTypes only contains AEKeyType.fluids()
   • The item import strategy is disabled!

The Solution

The keyTypes set should contain ALL types supported by the Import Bus (defined by StackWorldBehaviors.withImportStrategy() in ImportBusPart line 45), not just the types present in the filter.

The constructor should be modified to accept the supported key types from the Import Bus and use those instead of deriving them from the filter items.

AI-Assisted Analysis of the InverterCard Bug 🤖

Hello! This is an analysis generated by Claude Code 4 Opus to help understand the root cause of this issue. Please note that this is an AI analysis and may contain errors or misunderstandings. My goal is simply to provide additional insights and support to the developers, not to replace human expertise.

Summary of Findings

After analyzing the codebase, I believe the core issue lies in how StackTransferContextImpl initializes its keyTypes set:

// In StackTransferContextImpl constructor
this.keyTypes = new HashSet<>();
for (AEKey item : filter.getItems()) {
    this.keyTypes.add(item.getType());  // Only adds types present in filter
}

When the filter contains only fluids with an InverterCard:

1. keyTypes only contains AEKeyType.fluids()
2. isKeyTypeEnabled(AEKeyType.items()) returns false
3. Item import is completely blocked before any filtering logic

Why This Happens with InverterCard

The issue manifests specifically with InverterCard because:

• Without InverterCard: Filter acts as whitelist (empty filter = import nothing specific)
• With InverterCard: Filter acts as blacklist (we want to exclude specific fluids)
• The keyTypes detection doesn't account for this inversion of logic

Potential Solution

The filter should determine which specific resources to allow/deny, not which resource types are enabled. A possible fix:

// When filter is not empty, include all supported types
if (!filter.isEmpty()) {
    this.keyTypes.add(AEKeyType.items());
    this.keyTypes.add(AEKeyType.fluids());
    // Add other types as needed
}

Note to @Mithi83

I see you've done extensive analysis on this in #8068 - your insights about the complexity are spot on. The interaction between KeyTypeSelection, filter types, and the InverterCard creates multiple edge cases. My analysis might be oversimplifying some aspects you've already identified.

This analysis was generated to assist developers in understanding the issue. Please verify all findings against the actual codebase and test thoroughly before implementing any changes. The AI may have missed important nuances or constraints in the system.

Follow-up: User Expectations Discussion 💭

@Mithi83 @Gimpansor - I saw your interesting discussion on Discord about user expectations. You raise an excellent point about the ambiguity of what users expect when using an InverterCard with a type-specific filter.

The Two Possible Interpretations

Interpretation A: "Type-scoped inversion"

Filter: [Lava] + InverterCard
→ "I don't want lava (but only considering fluids)"
→ Expected: All fluids except lava, NO items

Interpretation B: "Global blacklist"

Filter: [Lava] + InverterCard
→ "I want everything except lava"
→ Expected: All items + all fluids except lava

As Mithi83 correctly noted, we have a selection bias - we only hear from users who expect interpretation B and consider the current behavior a bug.

Potential UX-focused Solution

Instead of changing the core logic (which might break existing setups), what about improving the UI to make the behavior explicit?

┌─────────────────────────────┐
│ Import Bus Configuration     │
├─────────────────────────────┤
│ Resource Types:              │
│ ☑ Items  ☑ Fluids          │
├─────────────────────────────┤
│ Filter Mode:                 │
│ ○ Whitelist (only these)    │
│ ● Blacklist (all except)     │
├─────────────────────────────┤
│ Filter Items:                │
│ [Lava] [Blood] [+]          │
└─────────────────────────────┘

This would:

1. Make resource type selection explicit and separate from filtering
2. Replace the InverterCard with a clear mode toggle
3. Remove ambiguity about scope

Alternative: Enhanced Tooltip

If UI changes are too invasive, perhaps just improve the InverterCard tooltip:

"Inverts the filter within each resource type.
Note: Only resource types present in the filter are processed.
To import items when filtering fluids, add any item to the filter."

What do you think? Would separating type selection from resource filtering help clarify user intent?

AI-generated response to contribute to the discussion