New feature: `Event Emitter` node about arrow HOT 3 CLOSED

Event emission (signaling, propagating calls, etc.) highly depends on the runtime. In some cases (e.g. in environments with more static culture) you can not really have such flexibility easily. There is also another question: Why only one value? In many cases you need to pass multiple parameters/arguments with a signal. Here faces a second question: How many? Should it be implemented as an array/vector of variants (with heap allocation) ?
At the end of the day most developers have to customize around it in their own ways.

If I wanted to achieve similar (general purpose) functionality, I would go for a Foreign Function Interface node, where the node knows the events you may want to signal, emit or call, as well as the number and accepted types for its parameters. I think it's a better approach in general, although the runtime-specificity remains in place.
Such node can read the API data from a (JSON) file in the project's work directory, allowing source version management and easier modifications. I imagine a structure similar to this for the ffi.api file:

{
    "inter_chapter_jump": { // Function name to be called or the event name/label
        "chapter": { // Parameter/argument name
            "optional": false,
            "input":  ["int", 0, 100, 1, 0] // To customize parameter's input
             // (i.e. [type to explain the rest of customization, here:, min, max, step, default])
        },
        "custom_entry": { // Another parameter
             // ...
        },
        "fallback": { // Defines if we should fallback to the chapter's entry if the custom entry is invalid.
            "input": ["bool", true], // i.e. boolean with default true value
            "optional": true
            // , ...
        }
    }
    // ... And maybe supporting enums on top of int or str, providing hints and more.
}

I confess that I've contemplated it a lot, but it has never been a priority.
It is not planned either, though a pull request providing a viable implementation is more than welcome.

from arrow.

Event emission (signaling, propagating calls, etc.) highly depends on the runtime. In some cases (e.g. in environments with more static culture) you can not really have such flexibility easily

Engine-side, the concept I proposed would end in either

• a) a lazy switch-statement, or
• b) code generation that could do a) or something a bit more eloquent like creating Callables or sth. along the lines

Why only one value? […] How many?

if you choose

• Character, then you have more than one value -> it's Dictionary
• Variable, then true, it's one value; but
• Value can be anything
  • I intended it to be a string that the user can parse to anything: Array, Dictionary, Vector2/3, Formula, etc.
    • in retrospect, the LineEdit next to Value should be multi-line (for long values such as Array, Dictionary, etc)
  • maybe a better word would be Raw
  • this way, you can reference multiple characters, variables or anything else
    • this might lead to issues due to typos -> except we use the existing parsing logic for characters and variables in text for verification

The "single" parameter you would send in your Arrow-Event would be a Dictionary, looking like this

{
  "value": "Riza",
  "type": "Character" // or `Variable` or `Value`/`Raw`
}

Regarding the event name: There's the design option to pass it on as a String, or create an Enum (not using UID). The engine-specific add-on can generate code for the Enum in a new code file (to minimize parsing issues due to typos)

Though I admit that the Foreign Function Interface approach would result in better UX in the Arrow Editor and an easier implementation Engine-side (but only if you clearly specify the argument order -> depending on programming language, keys are unsorted)

from arrow.

I generally prefer the FFI approach because it promotes a level of order and awareness.
At the end of the day though, everything highly depends on each project's workflow again.

On the other hand, if we are going for the lazy/raw strategies, we can get even more lazy and simply just implement a parser/handler for our runtime's Marker node that detects special syntax in its label property, and interprets it as a signal, a call, etc. As I've mentioned in the wiki mostly for prototyping, we can always interpret a Marker labeled something like print["hello world", debug] as a call in runtime.

I intended it to be a string that the user can parse to anything, .... Value should be multi-line (for long values such as Array, Dictionary, etc).

I don't see any advantage in a lazy approach, in comparison to the above mentioned Marker-hook model.

... this might lead to issues due to typos ...

It does make a lot of headache for sure.
The whole idea is really difficult to be kept under control. If signals and parameters are typed by the developers, there can be typos. And in both cases (manual or FFI), a change in API creates a need for delicate intervention to make sure nothing is broken. Here awareness and less generality helps a lot.

... specify the argument order -> depending on programming language, keys are unsorted.

Yes. One can pass the parameters as a {parameter: value, ...} dictionary to runtime where it most-likely has to somehow bridge between local and foreign APIs (and probably re-order the parameters), or simply change the API definition file to accept a sorted array/vector (i.e. event: [ { name: parameter_x, input: ... }, ... ])

Another point that comes to my mind is that nothing really stops the inputs/parameters in the FFI API definition file from being able to also accept arrays of values, or dictionaries (like when we define sets of tags in Tag-... nodes). Although the Arrow editor side of the things will be a little more complicated to develop, it provides an even higher level of flexibility.
Anyway, I recommend restricting accepted values singular and/or in sets, to be of Arrow's variants/primitives (i.e. str, bool, num) types.

from arrow.