As I said I never used or suggested anything related to the too limited On Signal feature because they have no parameters + no way to pass instance or SOL (+ perf can get exponentially worse and the UX is pretty bad). Same for all the other convos we had about this during the past 10 months 🤷‍♂️

That feature doesn't help at all with the issue I'm describing and the performance gets exponentially worse the more you use it.

You always told us how much cooler and performant Builtin Functions were versus True Triggers (x3.5 perf i think ?), so the perf diff is even bigger if you compare builtin Functions versus tag-based true Triggers with increasingly bigger number of triggers and signals, because it will trigger every single Signal block even if it's not the same Signal string you just called.

There are your own blog posts explaining this :

- construct.net/en/blogs/construct-official-blog-1/construct-3s-new-redesigned-1059

- construct.net/en/blogs/construct-official-blog-1/constructs-new-functions-1060

Here is your own graphic showing the difference between a between function and a old tag-based functions.

(+ note that the difference would be even bigger with tag-based True Triggers as old functions were already optimized via the deprecated Fast Trigger feature AFAIK !)

I still don't understand why asking for perf benchmark as you're well aware of this and you already did it yourself

The suggestion I made for "Better Signals" via a Emit Signal option for Functions/Custom Actions, allowing to add extra Listeners Blocks would solve all the issues mentionned (and even more as it could also feature an execution order option) :

construct.net/en/forum/construct-3/general-discussion-7/custom-actionsfunctions-175063

By default you would create a Function or a Custom Actions (nice UX and optimal perf for the "First Listener Block" at least), and if latter you realize that you'd like an additional listener blocks for it (for decoupling/organisation or because you want to apply different logic depending on the Layout or because you want to apply different logic depending on active groups/eventsheets as explained by me and other in different examples in this thread), you would just tick the "Emit Signal" boolean, and you could now create as many extra Listeners Blocks via the usual Object Conditions creation worklow. (that could probably be a bit more efficient than existing True Triggers for reasons mentionned on my first posts)

Some advantages of building Better Signals on top of Functions/Custom Actions instead of current On Signal Event :

Perf advantages : Built-in function perf + no need to trigger every signal every time + no need to do shenanigans to pass parameters + no need to do picking for each listeners

UX advantage : no typo due to strings, automatic bulk rename, parameters are automatically accessible as local variables in each listener block, Find all references support

+ if JS Events and scripting interfaces for calling Custom Actions are added, it would also work for this feature.

Other potential advantages from this suggestion : listeners blocks could be added via the same workflow as regular Conditions (the same way custom actions calls are added via regular Action workflow), execution order feature

The thing is that very few people are facing this performance issue because again : the feature just doesn't exist at all in Vanilla Construct : this is the main issue. We just can't create Per Instance Signals supporting multiple listener blocks (and multiple parameters) to be able to decouple stuff for example (but it's not just an organization issue, it's just impossible to develop a modular Roguelike without those for example). This is the problem number 1.

I think a lot of users are happy that they can have several different places in their eventsheet to apply logic using vanilla Triggers. For example, i think it's common that people have multiple "On Main Player Created" blocks in their big project to initialize stuff on their Player (one for UI, one for Visual, one for Gameplay stuff, or even one for "Arena Layout" that differs for the one of "Dungeon Layout"). But we just can't create our own Triggers like that for stuff like "On Main Player Hit".

The same way people are happy to have a bunch of "On Start Layout" events in the same project, could you imagine making a big project were you would need to put everything you want to happen On start of Layout but in a single place in the eventsheets, no matter what is the current Layout (so we would need to make a huge else if statement in a single place), no matter what object you want to act on, the game feature that is relevant ?

I created various solutions myself by writing Addons to be able to do this. Including a Tag-based versatile Self Function behavior solution and later a "Create a new Real Trigger each time i need a new Signal".

So I don't get the point to prove the performance issue for a feature that just doesn't exist at all in C3 to prove it is worth developping it ? Again we just can't do that in Vanilla C3.

I totally understand the priority stuff, and i don't care if the feature isn't developped any time soon or even isn't developped at all, I think a lot of other stuff are 10X more important and urgent to have in the engine such as some stuff i listed in this post from an other thread : construct.net/en/forum/construct-3/general-discussion-7/good-time-construct-great-178657/page-6

The issue is that it happens very often that the answers I get from reports totally ignore the main points I'm raising. There is zero acknowledgment about the missing spot, just oversimplification of the issue and potential solutions i report and some suspicions i'm doing stupid stuff on my project that makes it slow or i'm trying to achieve things that are useless to do. I get why it could be the first answer that is provided to challenge the idea/the issue : it's totally fine, but i just don't understand why after maybe 25 detailed messages over 10 months we're still stuck on the comprehension/acknowledgement of the important thing ?

And i'm still feeling this about that issue C3 has that :

1. We can't create our own Triggers in C3. (Working per instance/SOL and supporting multiple listeners blocks).

2. Even after spending weeks developing my own solutions for this there are either performance issue (tag-based Self Function) or the process is just too hacky and cumbersome (need to create Behaviors and Real Triggers via SDK for every single Signals I want for every project i make)

