Recursive events

[MrMarble]

bevy = { version = "0.8.0", features = ["dynamic"] }

Currently, I have an entity that sends an event when it changes to propagate the change to the close entities and those entities do the same in a recursive way

I tried doing

fn propagate_on_change(mut rev_change: EventReader<ChangeEvent>, mut wev_change: EventWriter<ChangeEvent>)

But that yields an error ResMut<bevy_ecs::event::Events<wfc::ChangeEvent>> in system wfc::propagate_on_change conflicts with a previous Res<bevy_ecs::event::Events<wfc::ChangeEvent>>

How should I do it? Maybe is a XY problem, but I can't think of a way of doing it.

[wilk10]

You can use a ParamSet:

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_event::<MyEvent>()
        .add_system(sender.before(LabelBoth))
        .add_system(both.label(LabelBoth))
        .add_system(receiver.after(LabelBoth))
        .run();
}

struct MyEvent(&'static str);

#[derive(SystemLabel)]
struct LabelBoth;

fn sender(mut writer: EventWriter<MyEvent>) {
    writer.send(MyEvent("one"));
}

fn both(mut events: ParamSet<(EventReader<MyEvent>, EventWriter<MyEvent>)>) {
    for event in events.p0().iter() {
        println!("from both {}", event.0);
    }
    events.p1().send(MyEvent("two"));
}

fn receiver(mut reader: EventReader<MyEvent>) {
    for event in reader.iter() {
        println!("from receiver {}", event.0);
    }
}

This will continuously print:

from both one
from receiver one
from receiver two

Because the receiver system will read both events. So it's doable, but you may want to be careful.

Alternatives:

• Always use a different rust type for the events that get propagated, so you read an event type, and write another event type in the same system. I think this should offer the least footguns, but you may need to refactor a lot.
• Never read and write the same event in the same system. Maybe it's possible to just:
  -> read your main event type and write an intermediary event type (eg: PropagateChange) in the same system,
  -> in another system read the PropagateChange event and write a new ChangeEvent, but i didn't try it out, it might get tricky with the system ordering.