1. NODE SHEETS (Node Conditions + On Enter / On Update / On Exit)

Here is a mockup and a refinement of the Node Sheet and Node Conditions features I was suggesting

Everything is explained on the mockup

Basically each Node would be able to open its own "Node Sheet" as a Pop-up (which data is embed in the Flowchart asset).

Node Sheets are restrictive eventsheets with 4 premade blocks :

Conditions

• they are also displayed directly on the Node is the flowchart
• could be checked all at once thanks to a "Are Node {MyNode} conditions True"
• would be used by special Node Types like Sequence/Choice/Random to automatically pick an output based on various rules and conditions as explained in part 4.

On Node Enter

On Node Update ("every tick" runiing when this Node is currently playing)

On Node Exit

Other suggestions in addition to what have been said before :

2. Nodes should be able to have multiple different "Ins" Node

It is very useful for all kind of branching system where a node can be reached from multiple places (like Dialogue but really any branching system)

However it might be an issue with how it works right now because the Node Name and Node Value are in fact stored on the "parent In Node". So it would mean the same Node would have a different Name and Value depending on the parent In Node.

Not sure if it would be that much an issue as it could make sense to have different name and values for the same node in the context of the Dialog System.

However there should probably be a boolean option on a Node to guarantee its Name and Values would be the same whatever its Parent In Node is. Like a "Override Name and Value" boolean that gray out those fields on all the parent In node output corresponding to this node and that let you choose those values on the Node itself.

3. Allow flowcharts to have "local variables"