> Yes the performance does matter a lot.

Do you have performance benchmarks that demonstrate the performance overhead of "On signal" is too much for reasonable use cases? I think it would be surprising - why would you need something like thousands of signals per frame? If you are doing something like that wouldn't another feature like functions be a better approach anyway?

This is exactly what i'm suggesting here and what i've been suggesting for several months with the "Listener Blocks" feature built on top of Custom Actions and Functions, i never used or even suggested to enhance the current "on signal" feature for many reasons i explained. (no parameters, no way to pass an instance or SOL, bad perf, bad UX)

I never needed thousands of signals per frame, I had actual performance issue on my real world project using the various methods i mentionned until I opted for my hacky "create a Real Trigger via Addon SDK" anytime I want a new instance Signal. It wasn't even triggering thousands of signal, just some specific events of my game like when 10ish entities were hit at the same frame was freezing my game. (Because of the exponential performance overhead of tag-based Real Triggers I explained in my first posts of this thread) I didn't have stable 60 FPS until many many optimization tricks I did.

I find my own solutions for this after weeks if not months of work extanding the engine in multiple ways using both JS scripting and Addon SDK.

I already spend several days explaining this issue, a bunch of example usecases and different suggestion that could fix it on various occasions.

From your answers, i have the feeling you still didn't understand what is the issue (the performance is only a part of the problem - a big one - but also we just can't create at all Signals per instance supporting multiple listener blocks with the current features of the engine, i think i already reported that 15 times), and what are the solutions i'm suggesting (nothing related to current limited and not perfromant signal feature)

I have the feeling any benchmark i could provide won't change anything, as there here is no recognition of the problem in the first place, so i'll probably just avoid overworking even more on this.

I added a suggestion for Functions and Custom Actions JS events support ! construct23.ideas.aha.io/ideas/C23-I-456

I detailed the suggestion extensively in this post :

construct.net/en/forum/construct-3/general-discussion-7/custom-actionsfunctions-175063

The idea behind this is that C3 would be able to optimize those "Signal Triggers" almost as good as the built-in Function/Custom Actions.

No need to check every single Signal Trigger that exists in the project to check if the "tag" is the same, just the ones mapped to the right Custom Action or Functions. (It would still need to check if the Trigger Eventsheet and Group is active though which is why I said "almost as performant")

There is probably even better way to achieve this UX wise, but I tried to suggest something that could be built on top of existing stuff instead of creating a brand new customAction-style Signal feature. (Which should work per instance). Creating a brand new feature for this could be cool though

Yes the performance does matter a lot.

And it's not even just a performance issue, as I said it's just impossible to create signals with parameters or passing instances sélection or UID.

I first opted for a versatile tag-based Self Function's behaviors to be able to achieve the feature I wanted but it was not performant enough because of the "everything is triggered everytime I call any Self Function". As you said Triggers are not very performant in C3, it can get bad pretty fast.

So now the way I do it is for each Signal I want, I create a specific Real Trigger via the Addon SDK. So I need to manually add a new Trigger Condition such "On Hit Received" to my "Entity" Behavior everytime I need a Signal. It is not modular at all, all the most used Family in my project now have their own custom behaviors with a bunch of hardcoded Real Triggers.

I don't fire any signal every tick, but some stuff in my game need to happen very often : such as Entity : "On hit Received", "On damage dealt".

The way I'm doing it now solved all my perf issue but it feels weird I need to create new Trigger condition via Addon SDK everytime. Also it took me a while to find this hacks way of doing things after rewriting my whole logic from scratch a bunch of times

But if you have 20 different signals in your game with 2 different listener (very low number for a big project), it would trigger 40 places in the Eventsheet each time you call any trigger because of the limitation I explained. Not performant at all.

Also the issue I pointed out is that you can't pass any parameters, so you can't do anything per instance as Custom Actions are doing but with this signals, you can't pass a UID or the current SOL of that Object type.

This is too limited and not performant at all. I wrote very detailed posts about that multiple time in the past, current On Signals doesn't solve the issue at all

> Ashley do you think there is a chance that one day the Addon SDK would supports new "function-like True Triggers" for Timers or any plugin/behavior that wants to implement some kind of "Self-Functions" ?

The triggers system is not designed to be used for performance-sensitive cases. Basically it's quite slow, but for things like input events, that doesn't matter. The built-in functions are specifically designed to be used in performance-sensitive cases, but they are deeply integrated in to the event engine and so aren't easily extendable. So I'd say if you really need maximum performance, use the built-in functions, but as I was saying before, probably the vast majority of cases don't need extreme performance, so some other solution is probably usually fine anyway.

Yeah I know existing "Real Trigger" aren't performant enough to handle Trigger events such as On Timer X or On Self Function X where X is a specific tag as it would trigger all the events for every tag every time any timer or any self function is called just to check in each event block if they match the right tag.

This is why I wonder if it wouldn't be cool to bring the power/efficency of Functions/Custom Actions to the Addon SDK as a new Trigger type in addition to Real Trigger and Fake Trigger let's call them "Signal Trigger".

