Events, Tweens, Timers. Timers have worse performance than tweens?! Events are best... WHAT?

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

> 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.

So one of the main limitations of using functions for this is that the handler logic is only defined in one place and is defined explicitly so everytime you call a function your get the exact same behavior.

I think the actual ask is to have a similar mechanism to trigger and some event. But then have the ability to define different logic for handling that trigger probably based on context.

This adds an extra layer of flexibility, and also gives the user the tools to keep the event sheet better organized and grouped together.

A simple example let's say we have a player health bar on one event sheet and the in a different layout we need same infor for different display but still relies on the same info.

Without having to duplicate a bunch of event in layouts. You can have your player object emit signal player.health.changed and pass a value for player health

In each layout you can have a trigger for player.health.changed and then each layout event sheet can handle this logic differently.

It provides another tool to help the user decouple some of there systems. And this is very simple example but I think illustrates the point a bit better.

This condition does not rely on every frame check, and has the same flexibility as custom object when picking. The signal should be able to traverse different object types. But also be handled on a per instance basis so only the picked instances execute the logic.

And it should hopefully be in the JS api as well.

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)

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

I think I know what Overboy means and I'm pretty dumb with programming. Correct if I'm wrong but a good example of this is Godot's custom signals + autoload(singleton) and the possibility to assign this trigger to any block without caring who is listening and who is calling and to assign parameters/objects. However, I want to say this respectfully: through all these years I always have had the impression that Scirra should literally use other game engines more to know why some features are so important but somehow is treated like a minor thing because sometimes feels like Construct is more of a general purpose software than a game engine due to the, perhaps, the lack of a proper game engine experience and its needs