Closed UkoeHB closed 1 year ago
The server event sending_system and the client event receiving_system are both configured in set OnUpdate(ServerState::Hosting). This means a server response to a client event received by the server in tick A cannot be sent out until tick B (the same is true for a client responding to a server event).
Systems that are in set ServerState::Hosting
are not affected by the tick. But sending_system
also inside ServerSet::Tick
, so you are right: "server response to a client event received by the server in tick A cannot be sent out until tick B". I did this to avoid receiving events without the updated state.
Do you want to configure this behavior? What behavior would you like?
Systems that are in set ServerState::Hosting are not affected by the tick.
I mean the server app update cycle (a bevy tick, not a replicon tick).
What behavior would you like?
I would like the 'receive from client' and 'send to client' steps to sandwich my server code so that a message received in one update cycle can be responded-to in the same update cycle. Note that bevy_renet supports that pattern: receiving is in PreUpdate
and sending is in PostUpdate
.
Makes sense!
I think that ServerSet::ReceiveEvent
and ServerSet::SendEvent
should be good.
Do you want me to draft a new release now or you have plans for other suggestions?
@Shatur can we wait a few days? I need a bit more time to think about it.
Sure, no problem.
Curious, are you writing a library or a game?
I am writing a game, but starting out with an architecture template that will be pushed to github eventually.
I assume you working on prediction + rollback? Nice, let me know if you need anything from my side.
Hah nothing that advanced, I just have an obsessive attention to detail.
The server event
sending_system
and the client eventreceiving_system
are both configured in setOnUpdate(ServerState::Hosting)
. This means a server response to a client event received by the server in tick A cannot be sent out until tick B (the same is true for a client responding to a server event). The default sending/receiving systems have private visibility too, meaning they can't be configured to run at other times.Possible alternative:
ServerSet::ReceiveEvent
andServerSet::SendEvent
.run_if(in_state(ServerState::Hosting))
for server endpoints, and.run_if(in_state(ClientState::Connected))
for client endpointsWhat do you think? This way the server sets can be configured.