I don't see much advantage in making the output label editable, after-all the colours indicate the type of data outputted and the nodes themselves have editable titles which could serve any explanatory role. In instances where the outputs require specific labelling, these should most definitely be retained (& IMHO should remain un-editable)
However, I think the idea would have great merit for inputs.
Often I find myself translating equations so that they have alphabetised variables. It can be a quite counterintuitive process of letter substitution. It would be ideal if the "maths" and "mathsPts" nodes allowed editing of the inputs, like shown:
Also adding new inputs ATM is a 2 step process: first RMB clicking "Inputs" then selecting submenu button denoting next letter. This second step could be removed.
Getting back to "Out" labels. Perhaps we could do an experiment. I could post an alternative nodeEditor folder with all unnecessary labels removed, and those that want to trial it could then report back whether or not they thought the removal of labels had an impact on their user experience.
Although as I said before, that the colour of the output dot indicates the data type, there are a few nodes with more than 1 output of a particular datatype. These cases may require labelling to distinguish between them, but often, as in the case of your "Centroid" node, an extra object output is the same as the object input. This output is useful because it means that a "Clone" node can be avoided. However if nodes could have multiple Obj outputs (similar to Num & Pt datatypes), these extra outputs would then be superfluous. The node may then be like this:
I'm not suggesting you alter your "Centroid" node, I'm only reinforcing the point that node title itself often has all the descriptive content needed to explain the nature of outputs.
PS Switch node is a beautifully elegant node that demonstrates that the absence of I/O labelling is not necessarily an impediment to comprehension and usage.....quite the opposite!
& although it took a long time to create, once done it is possible to adjust thickness, tapers and
even move the 5 way connectors to the interior, so that 3 way junctions are on the exterior.
Unlimited variation: as is the nature of parametric design.
I am getting an error message when using curveLength node. (see below)
code:
TypeError: undefined is not an object (evaluating 'this.outputs[1].label = len[0].toFixed(2)')
moi://appdata/nodeeditor/nodes/extensions/infonodes.js line 74
70: out.addObject(inObj.item(i).clone());
71: }
72: }
73: this.setOutputData(0, out);
74: >> if(len.length>0) this.outputs[1].label = len[0].toFixed(2);
75: this.setOutputData(1, len);
76: }
77: crv_length.prototype.onPropertyChange = function ()
78: {
I have attached a simple .nod file. Can someone please run it to see if problem is universal or specific to my setup. I have already tried reloading both my v4beta & nodeEditor folder without fixing this issue.
Create a test directory for the Node Editor and call it with a shortcut. This way you keep the original directory and have a test area for playing with nodes.
The scripts in MoI often have Functions{} in their code.
The node programs do not seem to use such Functions{} very much.
Instead they use ...prototype...function().
So to use a function from a script, in a node, should they be written as ...prototype...function()?
Or,
I see that in the Lib folder under nodeeditor\nodes\extensions, there is a file called basicFunctions.js,
which is full of miscellaneous functions.
So when writing a node which uses a MoI script with functions, can or should I put the needed functions in a new lib file called, for example, basicFunctions2.js?
- Brian
It seems that the functions in basicFunctions.js can be (re-)used in any new node?
the prototype function gives the objects created by using the nodeeditor a uniform interface for the processing. Same method names for the various
Knots. So every code of the node creates a type. Later by using the node editor you create objects of these types with a uniform interface of functions.
You can of course use the functions in basicFunctions.js and also create a basicFunctions2.js. You can also write your functions to the same file as your nodes.
For more frequently used functions, it makes sense to store them in a library.
Screen Shot 2019-08-29 at 7.46.gif
