Feature: Flowanvas Macros for usage in Nodecanvas Action-&ConditionTasks

FlowCanvas Forums Support Feature: Flowanvas Macros for usage in Nodecanvas Action-&ConditionTasks

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #1881

    I’d like to suggest some ideas:

    I was thinking that it might be convenient to be able to use flowcanvas-macros or even whole flowgraphs as
    Actiontasks & Conditiontaks in the Action-Lists & Condition-Lists in Nodecanvas.
    Currently a flowcanvas has to be it’s own State / Leaf.
    I think it would be more encouraging to create smaller more modular behaviour-pieces (using flowcanvas) as macros ( or flowgraphs ) and then fire them up in an action-list inside of an Action-/Condition-Node in coexistence with the Action-/ConditionTasks.

    It would allowa more playful feeling and wouldn’t force me to model each action in an own state. Chaining actions In one Action-/Condition-Task allows to group them semantically in a coherent node.
    If one wants to use his flowcanvas-creations , at the moment one is forced to leave this neat semantical structure.

    Also I’d really appreciate , that when having flowgraphs in nodecanvas, that it woulnd’t enforce! the view to jump out of flowcanvas-graphs everytime one enters playmode.
    I find myself all the time : Enter playmode, reach the point where it enters a flowcanvas-graph, then hit escape to leave gameview, focus on flowgraph, doubleclick to peak into the flowcanvas-graph-node, then focus on playwindow aggain, hit play and continue testing.
    This is quite exhausting.
    Yes there may be the risk to edit asset-references accidentally. But I’d really prefer another solution, maybe a big warningsign inside of the flowscript-window or maybe even something preventing the user to change the asset until it is instanced, but it should allow me to let the canvaswindow rest as it is and not having to go through the procedure described above.

    Best Regards, David.


    Hello Dave and sorry for the late reply!
    Welcome to the forums 🙂

    Please let me address your requests:

    1) This is a nice suggestion and something that has previously been requested. Another user even made a extension such as this (posted on the NodeCanvas forums), but unfortunately no longer works in the current version. I plan to add this feature in the future and was hoping it would be there by now, but I really have to refactor some other things first, thus to support this feature more “elegantly”.

    2) This is something I want to “fix” apparently as well, but (apart from the accidentally editing asset possibility) it is actually quite hard to correctly implement. Basically the tricky part is replacing the asset currently in the editor with the instantiated graph of that asset “when” it is actually instantiated, but I understand this can be frustrating in certain situations, thus I will take another look at how to nicely implement this ability first thing right after the next version is send to the asset store!

    Thanks a lot for your suggestions Dave!

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


    1) Nice to hear that I am not the only one who thought about this

    2) AH, I see , the fruits are not as low hanging as they seemed :). Maybe if there was an option to explicitly tick/mark a nested FC-Node( or even multiple ones ) as jump-into-node as soon as it gets instantiated/ activated, that would be totally sufficient. Until instantiation , nothing to watch there anyways.. even better & more interesting to watch what happens on the above layers. The feature would be as simmple in usage as setting breakpoints is . ( Probably would have to prioritize when running nodes concurrently, but other than that…). The exhausting part of the process is the exiting of the player window, fiddling into canvas ,clicking into node,…..,….. Its not a problem to not being able to see the node immediately,there’s no need to see the node’s content immediately after entering playmode. I know, coming up with feature suggestions is so easy 🙂 But as long as you invest in support for your product, I will support you with providing suggestions maximize usability of the framework 😀 Thank you, and have all a nice weekend



    1) Indeed 🙂

    2) Thanks for your suggestions. The problem I see with this, is that if we check multiple nested nodes as “jump in” nodes”, then the editor view can potentially become very confusing by the various changes that can take place due to the nested graphs being instantiated at different times. Basically the view will change by itself without any user input and that can become quite frustrating as I foresee it.
    I will give it another shot to make it so that the editor retains the current graph view when entering playmode, even if that graph is still unsubstantiated and thus still an asset reference.

    Thank you!

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

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.