Describe the bug

Searching for $forge_tags does not yield any results in ME terminal.

To Reproduce

Search for a forge tag in an ME terminal. For example, put some iron ore in storage and search for $ores or $ores/iron.

Expected behavior

For matching items to be presented.

Additional context

Environment

• Minecraft 1.16.4
• Forge 35.1.4
• AE2 8.2.0-alpha.2
• All The Mods 6
• Forced crash log https://paste.ee/p/X4LKg

There's also export stuff, such as an export bus, or an interface told to keep things in stock. I actually came across a situation where I wished the export bus had a tag/fuzzy filter: export any wood to a formation plane network to automate Botania's Pure Daisy.

do two string compares each for the namespace and path

Or you could just ignore the namespace. I don't think JEI supports specifying namespaces in tag search at all.

Making these checks fuzzy is definitely where the dragon lies, and there is no easy answer that I can think of.

If you come up with anything, I'd be happy to do some testing. I'm an avid "expert mode" pack player, and quite used to dealing with huge networks and large amounts of item types.

Maybe this is less of a problem than we think, who knows.

Actually, can't search in #tooltips either. That would definitely also be nice.

Currently this is not supported at all and supporting it can be problematic for a couple reasons.

One is that tags are very flexible and every mod can freely add more for their own use. E.g. some mod might add something like a #foo:smeltableItemsIntoIngots to list everything their furnace supports or #bar:ingots to tag their own ingots on top of the forge default ones. So if someone only searches for #ingots it can list all sorts of items and not just ingots without a clear indication of why. To provide a distinct result it has to use a precise tag like #forge:ingots, which usually are internal details never exposed to players at all.

Also compared to JEI we cannot take like 30-60 seconds to build a fast searchable cache during the startup or the initial serverjoin and then use it constantly. We would have to do this each time a terminal is opened and probably each time an item is added or removed from the network. Even if we could optimize it to say take only 5 seconds, I doubt many players will be happy that it takes 5 seconds to display the inventory and each time something changes it is unusable for 5 seconds or so.
Or otherwise have it drop down to 1 FPS each time you open a terminal.

I might look into it at some point as it might be useful feature for some players, but that will really depend on how much effect it has on the performance in larger modpacks down the road. But certainly do not rely on it being guaranteed to be added.

Well, that is your prerogative, of course. Your mod, your choice. I'm only here to provide feedback and suggestions, and perhaps to have a discussion on the topic.

I understand the difference between what is essentially a compile time cache for JEI and a runtime cache for AE2. One has zero overhead, the other potentially infinite overhead. I know this is not an easy task if you hope to not just grind everything to a halt. But I also don't think it's too hard a problem to at least warrant exploring.

I suppose I see this kind of thing as much more important than you do. Tag based filters, not just for terminal search, albeit very convenient for that too, are an important tool for making complex automation manageable with a limited interface like Minecraft. They are an expressive language that allows you to set rules for how things should move in your base. The alternative is to define each item individually, which quickly gets cumbersome.

I think perhaps you might be underestimating the importance of this feature. I believe the kind of player that likes AE2 would appreciate the power of such a feature. The ones that don't, probably hate channels and 63 item types per disk, and never used AE2 to begin with 😛

I understand this is a potentially very complex feature to implement, and I don't expect you to drop everything and start working on it, but just closing the issue and dismissing the point entirely seems unnecessary.

As said, it would be a nice feature. To some degree even trivial to implement.

But it really has the problem of being at least something like O(n*m) with m being the tags for each unique itemstack. With these not being controllable in any way, if we are lucky it might average to like 2-3 per item, which would probably be fine with a few hundreds items, yet this doesn't have to be the case it can easily have like hundreds of tags assigned by some modpack as they use it to track progress or similar.

We already cache the current view, so as long as nothing changes, it won't affect it at all. But once it changes, it has to apply the filter again. So while it might look like it works fine in development, in a real modpack it could easily break down.
And iirc the functions to actually work with tags in this way are added by forge itself and in the past I rarely had good experience with things they added in terms of performance. While it might work fine within the confined space of 27-36 slots of a vanilla chest/player inventory, once it gets larger it scales not always well.

So yes, while it might be added, it's not really in terms of it will happen in any case just might time. More about how mods and modpacks will make use of tags, however there aren't that many advanced ones for 1.16 out yet.
I really don't want to make any promises here or even worse have to pull a feature later on because it's a massive issue.

I'm not really familiar with Forge or Minecraft modding, so I don't know how much is forced on you by Forge and Minecraft. If you have a hash map of tags to item types, which you can compute at boot as JEI does, you would end up with a list of types you want to filter for given a tag. The complexity of that shouldn't be much worse than string comparison. In fact, it could be significantly better with some extra hashing done at boot. This really only supports single-tag searches, though. Precomputing all possible tag combinations would probably make RAM vendors very happy, and allow you to walk the dog while Minecraft starts.

Search complexity would indeed be O(n*m) if we wanted to find all items matching all tags of a given item. This would be the case for item substitution in a pattern as it is now, but not for item search in a terminal.

Rather than allowing to set an item in a pattern and have a box that says "substitute items", you might look into allowing the user to set specific tag patterns instead of items in certain slots. Such as "allow any forge:ingot/iron here". You should already have a hash for the tag, and lookup should be cheap.

There are two things here. One being patterns, these will never see any explicit support for tags defined by users, but they can already implicitly infer the tags from the recipe (or actually exploded list of items representing a tag).

The other being the terminal search. Which is just a string. We can certainly turn that into a tag, but it has to be exact. In other words someone has to type #forge:ingots into it. #forge:ingot won't show anything as it does not exist. Same for #ingots as by definition resources without a namespace are expanded to #minecraft:ingots (for ingots here). Which probably also does not exist or only contains iron and gold.

For filtering all itemstacks with a specific tag, it should just be O(n) as each item has a set of tags, which should be allow querying in O(1). Getting all items from a tag and then checking if the inventory content is contained there should be the same overall.

But it has the downside that #ingots won't show anything. For that we have to iterate over all tags from each item and do two string compares each for the namespace and path. Which does't sound promising in terms of performance. As well as including every tag containing ingots. Except without some interesting caches like a tree based on each character as node pointing to a subset of items matching it. Memory would probably not be happy with it and also resource like tags and recipes can be reloaded dynamically at runtime and require a rebuild.

So the quick win probably sucks either in terms of performance or more or less being useless for most players if they'd first have to type a 30 char long string without any typo to have it work.