Something of the hurdles I had to cross and one of the points of friction for me was getting used to the naming convention for the Operators.
They are not descriptive in name (e.g after I learned that B stands for Boolean in the end of the operators and I stands for integer (even though it can be read as lower case L).
It would be better to have descriptive names (IfBoolean, IfInteger).
Searching also could to with some wildcards
Typing in Float filtering all the operators that use float as an input or output, not just the ones with Float on its name.
I would expect (AddF, SubF, IfF, etc to also show up when I type float on the search).
Yes, the naming isn’t great. I do plan to make variants of a basic operator be collapsed into one and have the user rely on the context of placement (incoming wire, or first wire attached) to select the actual type of operator used, e.g. AddF, AddI, AddV3, would all be one and switch depending on the context.
This approach would also be used for the multi-input variants, they would appear as a single item in the list and start with two inputs and would change to the the 3-input variant if you try to drag another wire into them, etc. For efficiency reasons, truly variable input counts can’t be supported so they are all actually separate operator types.
But, yes, naming and search could be improved. I might add a search hint string to operators that need it, or just make the logical names more verbose.
This is the most efficient form (powers of two inputs) and can be scaled up to more bits if needed, or kept as separate procedures.
I will probably add these as coded operators once I have the ‘multi-input variants’ supported otherwise there would be a lot of clutter added (extra operators = num types x max inputs).