(in fact something similar to both local variables and instance variables at the same time as we should have ACE to be able to get/set them on the Flowchart Controller with dropdownlist depending on the chosen Flowchart. If it's too complicated then just a set/get Flowchart variable by name would be good enough).

Those local variables would allow use to do many things including passing the UID of an instance and retrieving it in the Node Sheets. Would be really useful to use Flowcharts as State Machines or Behavior Trees for entities for example.

It would also allow us to change the behavior of specific Flowchart instance dynamically at runtime by changing a local variable. For example setting a TargetUID local variable or changing the boolean of a Flowchart from a regular Eventsheet

4. NODE TYPES

• There could also be different kind of nodes depending on how to choose the output.
• The current default would be the "Manual" Node.
• But there would also be other kind of Nodes such as "Choose" Node, that automatically finds the first Output Node which "Node Conditions" are true and play it immediatly (and/or waiting for a Choose Node action to be called, but it's processed automatically on called).
• There could be other cool stuff to think about regarding Node Types and Node conditions to automate some stuff.
• Maybe also a "Sequence" Node ? that would execute each output node and it's branching in order until it reaches an end and then do the same for the next output node.
• Maybe a "Random" Node, that picks a random node output which conditions are true
• (It could be a Node dropdown property "Output Choose Methode" to choose between Manual/Random etc instead of actual different node types)

5. BETTER NODE CONNECTIONS/ARROW

As it looks like Nodes wille be able to link back to previous Nodes, i think it's very important that the arrows still looks clean, otherwise it will quickly look like a spaghetti mess. Maybe letting the user choose the shape of the arrow by creating and moving an intermediate point (mini node doing nothing) and making sure it draws a clean softened right-angled corner. Something similar to this :

This is a very exciting feature, thank you for the hard work on this.

IMO the biggest issue right now is that it still requires us to create a tedious/complex backend using Eventsheets to actually use this new data formats.

It requires us to create a bunch of Functions, use a lot of different ACE etc...

Usually branching tools kinda automates some stuff for you

Also we need to painfully handle infinite else if statements on triggers to do some special logic on each Nodes (playing sounds/displaying an avatar etc...), everything being a string and it's a spaghetti mess between eventsheet and flowcharts

By coincidence, I very recently wrote a long forum posts explaining my thoughts about it with a detailed benchmark of other tools merging Action/Conditions with Node Trees.

construct.net/en/forum/construct-3/general-discussion-7/ace-based-node-trees-creating-179570

Especially Unity's 3rd Party tool suite called Game Creator 2 and not-yet-announced official Unity Tool called Muse Behavior.

The excellent thing with the implementation you chose is that it's very versatile so it would be possible for Scirra to build very cool stuff/options to just make some of it works "immediatly" without requiring us to create all the complex backend (as the current example is doing).

I know both the release note and this post present this new feature as a data-oriented feature but I do think the true potentail of that kind of feature would be achieved if it also allowed us to implement game-logic per node.

ALLOW TO ADD A EMBED FUNCTION FOR EACH NODE

• Basically each node would have a "Add Node Function" or "Open Node Function" button. (it can only have 1)
• A node function is a "mini-eventsheet" directly embed in the Flowchart asset and that is executed as soon as this node is reached in the flowchart. In fact it's a Function-like single eventblock with its children. It can have any number of actions/Condtions/Subevents, but can't have any parameters. Under the hood it would be exactly the same implementation as a function except it can't be called via "call Function" action, it's only automatically called when the node is reached.
• When we click "open node function" it would open a pop-up that looks like a more restrictive mini-eventsheet only displaying the Node Function.

It would allow us to do crazy stuff with ease.

Like playing a particular sound when the node is reached/setting a global variable or anything useful for any Quest/Dynamic Cutscenes/Dialogue/AI/Movement system.

And it would avoid the need to handle the cases with Triggers events placed on Eventsheets that would create dependancies everywhere between actual Eventsheets and Flowcharts using Triggers that would ends up being a mess for big projects (Triggers are also useful but really embedding logic per Node would be amazing).

NODE CONDITIONS (And node Types)

this suggestion is built upon the previous Node Function suggestion

• All conditions that are directly under the Node Function (so not in its own subevent but directly at the root) are the "Node conditions".
• They could be the only ACE of the related Node Function that are also displayed directly in the flowchart. So it's more readable for state machines or conditional flowcharts.
• There would be a condition to check if the current Node Condition are true (so no need to handle every single cases manually in Eventsheets), it's just done "automatically" by default.
• There could also be different kind of nodes depending on how to choose the output.
• The current default would be the "Manual" Node.
• But there would also be other kind of Nodes such as "Choose" Node, that automatically finds the first Output Node which "Node Conditions" are true and play it immediatly.
• There could be other cool stuff to think about regarding Node Types and Node conditions to automate some stuff.
• Maybe also a "Sequence" Node ? that would execute each output node and it's branching in order until it reaches an end and then do the same for the next output node.

Even if it's NOT what i'm describing here is a visual representation of the Quests Module of Game Creator 2

EDIT : Node Conditions and On Node Enter should be 2 seperate Blocks on a "Node Sheet", along side with On Node Tick and On Node Exit, everything is detailed on a mockup on my next post here : construct.net/en/forum/construct-3/general-discussion-7/new-flowcharts-feature-r370-179833/page-2

"Infinite loops" (looping Flowcharts) make sense for all kind of State Machines/FSM that could be used for AI Behaviors, Game States, and UI state. (but also for creating complex Platformer/Movement behavior or that kind of stuff)

Great to know backlinking nodes and referencing flowcharts directly are considered for future updates !

Here are a few screenshot of a cool Node-tree tools using Actions and Conditions called Game Creator 2 (and its module Behaviors), I think those would be inspiring for C3 Flowcharts

Would it be possible to create a special "Linked Flowchart" Node ? with a clickable button to open the referenced other flowchart.

Currently, the way we have to do it is creating a custom logic with ACE. Everything is string based and it's difficult to navigate from one flowhcart to an other within the editor, must go to the bottom of project view everytime, looking for the right flowchart etc. Here is how it is in the example.

Would be cool if we could actually reference actual flowcharts directly in a new Node Type.

Referenced flowcharts could also have a list of all the backlinks of other flowcharts referencing them.

So we could easily naviguate from one flowchart to an other (from referencing to referenced AND from referenced to referencing), it would enhance the UX a bunch.

HOWEVER : We should still be able to change those new "flowcharts output" by name/string at runtime thanks to new ACE for more flexibility, in addition to new dropdown list ACE

CONSTRUCT IMPLEMENTATION SUGGESTION (Wip)

(I'll edit this post to add C3 Mockups later)

I beg Construct Team to deeply look into those tools if they ever consider adding such a Node-Tree feature :

• 1. Game Creator 2 and its modules (Unity 3rd party)
• 2. Muse Behavior (Unity official)
• 3. Dialogic 2 (Godot 3rd party)

All potential use-case should be taken into consideration (from State Machine/BehaviorTree to Utility AI and Dialogue Systems), it should be versatile enough to be able to do everything.

EDIT I refined this suggestion in this post based on the Flowchart feature C3 Team just released

construct.net/en/forum/construct-3/general-discussion-7/new-flowcharts-feature-r370-179833/page-2

EDIT : Flowchart feature was released in r370 by Construct Team.

I detailed here the suggestions about how it could be enhanced to become a powerful addition to handle Game Logic to create Dialogues / Quests / Combos / States Machines and Behavior Trees.

construct.net/en/forum/construct-3/general-discussion-7/new-flowcharts-feature-r370-179833/page-2

I created this thread to discuss about a "ACE-Based Node Tree" suggestion that would allow us to decuplate the visual scriptings capabilities of Construct. (to create State Machines/Behavior Trees/Dialogues/Quests)

First post is the explanation of the full potential of Node Tree in C3 and a benchmark of the best implementations of "ACE-Based Node Trees" in the game engine market, second post will be more about how this feature could be implemented in the context of C3 (still didn't have time to write it and do quick mockups)

TLDR :

• Eventsheets-based visual scripting is awesome
• [Top-to-bottom visual scripting like C3, using Actions, Conditions and Expression (ACE), executing logic contained in Plugins and Behaviors under the hood]
• Node-based visual scripting is bad
• [by that I mean Blueprint-like nodal system which quicly become very messy]
• NodeTrees built upon Eventsheet is INCREDIBLE.

Yesterday, I randomly stumbled upon a <100 views hidden Video of an upcoming Unity feature called “Muse Behaviors” : it’s basically a mix of something similar to the Actions & Conditions we’re using in Construct 3 with a Node Tree. To be honest it's mindblowing, and it looks like they plan to use Actions/Conditions for more systems (maybe Unity Eventsheets ?)

When i saw this video, it gave me the urge to suggest something i’ve been thinking about from quite a long time : “ACE-Based Node Tree” or “Node Tree Eventsheets” in Construct. It would probably require a huge amount of work but I think this is a perfect match for Construct 3, which would be the best engine on the market to integrate that kind of stuff thanks to his amazing Eventsheets and all the Action/Condition/Expression features that exist thanks to all official and 3rd party plugins and behavior.

If done right, it would allow us to create all kind of extremely powerful systems :

• Behavior Trees
• States Machines
• (Behavior Tree and State Machine, other kind of Trees could be useful not only for AI but also to create the global flow of our Game, like a Game Manager but also advanced user interface system)
• Utility AI
• G.O.A.P
• Dialogue System
• Quest System
• And even more : Combat System ?

Game Creator 2 and its modules

The reason I’ve been thinking about that is because i’ve been playing for a few years with a wonderful 3rd party Unity tool suite called Game Creator 2. I’m 100% sure Game Creator 2 is inspired by C3, and then the Unity Team was inspired by Game Creator 2 and its innovative tools to create their own “Muse Behaviors” they’re about to announce.

I’m talking about those tools because they help to understand the full potential of Node-Tree using ACES and it’s the closest possible implementation that could be done for Construct 3.

Game Creator 2 for Unity is a suite including a base tool and a bunch of modules.

The Game Creator 2 basically implements a ACE (Action/Condition/Expression) system very similar to how Construct 3 works, but in the Unity context.

With base GC2 you can create your "eventsheets" directly on your objects using the Unity Inspector (not as cool and easy to use as C3's global eventsheets, but still the best visual scripting system ever created for Unity - ugh i hate Unreal Blueprint-like nodal systems that most softwares implement for game-logic)

However GC2 additional modules also allow you to create logic as seperated assets that are composed by "Tasks" (= Mini Eventsheet blocks composed by Actions/Conditions), there are 2 main categories of "Task Trees" :

• GC2 TASK TREES (used in Behavior Module)
• GC2 TASK HIERARCHIES (far more pleasant to use for stuff like Dialogues/Quests/Combo)

1. GC2 TASK TREES: BEHAVIORS MODULE

(State Machine, Behavior Tree, Utility AI and G.O.A.P)

GC2 built Node-Tree systems on top of Actions, Conditions and Expressions to achieve the 4 Main type of AI systems used in the Game Industry. (they can in fact be used in far most situation besides just AI)

Those are basically like "Trees of Eventsheets" made of "mini-Eventsheets"

Official GC2 Behavior documentation: (worth a read)

Showcase video: (go to 13min10 to this it in action even if the explanations before are really interesting)

If you want to understand the incredible potential of those 4 Node Tree AI system, i also totally recommend to watch this wonderful Gamer Maker’s Toolkit video explaining how each of those type of AI, and especially Utility AI, were used to create one of the most innovative and fun gave ever : The SIMS. Awesomesauce.

Utility AI : Basically you define the "needs" of a character and it automatically picks the correct goal based on what should be prioritized. It’s used very cleverly and at different scale in the Sims to handle the behavior of each character but also for more abstract concept such as neighborhood in the Sims, to create powerful story machines constantly creating emerging gameplay and situations.

2. GC2 TASK HIERARCHIES :

Dialogues, Quests, Combo etc...

GC2 use a different king of "Task Tree" for its Dialogue/Quest/Combat Combo modules, they looks more like a Hierarchy of "mini eventsheets" (=Tasks) that is far more readable and useable for that kind of purpose.

It's also the kind of system used by Dialogic 2 for Godot (the last cool visual scripting tool I wanted to mention in this benchmark)

It's basically like an "Super-Eventsheets" made of "mini-Eventsheets"

Wow amazing ! Thank you 🙏

1. Does it also includes Object Property support for Behavior ? I found out that anytime an Addon could be a Behavior, it's better to make it a behavior rather than a Plugin as it allows for better Modularity and ends with easier events (no need to act on a bunch of seperate objects and to do picking). I think it's especially true for 3rd party addons that are meant to extend the functionnalities of Vanilla feature, they must work on top of any Vanilla World Plugin. construct23.ideas.aha.io/ideas/C23-I-464

2. Thanks ! that's good to know, i'll keep that in mind if i ever face a similar issue and will report it as a bug.

I suppose if LoadWebGLTexture() for AnimationFrames was wrong then maybe GetCachedWebGLTexture() also requires some fix ?

3. I thought about it again and realized it was more complex than i thought, updated the suggestion to reflect those extra thoughts : construct23.ideas.aha.io/ideas/C23-I-469

Some methods might be difficult to implement but other are probably a matter of exposing existing stuff and would help for a lot of usecases not even related to UI (Getting Parent/Children, Destroying Instance etc.)

Other issues i faced (workarounds kinda exist for them - in some sitations only - but it feels like they're unnecesseraly tedious)

5. It would be probably good to add a project.GetInstanceByUID(uid) or a layout.GetInstanceByUID(uid) depending on where it makes sense

6. There is no way to get the Layouts of the Project, as explained in Skymen's article, a project.GetAllLayouts() would be useful to have.

Above all, a project.GetCurrentLayout() would be useful to then get a specific layer then create a world instance on it, as Layout allows to access all Layers. (layout.GetLayerByName() would be a nice QOL but very easy to workaround with a loop) There is already a CreateWorldInstance(layer) method but it's sometimes tedious to use without handy ways to pick a specific layer.

Hi ! this topic aims to be a constructive discussion between Addondevs and Scirra about how the exposed Editor SDK could be improved to allow us to create simple tools working in editor.

As Scirra is using the "secret obfuscated Editor SDK" under the hood for all Vanilla Plugins and Behaviors, the "exposed Editor SDK" was never dogfooded in any way and there are many many holes that makes it almost impossible to use for anything relevant. This is why most addondev just abandon the Editor part of their addon and everthing can only happen at runtime. But it is an issue as many cool Plugins/Behaviors that could be made would only be useable if the user was able to set them up and preview some stuff happening at edit-time.

Example usecases :

• UI System
• Addons displaying textures from other Plugins (as Particles and 3DShapes are doing)
• Utility Plugins to create/place instances in bulk in the Editor

Tagging skymen and Mikal as they're the 2 other devs I know that tried a lot to deal with the Editor SDK before. Skymen wrote an amazing article about this topic about this btw : construct.net/en/blogs/skymen-13/flexbox-weird-characters-1590

Even if the best would be to have access to a much bigger part of the actual Editor SDK API, the goal of this thread is to discuss about the main holes in the exposed SDK and try to find reasonnable and clever ways to makes things much better with the smaller amount of changes and new methods, as I understand Scirra wants to keep most of the Editor SDK obfuscated.

I spent an entire week trying everything I could thanks to skymen's help to make simple stuff happening in Editor with custom behaviors/plugins and just faced walls after walls preventing me to do anything relevant, no matter the tricks I used, even after trying every possible way of doing stuff. Here is a few issues I faced.

• 1. Object property : Plugins can select other ObjectTypes as one of their property. It's very useful and used by Particles and 3DShape to be able to do stuff based on other objects. However at editime, those properties returns the SID of the ObjectClass but there is not a single way to get an ObjectClass by its SID using the Editor SDK.

Solution : Add a GetObjectClassBySID(SID) method to the IProjectClass

(could be cool to also add Object property support for Behavior btw)

• 2. IRenderer.SetTexture() only works with IWebGLTexture class but "not secret WebGLTexture class" which is a big issue because it means there is no way to make anything work both with official Plugins/Behaviors and 3rd party addons. Indeed LoadWebGLTexture() method of AnimationFrames returns a secret SDK instance (WebGLTexture) that can't be used using the exposed SetTexture() method. It's as if the Vanilla Addons and the Custom Addons were their own island that can't interact with each other, making it pointless

Solution : Different possiblities : make LoadWebGLTexture() returns an IWebGLTexture instance instead, also make functions like SetTexture() work both with exposed IWebGLTexture and WebGLTexture

General Thought : Make sure any method that exists in the exposed SDK work both for Vanilla addons and Custom addons

• 3. No way to do anything related to Hierarchy feature, while it would allow us to create AutoLayouting behaviors, utility tools and full UI system : I describe every missing stuff extensively in this suggestion : construct23.ideas.aha.io/ideas/C23-I-469

• 4. Missing GetName() : It is possible to GetAnimations() from an ObjectType, but not a single way to get their animation name, so it means it's impossible to know for sure we access the animation we wanted to access.Ideally everything that has a name should have a GetName() property

Solution : Add a GetName() method to the IAnimation Class (and any other class that should have one one but has not, same for all the basic stuff that would be useful and that isn't subject to change)

Those are just a few roadblocks I faced while trying to do simple things using the Editor SDK. As there was never detailed dogfooding or detailed feedbacks from addondev on this, I hope a discussion could be a start to solve those annoying roadblocks in reasonable ways to improve the Editor Addon SDK so we can use it to make cool stuff.

Looping back to the original point of the post, I'm still confused why "OnTween" finished seemingly causes no reduction in fps, while "onTimer" does. Seems like timers are.... outdated? Tweens are nice and fast for all they do.

It's because Fake Triggers which is used by the "On Timer" in the Timer Behavior actually check if they're true everytick as opposed to True Triggers So if you have a bunch of objects checking a bunch of On Timers it can be heavy.

True Trigger on the other hand don't do anything every tick, they're just triggered when they're called (with a little overhead)

Both approach have their own trade-offs as often in programming. Even if I admit I did tricks to avoid many "On Timer" Fake Triggers in my project

(Ruskul, I think the comment of tunderrunz was about official behaviors not the Advanced Signals pack I made)

Overboy

Sorry If I missed the answer elsewhere, but I wanted to ask about performance of your tools.

For the custom signals and the like, do they perform better than c3 built in functions?

I have a project where I need to call alot of functions, those functions call other functions, etc... Its in loops in order to achieve object picking,.

I have alot of object that have large lists of buffs, effects, etc, that are all being passed around. And alot of those effects do something every tick. How is the comparable performance of your plugin compared to built in custom actions and functions?

They don't perform better than built-in Function.

Please check my posts in your thread about Timers and True Triggers for all the details ! In my post where I link my Addon Pack, I explain the only example in my big project where the performance did matter and the tricks you can do to solve it (using multiple Advanced Signals behavior to split the workload or using the Simple Trigger behavior also included in the pack for the most commonly used Signals). As ever with optimization, only do it when it matters.

There is not a single way to get the IObjectInstance from IBehaviorInstanceBase or a IBehaviorInstance in the Editor API of Addon SDK

Please could you add a GetObjectInstanceBase()

Because we can't do anything thanks to behavior in Editor as behavior don't let us do anything - only ObjectInstances have useful methods

I'm currently stuck on an urgent work because of this.

Edit : I also posted a dedicated request : construct23.ideas.aha.io/ideas/C23-I-468

If you find some time to add it for this week beta it would save me ! 😅

I just pushed Updates to 3 of my addon packs !

There is currently a sale/bundle to grab all of them with a discount on itch.io

overboy.itch.io/construct-3-object-signals-custom-expressions

ADVANCED SIGNALS & CUSTOM EXPRESSIONS : V1.2 Released

• Added AllParams() expressions to Signals and Custom Expressions
• It allows you to return all the parameters of the current Signal/Expression as a string (seperated by '|')
• It can be useful for different purpose, for example, it provides an easy way to pass the parameters of the Current Signal to additional Signals you'd like to call

UIDToAnything : V1.3 Released

• Added UIDTo.LayerName(UID) and UIDTo.LayerNumber(UID) expressions
• Fixed a few typos
• Improved the naming of some ACEs to be more consistent

DATA+ : Minor Update

• Pushed a minor update to move JSON+ Behavior to the "General" category (instead of "Other") to improve consistency with Array and Dictionary behaviors of the addon pack !

Thanks to TackerTacker and fedca for their feedbacks and suggestions!