It’s a crate for server-authoritative networking. We use it for Project Harmonia, but it’s general-purpose.

Kinda our 30th anniversary 😅 This release introduces remote triggers. The API is similar to our networked events. Here’s a quick showcase for client triggers:

app.add_client_trigger::<DummyEvent>(ChannelKind::Ordered)
    .add_observer(receive_events)
    .add_systems(Update, send_events.run_if(client_connected));

fn send_events(mut commands: Commands) {
    commands.client_trigger(DummyEvent);
}

fn receive_events(trigger: Trigger<FromClient<DummyEvent>>) {
    info!("received event {:?} from {:?}", trigger.event, trigger.client_id);
}

Server triggers have a similar API. Targeting entities is also supported.

We now also provide an example backend and examples that directly from the bevy_replicon repo. The examples have also been re-written to take advantage of the latest Bevy and Replicon features.

📜Full changelog 📦bevy_replicon

    • ShaturOP
      link
      fedilink
      arrow-up
      1
      ·
      1 hour ago

      The difference is the same as between Bevy’s regular triggers and events. We aim to mirror the Bevy API and simply make it networked.

      Events are buffered and pull-style, while triggers are called on commands flush and can target entities and components. Triggers were introduced in Bevy 0.14. Generally, you should use triggers for events that happen rarely and events for things that need to be processed in batches.