-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ServerEvents can be missed on clients using FixedUpdate #86
Comments
Here's my workaround at the moment: fn clear_events<T: Event>(mut events: ResMut<Events<T>>) {
events.clear();
}
fn replicon_event_setup(app: &mut App) {
// before replicon creates these with normal `add_event`, create them manually
// so they will not be cleared before FixedUpdate can run
// see: https://github.com/lifescapegame/bevy_replicon/pull/85
#[cfg(feature = "is_client")]
{
app.init_resource::<Events<InitClientMessage>>();
app.init_resource::<Events<PlayerInputsMessage>>();
app.init_resource::<Events<TimingReportMessage>>();
app.init_resource::<Events<EventMessages>>();
// clear them at the end of fixedupdate:
app.add_systems(
FixedUpdate,
(
clear_events::<InitClientMessage>,
clear_events::<PlayerInputsMessage>,
clear_events::<TimingReportMessage>,
clear_events::<EventMessages>,
)
.in_set(SpacepitSet::Last),
);
}
// SERVER -> CLIENT EVENTS
app.add_server_event::<InitClientMessage>(SendPolicy::Ordered);
app.add_server_event::<PlayerInputsMessage>(SendPolicy::Unreliable);
app.add_server_event::<TimingReportMessage>(SendPolicy::Unreliable);
app.add_server_event::<EventMessages>(SendPolicy::Unreliable);
// ...
} |
For reference, this is fixed in this bevy PR. |
Could just document the workaround until bevy solves it for us 🤷♂️ |
Fixed in Bevy 0.12.1, closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
because of how bevy clears event queues it currently happens that server events can fail to be received by clients using FixedUpdate.
you might write to the EventWriter, and then a few frames tick past before FixedUpdate runs again, by which time the event is long gone. Double buffering keeps it for 2 ticks only.
On your client, if you want to receive the server events in a FixedUpdate system, you might not see them all (even though replicon receives them and writes them to the EventWriter).
here (server_event.rs) is where the standard
add_event
is used, which is what the clients consume via a system using normal EventReaders.to make this work for fixedupdate clients, that would need to be a manually created Events resource too, like are used for the serverside events (the ones with
ToClients<>
wrappers).but then the question is: where do we clear the event queues?
we don't really know if the client is using fixedupdate..
I could change it to a manually created/cleared Events, and put a system to clear it in in
Last
. That would work the same for people who aren't using FixedUpdate.Then we'd need a setting in the replicon client plugin:
using_fixed_update=true
which doesn't add the event clearing system, but makes the consumer add it themselves to fixedupdate.How does that sound?
The text was updated successfully, but these errors were encountered: