New Flowcharts feature in r370

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.

My idea is similar to piranha's above. You don't implement EVERY node individually. You have reusable nodes where you implement the generic behavior once. In this example there are only 3 node behaviors, wait, random, and dialogue.

Overboy I see your point about node templates though! Having to recreate the dialogue nodes inside the flowchart editor every time is a pain. Two solutions, have the ability to duplicate a node, or when creating a node ask us if we want to "create a node from scratch" or "create a node from a template" and have another field for template name on the node.

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.

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.

piranha305

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.

It sounds like your brain is stuck on "nodes=behavior". It's just data. The output is an optional piece of data on the property, where instead of storing numbers or strings, it stores a reference to different node.

If you go up 8ish posts you'll see my screenshot that shows how dialogue nodes would flow into each other.

Overboy I'm not saying your points are completely invalid. I think using flowcharts to drive behavior using mini event sheets inside the flowchart editor is a valid suggestion. I just don't personally like that idea because I like to keep my behavior and my data separate. But flowcharts aren't even fully functional yet even just for data storage (ex: you can't create cycles so FSMs are impossible).

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.

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 + change the index where output are actual node links instead of variables.

I 100% agree. I feel there needs to be a node template system, where if the template node is updated then all the other "copies" update automatically, at least for # of outputs, output index, and their names.

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)

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.