Understanding Call (new Flow(1)) vs Call(f)

[edwoodgrant]

Hello again,

This is more of a simple question in terms of architecture. I’d like to understand what it means to call a flow when developing a new Node.
Is there any special difference in just passing the original Flow f, or in creating a new Flow(1)?
What does the integer in flow mean? I usually just put 1 in it, but I’m not sure what it exactly means. Also I don’t know when to just pass the original flow or create a new one.

Thanks a lot,

PS: Do you know if you have something of a Roadmap we can check out on what you plan to do next? Or maybe do you have an ETA of the next release. Thanks again…

[Gavalakis]

Hey,

That is an interesting question.

The general idea, is that a new Flow should be used when conceptually the node is meant to signal the start of a new flow in the graph, while the existing received Flow should be used, when conceptually the node is continuing on a previously started flow signal.

Thus, a new Flow should be created by Event nodes, since event nodes are the ones that signal a new flow traveling in the graph, while in all other cases where is possible and an existing Flow is already received, that same Flow instance received should also be further passed down to the next node called, by doing “Call(f);”

Architecture wise, this way we can for example tell how many “ticks” a single flow signal has done from start to finish (event node to final destination node). We can also pass temporary parameters that live within the Flow instance down the “flow pipe” which we can set or get using the “Read/Write Flow Parameter” nodes, and which can prove useful is some advanced situations. There are also some other features planned, which will require this architecture to be followed by all nodes created.

The value given in the constructor (the 1), is a legacy/deprecated feature that is no longer used or needed and serves purpose no longer, thus the value you provide in the constructor, is currently irrelevant. This is why I suggest that to avoid confusion and for your convenience, to use “Flow.New()” instead of “new Flow(1)” (which is basically a shortcut).

To recap:
– Whenever an existing Flow instance is received, you should use that received instance in your next call down the pipe if possible ( Call(f) ).
– If no Flow instance is received, thus it is the start of a new flow signal, then of course a “new Flow()” should be created and used, which is basically the case for all Event nodes.

Please let me know if that helps, or if you need any further information.
Thanks!

(PS: I am planning to make a sticky post with the planned features sometime within the week 😉 )

Join us on Discord: https://discord.gg/97q2Rjh

[edwoodgrant]

Perfect!
Thanks a lot for the insight n_n, I will modify my custom node accordingly.

I’ve been having lots of fun recreating a RPGMaker-esque system in Flowcanvas and it has been pretty easy to extend the system with custom nodes I must say. I do want to rely a lot on custom nodes, so as to make the designers and artist a lot easier to develop a simple event system just for this project. So all of this has been nice to develop :).

I do have a completely unrelated question, do you know about “best practices” when laying down Nodes in FlowCanvas? Maybe there is a way to nest/collapse flows.. or maybe I should tell my designer to be very careful in laying out flow nodes. 🙂

[Gavalakis]

Hey,
You are very welcome and I am glad to hear you put FlowCanvas in good use like that 🙂
Indeed making custom nodes project wise like you do, is a very good workflow approach!
Regarding “best practices” for laying out nodes, I believe that using Canvas Groups is one of the main ones 🙂
Just in case you haven’t seen it yet, to create a Canvas Group, start dragging a selection rect, then before release, hold down the Control key.
Another good organization would of course also be Macros.

Cheers!

Join us on Discord: https://discord.gg/97q2Rjh

[Author]

Posts