Aevyrie

We could do all three things with a single closure version: ```rs send_event(impl FnMut(E)-> F>) ``` 1. Capture `send_event(move |_| my_other_event.clone())` 2. Convert `send_event(MyEvent::from)` 3. Default `send_event(|_| MyEvent::default)`

You would need to clone the event regardless. Events need to traverse the hierarchy and can be mutated. If you target two entities, you need two events. If your event...

You might want to change this to take a closure instead, like mentioned here: https://github.com/aevyrie/bevy_eventlistener/issues/25 That would avoid the need for Clone, and you would be able to react to...

I had a discussion on discord about the design of what this would look like: https://discord.com/channels/691052431525675048/1038322714320052304/1209594439832567818 The goal is that when you register a callback, you get a handle to...

Here is a sketch of what the API could look like: ```rs // In the simplest case, you can add a listener with no callbacks in a bundle commands.spawn((Name::new("Foo"), On::::default()));...

From discord discussion, a rough look at what the new method will look like: ```rs #[derive(Component, Default)] pub struct On { phantom: PhantomData, /// A function that is called when...

> Now that `bevy_mod_picking` is upstreamed, will work be continued on this PR or somewhere else? No, this crate will eventually be archived in favor of observers and propagation, and...

This should be possible now, by adding that logic to the callback. This may behave strangely if it is ever possible to add multiple listeners of the same type to...

This has been added to bevy_mod_raycast: https://github.com/aevyrie/bevy_mod_raycast/pull/38 Currently downstreaming into bevy_mod_picking.

Yes, closing.