Add scripting interface for System Signal action

[armandoalonso]

Reviewed guidelines

• [X] I have read and understand the suggestion guidelines

Checked for duplicate suggestions

• [X] I checked for existing similar suggestions

Summary

please add a scripting interface for signal, this seems like a middle ground for https://github.com/Scirra/Construct-feature-requests/issues/271, adding this scripting interface will open up a-lot possibilities when when creating games using javascript/typesript to trigger events in the event sheet.

C3.Plugins.System.Acts.Signal(tag)

Possible workarounds or alternatives

a possible workaround is to create a brand new addon that essentially duplicate the signal functionality and expose it manually to JavaScript, but this it won't behave the same way entirely because then addon would need to use undocumented features to get the scheduledWaits and won't work with wait for signal.. so that is out of the question

but it can be partially done to just act as a triggering mechanism.

Proposed solution

Add a new runtime function to invoke Signal(tag)

or Add a new System Plugin interface with Signal(tag) exposed

this call should trigger any signals in the event sheet

Why is this idea important?

currently the only way to call inside the event sheet is with functions, and when we need to wrap every interaction that goes across the event sheet/ JavaScript context. it adds lots of bloat to a project. having wrapper functions for everything is error prone and kinda a nightmare to work with with large projects

Additional remarks

https://github.com/Scirra/Construct-feature-requests/issues/271

is another request to kinda to accomplish the same thing, but differently. the main problem is communication from JavaScript to events. the only way is using functions as wrapper. it makes creating complex systems that take full advantage of constructs strength difficult.

[WilsonPercival]

Can you explain to me why you think this method makes it difficult to build complex systems? issue293.zip

[armandoalonso]

complex systems that take full advantage of constructs strength...

Ie... Event sheets

So the issue is not making complex systems, that can be done in both events sheets and in Javascript in isolation.

The issue comes when you need to communicate asynchronously across boundaries.

Right now from js if you want to trigger something from js.. You need to manually invoke a function. The function is accessible globally but is only defined in one layout. So the one function definition could be come bloated if you need to handle alot of of stuff...

Where as signals can can defined in multiple event sheets and each can handle a subset of logic...

For an easy example you have a player that takes damage. You need to update player state, you need to update ui. And proa ly trigger effects or sound?

In js you can invoke a player take damage signal. And in every event sheet that's included the right code will run.. With a function Implementation the function starts handling multiple things and couples it to many systems.

It's just a cleaner way to write logic, that improves developer experience. I guess my choice of words were incorrect it's not more or less complex... But it makes it easier to reason about your logic on a complex project

[WilsonPercival]

To be honest, I don't understand what you're talking about. You don't need to extend the Signal function you created. You simply call the function when you need to trigger a signal. It shouldn't matter to you whether you call the signal directly or through a function. All you need is to declare one C3 function and that's it.

[armandoalonso]

I guess you could create a generic function to then call the signal?

But that always seems to be the solution? Why do I need to create a function to talk to events?

Same for custom actions? The answer is always just wrap it in a function. Then your project ends up with 50 wrapper function that that just proxies data over?

Whats the point of having a js api, if alot of the same function are gated by event sheet?

[WilsonPercival]

The problem here is that you want to use scripts and events at the same time. If you only used scripting, you would never need to call signals from the event sheet. For this reason, there is nothing wrong with wrapping the functionality you need from the event sheet into a C3 function.

[armandoalonso]

I highly disagree with this take. If I was just going to use only scripting I would not use construct.

The benifit of using construct comes in the form of the picking system and predefined behaviors and plug-ins...

Now when the current plugins and behaviors are not enough you want to extend the functionality and build on those objects you can use the sdk or you can use subclassing in scripting.

With the sdk you can define triggers which are treated just like signal except for some built in stuff with the wait scheulder

In scripting you can't do that. The goal of the new sdk 2.0 changes are leaning towards unifying sdk and scripting runtime. Which means my ask here is not too far fetched?

I 100% bieleve if you were just going to use scripting to make something in construct you have chosen the wrong tool because you are limiting yourself to about half the tools available in events (until they make the api more consistent with events) why reinvent everything?

