Different Event Paradigms

[dubrowgn]

I've been playing around with BMS for a couple of weeks. It pretty impressive!

As far as I can tell, the only way to handle events is via ScriptCallbackEvent + event_handler::<OnEvent, LuaScriptingPlugin>. This works, but is fairly boilerplate heavy on the rust side, needing two sets of event registration types/code, and relatively opinionated since event_handler handles the dispatch in a specific way. Are there plans to make event handling more inline with bevy in the future? Specifically:

1. EventReader<E> / EventWriter<E>

Being able to use EventReader and EventWriter natively from script systems via system_builder. A cache/performance friendly way to handle lots of the same kind of event. Theoretically, no BMS specific registrations or boilerplate needed.

2. Trigger<E>

Being able to use Trigger<E> natively from script systems via system_builder. Theoretically, no BMS specific registrations or boilerplate needed.

3. One-off ScriptCallbackEvent-like dispatch

An easy way to manually dispatch a script event handler. Basically what event_handler already does, just for a single event. Maybe this can even be abstracted to easily dispatch any script function by name, where event handling is just one use case.

Note: I'm using the pre-v0.17 bevy event/trigger terms.

[makspll]

EventReader<E> / EventWriter<E>

Yes, although it would require support from bevy, or a custom type data: bevyengine/bevy#18511

Trigger<E>

Haven't thought about that, but it may be possible to register script systems as observer systems. It looks like bevy uses ComponentId's here, but looks like the only way to generate EventKey structs is from typed On<T> instantiations: https://docs.rs/bevy/latest/bevy/prelude/struct.On.html#method.event_key, so this might also require a dynamically typed API from bevy in this area

One-off ScriptCallbackEvent-like dispatch

You can already do this via the RunScriptCallback command, it currently calls the top-level function in the script with the given callback label. It will also work with the new concept of registered callbacks introduced in this PR

[dubrowgn]

EventReader<E> / EventWriter<E>

Yes, although it would require support from bevy

Is this necessary to support just event types that implement Reflect, or do you mean in a more general sense of being able to support any event type? The linked issue kind of makes it sound like the latter.

I played around with adding some kind of Event field to ScriptSystemParamDescriptor. I assumed it must be possible to add an EventReader/EventWriter adapter here because Resource doesn't have to be Reflect either, but admittedly I didn't get it to work. All the bevy macro derives and reflection make it a bit difficult to know what you are actually working with.

You can already do this via the RunScriptCallback command

Thanks, I think RunScriptCallback::run() is more or less what I was looking for.

[makspll]

You need some sort of support from bevy to even send a event, there is no interface at the moment allowing you to take a dyn Reflect value and send it as an event.

In fact because the underlying resource is generic, you can't even query for it without having some sort of Event type aware construct with compile time knowledge

[dubrowgn]

Fair enough. That is pretty frustrating.

It does seem like BMS' event_handler function has similar issues, and is still useful though. You basically have to register events you care about, up front, at compile time. Maybe it would be useful to have a generic function that takes an event type E that implements Reflect, and injects an adapter function into the script context that puts the input event in the appropriate EventWriter? Then scripts could call that adapter without knowing about EventWriter. I suppose you'd have to have access to the bevy World.

A similar event registration mechanism seems like it could work on the EventReader side too. Expose some EventReader proxy to the script context, as long as the registered event E implements Reflect. It wouldn't be as flexible as what you want, but it would cover cases where you have a known scripting API to your application, which seems like a pretty big use case. If bevy ever does sort out this portion of the reflection API in the future, obviously move to that.

The upside of these adapters is that they wouldn't use a separate event queue from bevy events, like event_handler would do, making it easier for rust and script code to communicate using standard bevy event types.