Overboy's Forum Posts

  • To be clear Overboy, I don't mean having them linked to the same values Outputs use. I mean having a second list for inputs like this

    This is a super quick mockup, as long as we can "name" inputs I think it's good enough

    Isn't it already how it works ?

    (it looks like a bit redundant with how it works right now + it would be a bit confusing and it involves the fact we need to manually add Input Value in addition to Output value which could lead to "misclicks")

  • I think linking inputs to "IDs" would let you get a parent by ID, instead of by whatever is already there.

    I can see a few reasons why this would be cool, but it's mainly for UX and just letting things be more open IMO.

    Just in general, having more control over how the input field works is good.

    Could also make it so we can write graph structures where instead of seeing this as a node structure, we treat everything as siblings and so any node can be linked to from either side.

    Let's say I use this as an FSM, having every single link go out from the node from the left side can be pretty painful.

    I still don't understand how it would help 🤔

    Being able to do FSM by linking later nodes to first nodes would be indeed very useful, as the posts of the first page of this thread explain.

    But what would be the benefit to connect a value to an other value rather than a node ? I can't find any example of usecase. You can already get any value from an output node anyway

    Also even if they are usecases, wouldn't it be unreadable and confusing ? let's say you have some stuff that have the whole Node as output and some other stuff that have values of this Node as output.

  • They can, it's just that you can't link an input with a value the same way you can with outputs

    Oh yeah they can ! cool, I probably failed my input when i tried doing so on last update r370 (when we didn't have feedback for linking nodes)

    It wouldn't make sense to link an input to a value, so the way it works right now is good, a whole Node can have different input Nodes !

    I maintain there should be properties in a Node to override the corresponding values in all parent Nodes. Because while it can make sense in a Dialogue System to have different values connected to the same node, in some other situation it would be a pain to make sure all corresponding values in Input Nodes are exactly the same. (If a node has overriden properties, then the corresponding input values would be grayed out with those overriden values so the user understand he can't edit it there but must go in Output Node properties instead)

    EDIT : Ooooh i realized why i didn't manage to link multiple Inputs, we can't link multiple Values from the same Input Node to the same Output Node. We only can link 2 different Input Nodes to the same Node Output

    I don't understand why there is this restriction tbh, it's confusing because it can make people think multiple Input isn't supported

  • Overboy I went back and read through your whole suggestion. I agree with a lot of it.

    Arrow management, definitely.

    A. Conditions in the node options so they can transition automatically if condition is true, hell yes.

    B. Nodes with multiple inputs, I'm pretty sure it can already do that.

    C. A few different node types like link to other flowchart, random, and potentially sequence, yes

    D. I just don't like each node having it's own event sheet. I think it would encourage spreading logic around too thin, which would make issues harder to debug. If Scirra decides to implement that then cool, I won't complain, but I won't use it either.

    Just a few precisions of what i had in mind

    A. Node Conditions are not meant to 100% automatically and immediately go to output node which verify those (most of the time we want to wait something to happen before changing node, like a user input for Dialog or some other conditions for State Machines). But thanks to a new "Are Node Conditions True ?" condition, it would allow us to easily create any system we'd like that use Node Conditions using a Node Template feature. For example you would create a "Random True Ouput" Node Templates. In its Node Tick function, you would create a subevent checking for a user Input (On A Gamepad button press), then it checks all output nodes with Conditions that are true, pick a random one that is true and enter this output node. We would still be able to create Nodes that 100% automatically and immediately choose a output node via Node Enter or Node Tick functions if we want, but it should be flexible.

    B. Nodes can't have multiple inputs AFAIK (edit : my bad they can)

    C. The only 2 actual different Node Type would be to link other Flowchart (so it could include button to switch to referenced flowchart) AND "tiny Arrow Nodes" that does noything but help with arrow management, IMO everything else like Random or Sequence would be best achieved thanks to "Node Templates" allowing to have variable and default overridable/extendable functions OnEnter/OnTick/On update. So the user would create its own Random Output Node Template or Quest Task Node Template thanks to the shared logic that act differently depending on Node instance variables and even be overriden or extanded via additional ACE + super call on Node instance functions.

    D. It would be 1 flowchart sheet per flowchart with a group containing 4 premade blocks for each node, not 1 node sheet per node. (So we could easily find all nodes by scrolling up/down and copy paste ACE from one to another but the Open Node in Flowchart Sheet button would automatically focus the relevant place on the Sheet opened as pop-up, so no need to switch tabs)

    (The two last points changed from my first posts as I realized they would be more powerful/pleasant/simple ways to achieve similar stuff in later posts)

    Some advantages of a automatically handled Flowchart Sheet with premades Blocks vs Event Sheet with Triggers :

    1. No more string checks for everything
    2. Easy way for construct to open a relevant place with all the logic of a specific node in one place (Node Enter/Tick/Exit but also Node Conditions).
    3. Would allow to implement the Node Conditions feature there as I don't see any way to implement this in the regular Eventsheets while it's maybe one of the biggest must-have of flowcharts.
    4. As Node Enter/Tick/Exit are like Functions/CustomActions instead of Triggers, it would allow the potential Node Template feature to do the override/extand function for instances as Custom Actions allow to do between Family and Family Members
    5. No manual labor of creating a bunch of Trigger eventblocks for every single node we create which also require to write the exact string tag of the node (error-proned/tedious)
    6. Best organisation possible by default, automatically handled by the engine (no polution of regular Eventsheet for no reason, everything contained in a single asset at the user level, 1 sheet per flowchart, same logic disposition for every single node)

  • Scirra could you just implement a Hierarchy View instead of spending too much time on Flowchart if all issues raised won't be solved and it's just meant to be a data structure.

    Because I'd rather do my branching systems by creating parent/child relationshop between Objects (that would be my "Nodes") with all the features they already have (multiple families / instance variables / Custom Actions/ templates / User-friendly pick child condition / Find all Refs / Copy Paste etc...) to create my Dialogue or Behavior trees. All we need is a cool Hierarchy View that would also be useful :

    - for anything related to Hierarchy : to create relationship via drag an drop, visualize them without green arrows on layout

    - for any workflow involving finding/selecting instances on a layout : find instance via search bar, selecting instance without worrying about Zorder/Unlocked Layer ect..., organize stuff easily

    github.com/Scirra/Construct-feature-requests/issues/9

    Hierarchy View has been the highest requested suggestion on the platform this year, would be cool to see it pushed before platform reboot

    Also if a hierarchy view is added it could be cool to add a common "Instance name" property that override the default ObjectType name for that instance in the Hierarchy View. Would help a ton to quickly find a specific instance of an objecttype later and would be very useful for Hierarchy-based systems like Dialogs/BehaviorTrees.

  • The issue is that I agree that kind of less powerful "Node Template" feature would solve some issues (vs the more ambitious i was suggesting) BUT once it's pushed then it's all we'll have forever. (I was hoping to show the full potential of it before it's "too late")

    I did my best suggesting solutions to solve functionnality and ergonomy issues so we could have the best Node-Tree system achievable to synergyze with the Action/Condition/Eventsheet system Construct has, trying to suggest things that might be ambitious but also makes sense with how C3 works and similar to existing Editor/Runtime features.

    It looks like it won't happen, given the Answers Scirra gave that avoid the issues we raised, at least I tried but i'll just stop here talking/thinking/wasting time about a feature i'll probably never use. I prefer the tricks i found with older features for Dialogue/Quest/FSM/BehaviorTree/Combo systems

    A bit sad about the wasted potential knowing Unity official Muse Behavior and above all Game Creator 2 are showing us how cool it could be and are beating Construct at his own Action/Condition based system in the context of Flowcharts.

    I think the suggestions in this thread would even make C3 Flowchart system 10x better than Game Creator 2 and Muse Behavior thanks to its flexibility and all synergies with existing features/ACES (The system wouldn't be built for a specific application like Dialogues or Behaviors but would be powerful and flexible enought to create all kind of branching system with ease)

  • yeah ok so all X first output are "node instances variables" and everything after ID = 5 are actually out nodes ?

    yeah this is a cool hacky trick, but there are still all the other deal breakers for me

    Also it still assumes feature that are not yet included in Flowchart features :

    -indeed it would require us to be able to duplicate Nodes to avoid the pain of manually creating every single variable every time in the right order, with the right name etc...

    But then, if you want to expend the system of this "node type", you would need to manually add that Variable in all existing nodes (right index + right string name) + change the index where output are actual node links instead of variables.

    For me, it only solve 10% of the problem at most while still requiring new features and hacky tricks even if I admit this is a smart trick.

    I still prefer the tricks I found with older features to achieve Dialogue System or FSM.

  • piranha305

    I don't understand what you're meaning with this screenshot ?

    Why are you setting the "variables" as node outputs, how would you branch this Dialog node to other Dialog nodes. Outputs is supposed to store other nodes, not the "variables" of the current node.

    The Dialog Node should be linked to other Dialogue Nodes.

  • Fib Yeah but this means we have to recreate every single ACE that already exist in Construct 3 to create our own awful node-based Unreal-like Blueprints ?

    Where each action and condition is replaced by a Node Type, that we need to define in other eventsheet via a bunch of strings checks on top of that ?

    This is exactly what sucks about Blueprint. A Variable is a node, a trigger is a node, a condition is a node, an action is a node, an inversion is a node.

    Also it still doesn't solve the Node Data issue i keep mentionning. What about the avatar sprite, the avatar animation, the text animation and so on ?

    I'm all for being able to create Custom Node Types and i perfectly know it can be achieve this way with current features but it doesn't scale.

  • What tokens are you talking about and why would you have to remember them all? If youre just talking about node tags then I don't see the issue. C3 has tag systems everywhere, audio, timers, tweens, solid collision filter, etc. Why would node tags be any more cumbersome than those?

    I already explained this several times. Tokenlist aren't related to Node Tags but to Node data. What if you have a Dialogue System where each Dialogue node has a different Dialog Text but also Avatar sprite, Avatar animation, Text animation, pacing data (wait for X seconds) ect... then you have 2 bad options (well in fact even more but they all suck) :

    1. either you put all the Data in a big token list as the Node value

    "my text dialog text or id that can already be a long string, myAvatarSpriteName, myAvatarAnimation, TextAnimationKind, WaitXSecondValue" that will be interpreted in a "OnAnyNodeEnter" that use ACE based on those tokens

    ACTION : wait tokenat(MyDialogData, 5, ",") seconds

    2. or you create a new trigger for each node via the "OnSpecificNodeEnter" but then you need to copy past the WHOLE logic of your dialog nodes in every single Trigger for every single Node and if you want to expand the capabilities of your Dialog System you'll need to painfully add/remove ACE in every single Trigger Block (imagine you have 5000 as Ashley suggested)

    ACTION : wait HardcodedValueOfSepcificNode seconds

    (but that action need to be copy paste in all specific Dialog Node Trigger)

    (I know there would be other hacky tricks to achieve that kind of thing but they all suck)

    The example i provided is extremely simple, most system would need far more data for each node.

    Which is why I suggested a Node Template feature that would allow Node Instance to inherit variables (each instances would be able to have different values for those variables like instance of an ObjectTypes) + have default OnNodeEnter/Tick/Exit functions that can be overriden or extanded via super Call for each Instances

    This would work perfectly with the Flowchart Sheet feature i suggested with Node Condiditions + automatically created On Node Enter/Tick/Exit eventblocks on the Flowchart Sheet for each nodes.

  • Yeah this is the error-proned token list i'm mentionning in every post.

    Need to remember the right order of token (is the 17th token in the output data the string-based sound to play when this node is reached ? or it is the wait X second values argh i don't remember, argh i don't have enough space to see all the tokens at once, oops i skipped token 6, mmh i wish i had autompletion for the avatar sprite name) + use tedious token expressions to parse and interprete the data.

    And the manual labor of creating a bunch of triggers on eventsheets with strings checks for tags for each Node we create (without Navigation/Visualisation help).

    Again every solution you mentionned was already what we did with Array/JSON before, except it was handier on some aspects (except the visual arrows I admit)

    I'll keep avoiding the pain of doing games relying on Dialogues/Quests in C3 and anything that looks like State Machines for now then.

    I hope someone at Scirra will take the time to check Game Creator 2 Behavior 2 Module or even better, at least try to understand or just consider the tailored suggestions written in this thread that makes sense in the context of C3 and how it is working under the hood. (written by people who most likely already painfully created their own quest/dialogues/FSM systems using C3 and know how tedious it was and still is)

  • Context menu to switch between a node and its trigger would be nice, but how would that work if everything is string based ? Usually C3 does it when the engine is able to map efficiently things together like with Functions or Custom Actions.

    How would you achieve all the usecases i mentionned with current Flowchart features ?

    - Pick output based on conditions proper to each possible output nodes

    - Having a specific dialogue node that wait X second before executing the regular Dialogue node condition logic

    - Playing different sounds, or putting different actions in every single nodes (let's say you have 5000 nodes as you suggested)

    - Having multiple value to handle for each node (avatar image, avatar animation, text animation, related QuestID, including variables within the actual Dialogue text)

    (just a few simple examples of stuff we need to be able to do with ease)

    Btw i said 2 times it would probably be better if all "Node Sheets" of the same Flowchart would be in fact a single "Flowchart Sheet" opening to the relevant place, as opposed to the mockup I made at first

    I think people are also seriously underestimating the downsides of having different places to put logic. If you have 100 flowcharts encompassing 5000 nodes, with bits of event logic distributed all across them, and then you find something isn't working right... how do you even begin to sort that out? You could easily spend hours just trying to figure out which part you ought to be looking at. Keeping things in the same set of event sheets might seem like an inconvenience, but IMO it's actually far better for scalability and organising larger projects.

    I don't understand what you mean.

    Do you really think having 5000 nodes with string checks in eventsheets, requiring us to manually create multiple trigger blocks (NodeEnter/Exit/Tick) with the right tags 5000 times (so 5K manually writter Node Tags on the Flowchart then 15K manually assigned Triggers with manually written Tags on regular Eventsheets) is better than each flowchart embedding a flowchart sheet with premade functions for each nodes automatically created/assigned and efficiently mapped by the C3 engine ?

    The tag-based trigger way we need to do right now is the actual scalability/organization nightmare.

    I don't see what would be the difference regarding debugging.

    In both scenarios, those are just triggers/functions called when the Node happens.

    Except the flowchart sheet suggestion provides QOL, quickly open all Node-specific logic as a pop-up (so Node Conditions + Node Enter + Node Tick + Node exit packed automatically at the same place accessible as a pop-up with just a click), find all references support easily achieved as NodeEnter is a premade function linked to the Node by the engine, not one of the 5000 Eventsheet triggers the user created manually, after manually defining a tag for the node and then writing that tag name in each related trigger blocks with potential mistake. (what if i want to change the tag later btw ?)

    As i said, under the hood, the engine could perfectly interprete the Flowchart sheet as regular eventsheet anyway, but each blocks within them would be more restricting, automatically handled when creating/deleting nodes of the related flowchart and flowchart sheet wouldn't be displayed in the Eventsheet list.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I don't think flowcharts work well for game logic. You tend to end up with what looks like a big pile of spaghetti, and the two-dimensional scrolling makes it hard to review and change. Our approach with flowcharts is, currently, as a data structure only. This is suitable for things like conversation trees which are typically structured in an ordered way, and game logic stays in the Event Sheet View (or coding). I think this is a good way to bring the benefits of a visual designer for tree-like structures without the downsides of spaghetti-logic.

    We're not suggesting bad node-based Visual scripting like most softwares are implementing. (Most famous example being Unreal Blueprints)

    Node-based visual scripting sucks, especially when each variable or the fact to invert something is a node itself, it indeed looks like Spaghetti and it's an absolute mess.

    Event system like C3 is using is far better.

    HOWEVER, as i explain in previous posts, i feel like what current Flowcharts features require us to do moves the problem to an other kind of "abstract spaghetti" and coupling mess :

    • It requires a bunch of string checks to achieve per-Node-specific Conditions / On Node Enter / On Node Exit / On Node Tick + a lot of manual work every time we add a node (stressful/easy to forget/error-proned)
    • The logic split among different assets
    • With no navigation/visualisation help. (requires to switch between multiple tabs and find the relevant places of each of them each time, need to scroll every time both on Flowchart and Eventsheet)
    • need to painfully parse data contained in huge error-proned token list (avatar frame ? node-specific conditions to pick outputs ? camera settings to change ?), tokens are tedious to deal with on top of that using eventsheet, it requires a bunch of unreadable expressions.

    What i'm advocating for is the best of both world : Node-Trees packed with dedicated Event Blocks for each Nodes :

    (since i made this mockup, i realized it would be better if all "node sheets" of a flowchart were in fact in the same "Flowchart sheet", one after the other, so the pop-up would just automatically scroll to the relevant Node, but we would still be able to scroll the sheet up/down to find other nodes and potentially easily copy/paste ACE from one to an other)

    This is the main point of what i try to explain in all my posts referencing Game Creator 2 (Unity 3rd party tool suite). Node-Tree visual scripting + ability to use Actions/Conditions/Expressions per Node is the most effective way to create :

    • Dialogue Systems
    • Quest
    • State Machines (states machines have infinite usecases : complex player movement behavior, enemy AI, Game States, UI flow)
    • Behavior Trees
    • Combo System for Combat Game
    • Dynamic cinematics

    Existing Triggers included in FlowchartController Plugin are great for some purpose : logic shared by multiple Nodes, but not for individual nodes because the workflow involve many step for each Nodes we create, with no UX / Navigation / Visualation help.

    However even that last point could be improved thanks to Node Sheets merged with the ability to create "Node Families"

    NODE FAMILIES : node variables and overriding default OnEnter / OnTick / OnExit functions

    That Node-Tree / ACE hybrid approach i'm suggesting could be even pushed further thanks to the ability to inherit default On Node Enter/Tick/Exit functions and variables from "Custom Node Types" (or Node Families / Node Templates)

    We would be able to create "Node Templates" (or Node Family) implementing logic for their NodeEnter/NodeTick/NodeExit eventblocks, and then, in the inheriting Nodes, overriding AND/OR doing "super" call just like Object Family with Custom Actions are allowing us to do.

    Node Family could also have "instance variables" in their properties, so it would allow us to easily set an Avatar Frame, or that kind of stuff without needing to parse Data in token lists

    This way we could easily create a single Flowchart merging Dialogue + Quest + Cinematic capabilties at the same time.

    You would create a Dialogue Node Family, a Camera Node Family and a Quest Task Family and then create inheriting node depending on what you want to happen at what point of your Flowchart

    All Dialogues nodes would have a Avatar variable for example, while all Cinematic nodes would have TargetInstance/ZoomScale variables for example.

    All Dialogues nodes could do a super call of the common Dialogue Family "OnNodeEnter" logic (which behavior could change depending of the "node instance variable" values) BUT some of them could wait X second before, playing a specific sounds, creating a specific instance after etc.

    => It would allow the user to create its own Node Types (with variables and overridable/extendable logic) depending of the system they want to achieve

    Also we would be able to create our own Node Types to choose output based on Conditions as I was suggesting earlier, no need to include Vanilla "Random Output", "Choose First True Output" Node Types, the user would just be able to create it themself thanks to the "Are All Node Conditions True" Condition

  • I don't think most of the things suggested in this thread can be achieved currently. Well at least for almost all of them, the UX would be painful and it would feel very hacky.

    Regarding Node Enter/Tick/Exit using the exisiting Triggers, yes I agree it could be done that way, I thought about this and then thought about how to improve it. I find the worklow unpleasant, because it means creating manually a bunch of events with strings check everywhere, potential big else if statement, no easy way to jump from the Flowchart to the eventsheet etc.

    (Those are still great to have, but more for logic shared by several Nodes of a flowchart, not for Node-sepcific logic)

    IMO for that kind of tool, UX is equally important with functionnality. (Visualisation, Naviagation, QOL)

    The current workflow needed to achieve this is stressful and annoying, while it could be such a breeze if Flowcharts allowed to implement Game Logic.

    As someone who enjoyed Game Creator 2's Behavior module, I can safely say it is totally amazing and powerful to be able to merge Node Trees with Actions and Conditions with ease. (GameCreator2 Base Tool plugin adds some kind of "eventsheets", yet its additional paid modules adds extra way to use Actions and Conditions and it totally makes sense, they don't compete with each other they synergyze very well and the community is happy about it).

    I feel like it's a missed opportunity because Construct 3 has the best Actions and Conditions system out there, (and a huge number of Vanilla and 3rd Party ACES) but yet Unity (upcoming Muse Behavior) and its third party tools (GameCreator2) use their own ACE system in a better way.

    If using Flowchart we need to implement our own logic to create the whole backend for how flowcharts are executed, as the first example shows, how to go from one node to another, need to navigate through a bunch of tabs, manually implement several triggers via strings for each node in every flowcharts etc, potentially painfully contains visual data (avatar animation/text wave effects) and conditions data (why would this out node be chosen ?) in big token strings (that then need to be parsed and intepreted by ACE instead of just using ACE directly), then it means the only thing Flowcharts allows to do is linking array entries visually. (which is cool i admit !)

    Currently implementing Dialogues/Quest/StateMachine/BehaviorTrees with Flowcharts require exactly the same amount of work (tedious work) as it was before using an array (or JSON) where each entry would represent a node for example.

    The only difference is that the array entries aren't linked by arrows, but each array entries could store a token list of the ID of out Nodes.

    However the Array method would be much more flexible because it would allow us to link any Node to any other Node (multiple Ins support, possible to link back to previous nodes).

    To be honest, with the current set of features, i'm not sure why i would go with the Flowchart instead of the Arrays (or JSON). Because Array would also allow us to store any number of values ("unlimited column numbers", while Flowchart are just more retrictive and require to parse data contained in just a 3 values max - Name/Value/Tag, it means potential huge token list which are not always very pleasant to deal with).

    JSON would even allow us to nest and manipulate any amount of Data/arrays/Dictionaries for each nodes.

    So IMO right now Flowcharts try to compete with more flexible and powerful Data Plugins while they could become something new that synergize well with Eventsheets

    I just love the work you did so far on Flowcharts, very promising and exciting, and really hope the full potential will be exploited. So far nothing in its current implemention prevents it to become the best NodeTree/ACE hybrid tool out there, both it term of ergonomy and functionality, that could be used for Quest/Combo/Dialogues/StatesMachines/BehaviorTrees and enhancing the "instant and easy powerful visual scripting" features of C3 we love.

  • I don't agree with the "competing with event sheet" counter-argument besides the fact it would maybe involve more work for Scirra. It term of UX Node Sheets would be just better as it would just avoid the pain to manually create 3 Functions for every single node for every single flowchart we'll create, that would pollute actual eventsheets and already huge Function list for no reasons and that would require to endlessly jump between a big number of tabs. (How would we be able to jump from a Node to a Function and to a Function back to its Node ?)

    It's like saying Timelines is competing with Tweens and it's something we want to avoid while they are for different purpose (I think the comparaison between Timelines VS Tweens and Flowchart Node Sheets vs Eventsheets is fair, and there could be other counter example like Custom Actions vs Functions)

    Also it wouldn't solve the Node Conditions feature that I think is a must. Would be a shame to not take full advantages of all existing Conditions (Vanilla + 3rd party add-ons) for the visual scripting capabilities of such a system to help picking the right output on a Flowchart

    HOWEVER I guess an intermediate alternative would work to still keep most of the advantages of the Node Sheet suggestion :

    - automate the creation of the Node Enter / Node Update / Node Exit Functions on an desired Eventsheet (and automatically create a Group for each flowchart and a subgroup for each node).

    - There would be Eventsheet name and Group name properties for each Flowchart and Subgroup name property for each node that allow us to override the default places where those are created (Flowchart/Node names are the default names of the Groups, changing the properties automatically renames related groups because they would be effectively mapped)

    - Could also have a Project property "default Flowchart Eventsheet" where every Node related Functions are stored.

    - as the engine created the Node-related Eventsheet function and group itself, it could restrict the rules for them (showed by a slightly different logo or wording in the sheets), like don't let us call those Functions via regular function call action (at least by default), don't let us move Node Function blocks.

    - This way it wouldn't be a string spaghetti mess and the engine would be able to efficiently map the exact single place in eventsheets that is related to each node so it should be able to open the desired Eventsheet at the desired place directly when clicking on a "open this Nodes Event Group" (as a pop preferrabily, and/or at least the Node Group would itself have a button to open back the flowchart back to the right node position - but I think pop-up would be the best for ease of use in that case and we could still open them as any other tab if they're regular eventsheets)

    That being said, I think what I just described (automatically creating Node Event Groups containing premade Functions on regular eventsheets) could just be how the Node Sheet feature I was describing would work under the hood even if the C3 user couldn't tell because all of this is hidden and is presented in the most pleasant and user-friendly way. It would also be a better base to create other Node related features like Node Conditions in single place and to make it clear those events follow more restrictive rules

    Anyway there would still be the Node Conditions feature to solve and I can't see myself going to the pain of manually creating 3 functions for every single nodes and referencing them with strings, jumping from a tab to another without help etc.. That would be the actual spaghetti mess the Node Sheet feature would solve among other benefits. Also having Flowchart Data + Node conditions + Node Functions contained in a single asset (at least at the user level in project view) just seems to be the most elegant and pleasant way of managing things.

    (Writing this last post also makes me think it would be great if the Node sheet pop-up I described with the mockup on my previous post would in fact contain all the Node Events of current Flowchart in a single place (it just automatically opens to the relevant Node Event blocks but we would be able to scroll up/down to find the other Nodes to easily copy paste some ACE from one Node to an other)