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

Fib Thanks for those kind words !

In fact, this is quite the opposite, I always advise to get the UID values of any object at runtime only (whether they were created at runtime or not), using the MyInstance.UID expression to get them directly or to store them in variables to access them later. I never "hardcode" UID numbers.

There are a bunch of reasons for which UIDToAnything is useful, i'll probably add additional screenshots on the itch page someday so it's easier to understand.

Indeed if you don't hardcode your UIDs, you need to pick the instance to be able to use UIDToAnything, but ONLY ONCE. For example, let's say you have a Entity family (which contain Player and NPC Objects) with a TargetUID number variable. At some point you could set the TargetUID of your Player Object to the UID of a specific NPC.

Then you could retrieve any info of this target and act on that NPC instance at any time, without picking them anymore, only thanks to the Player.TargetUID variable. For example you could use the UIDTo.DistanceTo(Player.UID, Player.TargetUID) expression that is packed with the Plugin to get the distance between the Player and that NPC without needing to pick the NPC Object.

Even better than that, you could then set the TargetUID of your Player to an instance of a barrel Object (Barrel.UID) and your game logic would still work even if Barrel isn't part of the Entity Family. This is an other great aspect of the UIDToAnything Plugin, you can have common logic for different Objects Types and even different Object Classes (Sprite and Text for example) without putting them in the same Family.

(also C3 don't let put Objects from different Object Classes like Text and Sprite in the same Family, so UIDToAnything allows you to workaround this big limitation of the C3 engine, which is very useful when creating a UI System for your game, as you can share the same logic for your 9-Patch/TiledBG/Sprites/Texts etc)

bankthink

Whether you're using "instance variables" or any "data+ behavior", I would advise against using the Persist Behavior.

There would be 2 main ways to retrieve your data once you switch your layout :

You could make the object itself global as oosyrag suggested in their answer to your thread, if this make sense to your game.

Or create a simple save/load system by storing the data on an other Global Object (putting relevant data in instance variables of this Global Object for example), or just using Global Variable. You could just save/load your Array/Dictionaries behavior data as JSON with single actions (you can store the whole JSON string you'll get into a single String Variable to retrieve it later easily). Same for the JSON+ behavior which would even allow you to have even more control on what you're saving/loading thanks to nested paths.

All in all, Data+ can definitely help you to create a better save/load system or even simplify stuff a lot if you just go with the Global Object technique but in any case I would advise you to first try to learn how to store and load a instance variable of your object from one layout into an other using Vanilla feature :) Try what oosyrag suggested !

Hello RafaelMatos !

I fixed the Array Behavior Debugger issue and pushed a 2.1 version of the Data+ Pack including those fixes.

EDIT : I also fixed the o() and snap() expressions issues for the Util addon and pushed a 2.4 version including those fixes. (as we discussed on Discord the remap() expression was already working fine)

Thanks a lot for reporting those issues :)

And thank you for your kind words on itch, i'm glad you find those addons useful ! 🙏