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!

It's seams quite powerful. Some of these use cases you mentioned can still be done with vanilla c3 features but others are quite difficult or impossible to achieve.

Hey Rafael thanks a lot !

How is it integrated with the engine? Relying on this just to be broken after some construct's update is always a concern about plugins/behaviors in general

I don't see how any of those 3 new behaviors could break besides of a huge change where Construct Team would require everyone to rewrite all their addons from scratch

ADVANCED OBJECT SIGNALS & CUSTOM EXPRESSIONS

[Addon Pack]

I just released a new Addon Pack 🎉 GRAB IT HERE

A powerful ADDON PACK containing 3 new behaviors for Construct 3 :

• ADVANCED SIGNALS Behavior (Per-Instance Functions on steroid)
• CUSTOM EXPRESSIONS Behavior
• SIMPLE TRIGGER Behavior
• (all those behaviors also support polymorphism, making the Family feature way more powerful)
• Example/Documentation .c3p project

Those are the 3 addons I used in all my systems to create a highly modular and maintainable Roguelike. Thanks to this pack : you can create scalable systems easily, decouple your logic to avoid spaghetti code. It also makes the Family feature way more powerful thanks to the polymorphism support.

Above all, it allows you to "CREATE YOUR OWN BEHAVIORS" only using the eventsheet.

(In fact it's even more powerful than Behavior on some aspects, thanks to the polymorphism feature allowing each member of a Family to act differently)

There is so much use-case and advantages of being able to create Custom Signals, Triggers and Expressions (supporting polymorphism and multiple parameters) I wouldn't know where to start,

take a look at the addon pack page for more info !

ADVANCED SIGNALS & CUSTOM EXPRESSIONS

(I'm currently running a sale/bundle to grab my addon packs with a discount)

Yeah i agree we shouldn't waste time optimizing stuff that don't matter, I just had performance issues on a specific heavy task in my game but I managed to solve it by making my own Addons.

Anyway i went ahead and released a new Addon Pack that fix all the issues i've been mentionning for months and that i've been using extensively using in my project for about a year, it basically implements all the things i've been advocating for. I couldn't imagine making any project without those now :

ADVANCED SIGNALS & CUSTOM EXPRESSIONS

GRAB IT HERE

A powerful ADDON PACK containing 3 new behaviors for Construct 3

It contains :

• ADVANCED SIGNALS Behavior (Per-Instance Functions on steroid)
• CUSTOM EXPRESSIONS Behavior
• SIMPLE TRIGGER Behavior
• (all those behaviors also support polymorphism, making the Family feature way more powerful)
• Example/Documentation .c3p project

Those are the 3 addons I used in all my systems to create a highly modular and maintainable Roguelike. Thanks to this pack : you can create scalable systems easily, decouple your logic to avoid spaghetti code. It also makes the Family feature way more powerful thanks to the polymorphism support.

Above all, it allows you to "CREATE YOUR OWN BEHAVIORS" only using the eventsheet.

(In fact it's even more powerful than Behavior on some aspects, thanks to the polymorphism feature allowing each member of a Family to act differently)

There is so much use-case and advantages of being able to create Custom Signals, Triggers and Expressions (supporting polymorphism and multiple parameters)

it's hard to explain all use-cases and advantages, take a look at the addon pack page for more info !

ADVANCED SIGNALS & CUSTOM EXPRESSIONS

(currently running a sale/bundle to grab all my packs with a discount)

Regarding the performance issue I faced at some point calling a bunch of Advanced Signals, a good thing with this improved solution is that Custom Expressions and Custom Signals are 2 different behaviors, this way you just add the functionality you need on the relevant object and the "workload" is split, on top of being better UX-wise. (Calling an expression will only check the expressions triggers of the same behavior, same for signals, they are separated). There are also a few optimization tricks we can do that i explain in the last part of this post.

In most situations performance doesn't matter at all, I agree, we should only worry about them when we need to optimize very heavy stuff

In my project I wanted to optimize further because it happenned very often that many many entities were hit at the same times calling a bunch of signals (on hit received, on critical hit received, on death, on damage dealt, on critical damage dealt etc...), and I had many many different signals handled by a single behavior with many Triggers blocks so it was like :

(a bunch of entities + their damage dealer)

* (a lot of signal that are triggered at the same time)

* (a lot of existing signal handled by the same behavior)

* (a lot of listeners blocks for each Signal

= the exponential overhead i was talking about, and fixed

I think it's pretty rare to have that and i reckon Trigger Overhead wasn't the main bottleneck (it's just that I wanted to make sure that scenario was as optimized as possible, even if it would just save a few CPU% on those especially heavy frames), I mainly solved those heavy frames thanks to some other addons i'll probably release soon that weren't related to Trigger overhead I had.

My goal was being able to hit 100 entities at the same frame yet being able to launch a bunch of signals doing a bunch of extra checks and logic on many eventsheets for all of them without any noticeable perf drop and I managed to do it.

(Those behaviors are all as optimized as they can be, nothing is happening on tick - as opposed to Timers Behaviors - and they don't require to init anything fancy etc)

Here are a few tricks on how to enhance the performance if someone also has specific events in their game with very very intensive use of the Advanced Signal behavior on a single Object and needs to save every CPU% they can :

• Create several Advanced Signal on your object : "HitSignals", "MiscSignals" each handling just a subset of all your signals

• Use the SimpleTrigger variant for the most commonly used "Signals" or requiring the biggest number of eventblocks.

As ever with optimization, and i join Ashley on this : only do it after you actually runned into perf issue