Event ordering

[UkoeHB]

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). The default sending/receiving systems have private visibility too, meaning they can't be configured to run at other times.

Possible alternative:

• add ServerSet::ReceiveEvent and ServerSet::SendEvent
• use .run_if(in_state(ServerState::Hosting)) for server endpoints, and .run_if(in_state(ClientState::Connected)) for client endpoints

What do you think? This way the server sets can be configured.

[Shatur]

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?

[UkoeHB]

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.

[Shatur]

Makes sense! I think that ServerSet::ReceiveEvent and ServerSet::SendEvent should be good.

[Shatur]

Do you want me to draft a new release now or you have plans for other suggestions?

[UkoeHB]

@Shatur can we wait a few days? I need a bit more time to think about it.

[Shatur]

Sure, no problem.

Curious, are you writing a library or a game?

[UkoeHB]

I am writing a game, but starting out with an architecture template that will be pushed to github eventually.

[Shatur]

I assume you working on prediction + rollback? Nice, let me know if you need anything from my side.

[UkoeHB]

Hah nothing that advanced, I just have an obsessive attention to detail.