The best workflow is to use a mix of both. At least in My opinion. Using both together is somewhat magical. But can also be improved to make managing more Complex games easier hence my request for this feature

[WilsonPercival]

You can only write scripts and no one forbids you to use predefined behaviors and plugins. Don't think that Construct and the event system are one whole. I used events for 8 years, but when I found out that you can do the same thing through scripts, I completely abandoned events and write only through scripts. By using events and scripts together, you get the disadvantages of both, rather than the advantages of both.

[armandoalonso]

but when I found out that you can do the same thing through scripts,

But that's the thing you can't... Unless you rebuild that functionality from scratch? Which is fine but why reinvent the wheel?

Ilike with everything there is a tradeoff for everything, events or scripting. But that does not mean you cant minimize those tradeoffs, and just because you found an optimal way for you, does not mean it's optimal for everyone. There are multiple ways to accomplish the same task...

This conversation has derailed quiet a bit from the original ask. If Scirra want to add the scripting interface for signals then that will be great if they don't? Then that is okay too.

There is no harm in asking?

[WilsonPercival]

There are a million things that could be added to scripting interfaces to make it a little easier to work with events and scripts at the same time. But this process will never be better than writing only in scripts, no matter how many queries you write. You're just creating a ton of useless work for the engine developers and I really don't want requests like these to be implemented. If we consider them from the side of time spent and benefit received, then the benefit here will be minimal. I think if it were really very easy and quick to do, it would have been done a long time ago. But some things must be left undone in favor of other, more important things. The engine will never be perfect, there is no need to try to polish it. Instead, it's better to focus on more important things.

[armandoalonso]

While I partially agree with you on some points. Not opening the request and documenting the use cases of improvement to the engine because you don't want to create extra work is really dumb.

We are all paying customers and it's not like they are obligated to implement my request I'm not navive and understand they have like 2 developers. But that's not an excuse to not provode feedback or request featurea even if the request gets glossed over it provides context on how users are using the software.

And on top of that who decides what's important... YOU? Ohh well I'm so sorry for even thinking about requesting, I'll just go cancel this request and delete my github lol.

Like instead give the request a thumbs down and move on.

[WilsonPercival]

I am not the one who decides what is important and what is not. If you have forgotten the rules, let me remind you:

Your request is solved by creating a single function. When I asked you why you didn't like this solution, you couldn't answer it, arguing that developers are obligated to implement it no matter what.

[armandoalonso]

I am not the one who decides what is important and what is not. If you have forgotten the rules, let me remind you:

Your request is solved by creating a single function. When I asked you why you didn't like this solution, you couldn't answer it, arguing that developers are obligated to implement it no matter what.

I would advise you to reread the thread? No where did I mention anyone is obligated to implement anything.

Just cause you don't agree with the suggestion does not mean it's not a valid ask.

[WilsonPercival]

Am I correct in understanding that you are only wondering if the developers would like to implement this feature?

[armandoalonso]

Am I correct in understanding that you are only wondering if the developers would like to implement this feature?

I mean if you think about the concept of this whole feature request board? They are more like suggestions.

I'd say alot of the stuff that gets requested does not get implemented. But it does get looked at by Scirra who ultimately make the decision.

I am not wondering anything I am suggesting something. Weather it gets implemented or not.

[WilsonPercival]

I've never seen developers say, "Please send us as many ideas as you can and we'll see what we can implement."

[armandoalonso]

I've never seen developers say, "Please send us as many ideas as you can and we'll see what we can implement."

This literally happens all the time, you are delusional if you think it doesn't, or don't use software very often.

Every software company I have ever worked for (from startups to very large companies) have a similar feature request /suggestion platform. Even games companies have this? Feature requests and suggestions exist for every engine?

[Zizaco]

@armandoalonso +1 This could be a valuable addition. I find it an interesting way to integrate scripts with event sheets. I think this can be quite powerful with the add-on SDK. Having add-ons emit signals for developers to set "on signal" listeners in the event sheets.

Here's the simple workaround I currently use:

// Invoke eventSheet function to emit signal
runtime.callFunction("emitSignal", "my_signal");

[AshleyScirra]

A new signal() method, as well as waitForSignal() for allowing JavaScript code to also wait for a signal, is now available in r401.