It seems that the current list contains_p does not have the support required if I want to use the operator "raw item equals" in conjunction with a list in order to ignore NBT and damage on both the list and the item to be searched for then negating it to result in a kind of
if (!listOfItems.raw().contains(itemToBeTransferred.raw())) if you can understand that weird pseudo java type thing.
Another list contains operator might be needed here.

Yeah, I've tried that an insane amount of times, all it does is says "This aspect expects operator, but received boolean"
And then if I flip it like intended for, it just says "ERROR" at the bottom, yet has a tick next to it.
Although, what do you mean by "Pipe raw equals into it"? Maybe I'm not getting you there...

Similar to CyclopsMC/IntegratedDynamics#195.

Will see if I can come up with a more generic system that can handle both cases.

I think this can be done already, though it is messy. If this were written in Haskell, it would be written like this:

contains_p listOfItems . rawItemEquals

Or in other words, a contains_p operator, apply listOfItems, then pipe rawItemEquals to it, and you should get a function Item -> Boolean that says if the list contains a matching item.

Make sure you are creating Operators, not regular variables. So you'd need to select "Operator" on the left and then find "Contains Predicate" in the middle list, etc. By pipe, I mean the pipe Operator. Pipe allows you to take an Operator a -> b and an Operator b -> c and combine them, so you get an Operator a -> c.

Yes, I am creating Operator Variables, but I had no idea about the pipe operator... thanks, I'll have to try that!

Rest in peace.

I just tried this myself and it worked fine. I started with the itemList and itemToBeTransferred variable cards, then did this:

1. Went to "Operator" in the logic programmer and made an "Item Raw item equals" variable card (I'll call this "X")
2. Went to "Apply" in the logic programmer, put in "X" on the left and itemToBeTransferred on the right, and made a new operator variable card (I'll call this "Y")
3. Went to "contains_p" in the logic programmer, put in itemList on the left and "Y" on the right, and made a new boolean variable card (I'll call this "Z")
4. Put itemList, itemToBeTransferred, "X", and "Y" in a variable store

At this point, variable card "Z" behaved exactly like you want it to. Does this work for you, or am I missing something?

I had no idea about this itemToBeTransferred operator, how do you find out about these things?
I'll try it out at some point... we don't really play the map I was using this on anymore, though.

@Revvilo itemToBeTransferred would simply be the name of a variable card containing an item that you need to transfer.

If this fits your requirements, I'll close this issue. I'll leave CyclopsMC/IntegratedDynamics#195 open though.

Oh... right...
Look honestly it's been so long since I've thought about it that it's kinda fuzzy what I originally needed.
I'm pretty sure I basically needed a blacklist that ignored NBT, where the list of items is obtained from a chest.
Obviously, the whitelist is easy because you simply put the list of items in "items to be transferred" and set ignore NBT to true, but a "Don't transfer these items" is what I'm looking for.
I'll try josephcsible's suggestion right now though... because I think I've proved enough that I have no idea what I'm doing.

I'm not sure what the itemToBeTransferred is meant to be, a single item variable? Because that wouldn't work for my requirements, I want it to search through the chest and ask if the raw item is not contained in the raw list like I explained above.

@Revvilo Okay, I get what you want to do now. You want an input chest, an output chest, and a blacklist chest, and to move all items from the input chest to the output chest unless they "raw item equal" an item in the blacklist chest. When I tried building this, I discovered the problem that you were running into. Here's what I did:

1. Made a variable card from the "Items" aspect of the blacklist chest. I'll call this "blacklistItems".
2. Went to "Operator" in the logic programmer and made a "List Contains Predicate" variable card. I'll call this "containsPredicate".
3. Went to "Apply" in the logic programmer, put in containsPredicate on the left and blacklistItems on the right, and made a new variable card. I'll call this "blacklistContainsPredicate".
4. Went to "Operator" in the logic programmer and made an "Item Raw item equals" variable card. I'll call this "rawItemEquals".
5. Went to "Pipe (.)" in the logic programmer, put in rawItemEquals on the left and blacklistContainsPredicate on the right, and made a new variable card. I'll call this "blacklistContainsRawItem".
6. Went to "Negation (!.)" in the logic programmer, put in blacklistContainsRawItem, and made a new variable card. I'll call this "rawItemNotBlacklisted".
7. Put blacklistItems, containsPredicate, blacklistContainsPredicate, rawItemEquals, and blacklistContainsRawItem in a variable store.
8. Put rawItemNotBlacklisted in the importer or exporter's predicate slot.

When I did this, I got the error "The property is expected to output Operator, while Boolean was found for operator Item Raw item equals." @rubensworks I now believe that this is a legitimate bug, but not the one originally mentioned. Specifically, I believe that the Pipe operator does not handle partial application/currying correctly. "Item Raw item equals" is "Item -> Item -> Boolean". When I call Pipe with it on the left, it's only supposed to get passed a single value, so it should end up returning "Item -> Boolean", which is an operator. However, the error message makes it seem that Pipe believes that it just returns Boolean.

I'll try it out myself to see what is going on there.

I'm sorry my explanations were so vague and caused all this rigamarole. I should really have started with explaining in basic terms what I needed and working from there. Thank you @josephcsible for helping me out here 😄

Ok, this was a very fun issue to debug, but not an easy one though. :)

@josephcsible In the next ID update your operator chain will work as expected.

For cases like these sharing method for complex operator chains would be really useful, I should start looking into something for that soon...

@rubensworks you only made that commit (and today's other commits) to the 1.10 branch, not 1.11 or 1.12.

For cases like these sharing method for complex operator chains would be really useful, I should start looking into something for that soon...

Also, this could actually be the use-case for CyclopsMC/IntegratedDynamics#211. In addition to the new internal format, it could also be user-facing so it can be copied and pasted.

@josephcsible Yes, I'm aware of that. Will merge with the other branches when I intend to make a new release.