Would it be an easy to develop feature to make wiring direction flippable at a certain node? Currently, if you have a number of nodes in multiple rows, then the wiring goes always left to right like:
So after node C, the wiring turns back and goes to the left to be able to connect to D. However, if it was possible to flip the direction of wiring for node D so that the input port is displayed on its right and the output port(s) are displayed on its left, we could have something like this:
Sorry for the schematic flows but I hope you get the jist. Once a wiring is flipped at a node, it'd remain like that for all nodes after it till the wiring is flipped again. This could result in cleaner and more transparently displayed flows I think. What do you think?
I totally agree, we should be able to connect the ports at different positions of a node. I think to avoid confusing between IN and OUT, it will be even better to have an option of an arrow head, which will TELL the node the DIRECTION of flow. Also better to have PORTS at top and bottom as well
What a pity, I missed those discussions -actually didn't even find them yesterday. I disagree though as I think it'd reduce the number of crossing wires. Nevertheless, I can of course accept your decision.
If arrowheads were on by default, it wouldn't be that confusing. If anything, it might help tidy up a bit.
Link nodes are fine, but sometimes about half of the nodes are links back and forth, and that is also very confusing, not being able to see where the wires go on first glance. Links are still super useful for jumping between tabs or between separate parts of the same flow, but for tidying up, it would be great to have the option.
Another thing that would help a lot to tidy up things would be a small branching node, a dot where you could connect wires and would just forward anything that comes in to all the wires in the output, a bit like an empty function node with only "return (msg)" inside.
On occasion, I've found myself having to add a debug node to see what comes on the INPUT of a certain node. This is usually not an issue, but when you have a node with 40+ wires connected at the input, adding such a node implies duplicating a sh*tload of wires.
In cases like this, the option I usually get is to add an empty function node to gather all the inputs and forward a single wire to the next node. That allows to connect the debug node in between with just one wire. I could also do it with link nodes, but then I have to add two nodes instead of one.
I was thinking of something the size of a deployed link node (the small square) with both input and output, that could be used just to sort out these situations where many wires converge on just one node.
It won't be until 3.0 now and we need to consider how to make it somewhat backward compatible - so flows can be shared with older versions of NR with some way of it working - much like we did when we added Groups.
I currently do the same thing you set there with an empty function node, but I assume it has certain overhead and if you need to add/delete it you have to rewire the whole thing. Junctions would solve that.
As for flipping the node direction, things like this could look much better (and would not be confusing if the wires had arrowheads):
I think that there might be some backwards-compatibility issues in the designs of nodes here since there are references to left/right which make assumptions about left->right flows. Certainly some careful testing would be needed to make sure that nodes still made sense visually if the in/out direction was swapped.
Also, how would the decision to "go round the corner" be made? I think it would need some measure of user control at least.
I guess I'm in two minds about this. I think that I've adjusted my flows to deal with the left-to-right flows but then maybe my flows aren't as complex as some people's.
I also think that there are laws of diminishing returns on visual based programming tools. In general, if a flow is getting that complex, it would probably be better to invest in collapsing parts of the flow to a subflow (and maybe the node creator) or making use of the link return features to create separate "functions". Either way, breaking the flow into more manageable sections. In extreme cases, I think you would get to a point where a custom node would be beneficial. Just saying that, just because you start with a visual tool, not everything needs to have the same level of visibility necessarily.
That I can only agree with and that's why we introduced using the command object design pattern. However, refactoring comes with retesting We did not have enough time to refactor/retest everything and still have some bigger spaghettis which could look better if there was some way to make them cleaner without retesting them.