but what if we’d got another node between 4 and 5?
it wouldnt have to touch the “do block”, but letting it float freely would leave max with the decision which one comes first, wouldnt it?
@xXm0RpH3usXx: This is a good point. You are correct, it would leave max with the decision of which piece of code to evaluate first. So, adding a floating node between 4 and 5 would produce an ‘evaluation error’ in your example. The ‘floating node’ is interpreted as the last piece of code in a code block, so there can only be 1 floating node inside another node. This may seem confusing, but just know that you don’t have to use ‘floating nodes’ at all. Here is a more complex, real-world example using Euclid’s greatest common denominator algorithm:
It’s difficult to read, so here is a link to a much larger image.
Below is the maxscript equivalent of the nodeset above.
In the nodeset, I’ve used red to color code where the struct instance is declared.
Also, note that the nodeset isn’t evaluated top to bottom, left to right. It’s evaluated based on the node’s connections (what they touch) and scope. In this example, all code exists within main’s scope. Please post any other questions you have, I enjoy answering them.
u see, although highly interested, i am not much of a coder, so it is already difficult to makes sense out of the code and then even translate it into “nodish”…
u said i shall i ask so now u got to deal with my idiotism ^^
so basically the reading is from inner to outer then?
but wouldnt it be logical if it started with the “main” bubble?
then why is it first evaluating the “B == 0” and not the “if A > B”?
so basically the reading is from inner to outer then?
actually, it’s the oppposite. Nodes are evaluated according to their scope (or in the nodeset example, by their size).
So first, the main () node is evaluated. That is the giant circle enclosing all the other nodes. This circle is equivalent to:
--main
(
...
)
Next, the struct definition is evaluated (the giant red circle). This is equivalent to:
struct GCDclass
(
...
)
And continuing on, evaluating the public fn findGCD, and then the if statements within the function. So, largest nodes are evaluated first, then nodes inside them are evaluated. This ‘nesting’ is related to ‘scope’.
but wouldnt it be logical if it started with the “main” bubble?
Yes it would be logical. Thus, it does.
then why is it first evaluating the “B == 0” and not the “if A > B”?
B must be checked before the algorithm continues on, otherwise the algorithm would never end, because it is recursive (the function calls itself in a loop). “If B == 0 then print A” is the end condition. If B does not satisfy this test, then the algorithm continues on, decomposing A and B until B = 0. Once B = 0, we know that A is the common denominator for the inputs. Here’s a little history on the algorithm.
Hey, looks like something comparable is coming to javascript!
http://www.i-programmer.info/news/98-languages/2389-waterbear-a-visual-language-for-javacript.html
Yep, waterbear is based on scratch.
Although both of these give me hope for the VME, I don’t like how the nodes resemble puzzle pieces that snap together. Intuitive, but not elegant – in my humble opinion.
In other news, it would appear that ‘flowcode’ is a name for an already established coding language. As well as this one. So, I gotta find a different name for this ‘visual coding language’. Any suggestions, max users?