The voting system is here to show what the community wants, knowing what a single user wants the most is irrelevant.

Allowing 1 feature request per user would be as pointless and ineffictive as allowing 1 bug report per user. (which i think you agree would be annoying given the fact you submit more than 50% of all bug reports)

That being said Nested Families don't need a "parallel feature" or to break backward compatibility. It involves a lot of rework under the hood but it's not incompatible with the existing Family features and it wouldn't break any project if it was done someday.

It wouldn't be confusing either if the family inheritance support was added some day. People who don't need it wouldn't see the difference and most people are actually confused it's not supported yet.

Ok I think I understand now. You want to create systems where some Nodes require to have multiple In Nodes like usual Shader Node Systems or Unreal Blueprints are working.

I dismissed that kind of nodal usecase because I thought anything that looks like nodal visual scripting would be best achieved via regular top-down eventsheets.

Do you have some ideas of cool systems it would allow us to build more easily than what we already had with existing features ? (given the limitations and the fact everything related to Nodes, and their in/out values would require long expressions and id or string checks ?)

Im mostly thinking about the Flowchart feature has a way to create branching logic for things such as Quests/Dialogs/TalentTrees/StateMachines/BehaviorTrees/Cinematics, where each node could implement custom logic, which have always very tedious to deal with in C3 in my experience, because it doesn't scale well (and the issue persist with current Flowchart features).

And in that kind of systems it makes no sense to limit the number of possible in or output nodes.

This is why I want so much Nodes supporting Node Conditions and NodeEnter/Tick/Exit to be able to implement specific logic for each node via "Flowchart Sheet" (by overriding/extending their Node Template Logic and with better Node instance variable support) without the pain of error-prone manual work with many steps for every nodes we create + no quick Visualisation/Navigation help. (The Flowsheet as pop-up suggestion would allow to see both side-to-side, especially if we are currently creating a bunch of Nodes while building a Dialog)

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.