I know it wouldn't work exactly as built-in Function as they would need to be on an active group/Eventsheet but as they would not allow any expression to be their "name" or "tag", C3 could map them more efficiently and so they would be more efficient than existing Real Triggers .

It would only need to restrict the "Signal Trigger condition" tag to a user-generated enums/dropdown list (corresponding to the Timer Tags for example, or the Self Function Names).

(But there could be both a expression based ("by name") and a drop-down variant for the related action that call those signals)

It would be for a different purpose than Real Triggers and built in Functions/Custom Actions.

And it would solve the longstanding issue that there is no way to create Performant Signals supporting multiple parameters that can trigger multiple event blocks efficiently. Which is a shame in a Eventsheet based game engine.

But anyway regarding Better Signals this would probably be a better solution : construct23.ideas.aha.io/ideas/C23-I-165

The big issue with True Triggers is that AFAIK, it would trigger all the "on timer" events of a behavior each time any timer is finished (can end up being a big overhead if you use the same behavior for many timers and triggers), only to check which trigger event was the one corresponding to the timer that just ended.

For example if you have "attack1cooldown", "attack2cooldown", "attack3cooldown" and so on.

When any timer is finished it would have the performance overhead for every single "On timer" Trigger you have for this behavior even if only one is in fact corresponding to the timer tag you want.

This is a big limitation of c3, there is no efficient way for plugins and behaviors to do that kind of effective true triggers condition based on "tags" or "function names". It scales very poorly in term of performance as the number of different "tags" you're using grows. We have built-in functions when we want to do that kind of stuff in Eventsheet but sadly there is nothing that allows to do that in the Addon SDK right now. This is probably why fake triggers are a thing.

Ashley do you think there is a chance that one day the Addon SDK would supports new "function-like True Triggers" for Timers or any plugin/behavior that wants to implement some kind of "Self-Functions" ? For example if the issue is that tags or names are strings that can be based on expression, making it impossible for C3 engine to map the right triggers for the right calls efficiently based on a tag, couldn't c3 users create our own tags enums/drop-down list for those new "Functions-like True Triggers based on Tags" ? (Instead of letting the user put any expression in there, this way C3 engine know for sure what to trigger in a performant way like built in Function)

I suppose the drop-down/enums choice would only need to be done on the Trigger event but there could be both a drop-down and a "by name" variant for their related Call action event.

Not only those potential Addon SDK "function Trigger" would be useful for Timers but it would also allow to implement a behavior-based "Better Signals"/performant Self Functions supporting multiple params similar to this request : construct23.ideas.aha.io/ideas/C23-I-165

I noticed a spike in traffic and sales for Data+ and UIDToAnything, it looks like it came from here, thanks for recommending my plugins, I'm glad they're useful !

As it seems there is a great interest for them currently I just set up a sale/bundle in case anyone wants to grab them !

overboy.itch.io/construct-3-json-plus

overboy.itch.io/construct-3-uid-to-anything

I agree scaling a game in C3 can be very hard, but to give credits to Scirra, i think there was tremendous progress made regarding that aspect during the past few years.

(Templates, Dynamic Layers, Performance improvements, Sublayers, Find Results, Hierarchy improvements just to name a few game-changers stuff that were released)

I've been working on my biggest project yet for a bit more than a year with C3, and in my experience, using both JS scripting and Addon SDK was unavoidable for a bunch of different reasons due to current Eventsheet limitations. I would advise anyone wanting to make full Steam games to learn using JS in C3 at some point.

Still, I feel like the community is in right to ask for missing features as C3 is a sub-based evolving software (which is awesome btw!), and we're the actual users of the engine who know the shortcomings based on years of experience we accumulated trying every workaround (including weird eventsheet tricks, behavior hacks, JS scripting, HTML/CSS, and Addon SDK).

However we need to provide actionnable feedback and fill detailed suggestion on the dedicated platform. And what we ask should make sense in the context of C3 and its own paradigms

The annoying thing is that sometimes it feels like features suggestions represent a tiny part of the features that are released, but at the same time sometimes i'm glad when Scirra takes cool initiative pushing great stuff no one directly asked. I still hope the balance would continue to grow towards something like >50% of community requested features in the changelogs instead of approx 10%.

Here are the things i've been missing the most while working and especially scaling my big project with their associated detailed feature request (some were written by me, some by other C3 users) :

• Hierarchy View

• Project View Search QOL : Ability to expand searched Folders/Families to find their content too

• Better Property View (worst part of C3 UX IMO)

• Right Click > Find all References of Variables directly from Property View

• Option to automatically select the layer of the selected instance

• Find : Option to hide/show ambiguous Results

• Reloading addons without restarting the editor (so Addon SDK is finally pleasant to use)

(^ Scirra just released this in r363!)

• Custom Expressions

• Debugger : per Behavior/Plugin CPU usage

• Scripting interfaces for Custom Actions

• MeshPointX/Y/Z expressions

• Terminate actions for functions/Custom Actions