Add `emit` command that emits events on nodes

[Maximinodotpy]

I think it could work like this

$ emit $path/of/node event_name "additional args for the event emitter function"

For convinience sake the user could copy paths into the input field at cursor position by clicking on it on a recent output to the ls command (#6 ).

( Awesome Plugin by the way! )

[Kubulambula]

This command would have to be disabled on export builds (debug builds should still be able to use this command imo) because I intend that GDShell would be safe-to-deploy by default, meaning that all the built-in commands should not be able to modify the game's logic flow in any way as someone might one day release their game with GDShell and it could be abused to pirate or hack the game if it's multiplayer. If the user makes his own command for cheats, or enables this command on export builds it's up to them.

Anyway I like the idea, usage and how it integrates with the proposed ls command. The copy on click should be easy to implement as GDShell expects a RichTextLabel for output.

There could also be more commands like this one for overriding (set) and printing (see/display/print?) variables, calling functions (call) and so on. They would all use the same syntax for ease of use.

This however would be really clunky when you try to modify multiple values, call a function and emit a signal. For this frequent use the user should make their own command that can be specialized for the usecase. For general one-time editing however this could be a great tool.

Do you want to tackle this command? I currently don't have much time, so I would really appreciate it.

The other ones, that I suggested would be very similar I believe, so the it should be quite easy.

( Awesome Plugin by the way! )

❤️

[Maximinodotpy]

Hey Thank you for the answer

I would like to collaborate I'm just new to this whole open source thing so I hope that this works out :)

[Kubulambula]

I'm pretty new to this too, so don't worry about it and consider it a learning opportunity.

Feel free to ask when you encounter any problem!

[Maximinodotpy]

Hey Friend,

It's possible that I wont have time to look at this proposal as I am working on my own things.

[Kubulambula]

Hey,

that's totally understandable. You know where your priorities are and I can't force you to contribute to an open source repository.

Thanks for the proposal and for telling me! ❤️

[CollCaz]

I think emitting signals like that would be problematic, once you start emitting signals that should only be emitted when particular things should happen, without them happening could cause a lot of trouble.

A better solution would be to add a command that would call a given function from a node, the user may then decide to create a function in that node that would emit the signal.

This is also a very helpful command either way!

edit: I managed to get both ideas working

[CollCaz]

Did some testing on this, I have a complete command that emits a signal on a given node, with error handling and everything, BUT
I tried it on a few nodes and most of the times the emit signal would just return ERR_UNAVAILABLE...

after more testing i believe the emit function can only emit connected signals.

[CollCaz]

Sadly there is no way of know what type a signal expects it's arguments to be, therefore it's not possible to support signal arguments.

Currently my command can emit any connected signal from any node on the tree, but doesn't allow arguments
Is this worth adding to the codebase?

[Kubulambula]

I think emitting signals like that would be problematic, once you start emitting signals that should only be emitted when particular things should happen, without them happening could cause a lot of trouble.

A better solution would be to add a command that would call a given function from a node, the user may then decide to create a function in that node that would emit the signal.

For this I thought about adding a call command that would handle method calling and it would be functionally similar to the emitting especially with the handling of arguments.
Both of them would be unsafe without any workaround I can think of, but they would be intended only for debugging and not for production (they should be disabled on export builds).
Also the user can work around this by making their own functions or commands that would handle the arguments the way they need for their project.