I’m not sure if this is located in the correct category? I am new to the Dynamo community. The feedback or question I have is related to node labeling and specifically the List.FilterByBoolMask node. The outputs refer to a True or False status, but the outputs are labeled (confusingly) ‘in’ and ‘out’. Why are they not just labeled True and False? To have an output labeled “in” is insanity. There may be some specific reason, but it seems it could be more intuitive. IMHO.
It does seem odd at first. I don’t know if there’s a more specific reason, but I believe it just has to do with whether the results are “included” (in) or “excluded” (out) from the filter. In many filtering cases, you might expect the filtered result to only return the objects that pass the filter condition, these would be the objects “in” the filter result. This node just provides both lists and therefore returns the “in” results as well as the “out” exclusions.
Nick,
Thank you for the reply & that makes a lot of sense. If that’s the case, then to avoid confusion I’d want to see “Incl” & maybe “Excl” instead. But I still have an issue with in & out. Except when it comes to burger joints! 
1 Like
Hey Adam!
First up, welcome to the community!
Topics aren’t really ‘hard and fast’, and 'where to put this isn’t clear even to me and I’m a power user here for sure. For now I’ve reclassified it to List-Logic as it’s directly related to lists (List.FilterByBoolMaks has list in the name after all) and logic (why things are the way they are).
This used to drive me insane as well. Sadly it’s one of those ‘early decisions’ which have long lasting repercussions, as the node returns multiple outputs. I can’t speak to why these values were used, but I can speak to the impact of the change and what that process might look like.
Here’s some technical background to cover what is happening when you call a node with multiple outputs. When nodes do this, the results are actually a dictionary, where the keys match the output names. This can be reviewed by lookingg at the data preview of the node (expand the results list); you’ll notice that it’s a dictionary with an ‘in’ and an ‘out’ key. THis is the raw results of the function in C#. The node takes the inputs, passes them into the function, gets the result as a dictionary (seen in the preview), and then calls for the ‘in’ or ‘out’ values from the dictionary.
Since the Dynamo team controls both the function’s result and the keys of the node, they could alter them to both be ‘included’ and ‘excluded’ or any other string that might make sense today and the node would continue to work.
However, anyone who calls the method in a code block using design script, in a Python context using the Python node, or in C# for use in a zero touch or node model node would have their code stop working as the ‘in’ key would cease to be.
Steps could be taken to enable both the old key and the new one, but that would consume a good bit more memory and slow things down by a non-trivial amount, so it’s not really viable.
This doesn’t mean we can’t get it changed, but that it has to happen at the right time and with a good bit of runway so the other tools that call the function can migrate to the new keys for the results. That next major change would likely be Dynamo 5 if not 6, which is a fair bit into the future (Dynamo 4 is already out as a daily build in advance of the next integration). So if you’d like, submit an issue to the Dynamo GitHub or Dynamo public roadmap, and we’ll see if we can get enough community support for the change. But know that even if that change is acted on, you’re going to be in the boat with me and have to learn to live with the ‘in’ and ‘out’ keys for at least a few years more.
1 Like