You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think what's really missing from bevy_matchbox is something akin to an EventWriter and EventReader for Matchbox messages.
This proposal outlines how I would implement this for a known socket configuration, with 1 unreliable and 1 reliable channel. It would maybe be a little messier with generics, but follow my lead here, if you will:
Essentially we would need to perform the network read on CoreSet::First, load the buffer of messages, and then clear the buffers on CoreSet::Flush/Last. Do this for both sending and receiving.
Such an integration would be very flexible, since it would play with Bevy's systems quite well and the user's own custom systems, e.g.
And to prevent against potential de-serialization collisions (an f32 can be interpreted as a u32, for example), Message needs an id() -> u16, but that can be easily derived with a hashing macro, based on the name of the Payload:
#[proc_macro_derive(MatchboxPayload)]pubfnderive_payload_fn(item:TokenStream) -> TokenStream{letDeriveInput{ ident, .. } = parse_macro_input!(item);let name = ident.to_token_stream();letmut s = DefaultHasher::new();
name.to_string().hash(&mut s);let id = s.finish()asu16;quote!{impl::bevy_matchbox::Messagefor#name{fn id()->u16{#id}}}.into()}
The text was updated successfully, but these errors were encountered:
I think what's really missing from bevy_matchbox is something akin to an EventWriter and EventReader for Matchbox messages.
This proposal outlines how I would implement this for a known socket configuration, with 1 unreliable and 1 reliable channel. It would maybe be a little messier with generics, but follow my lead here, if you will:
Take an example payload:
An pair that with an API purposefully similar to EventReaders:
Client Receiver
FullMesh Receiver
(Server receiver not done for brevity)
(and Sending would be equally simple for the user)
Essentially we would need to perform the network read on
CoreSet::First
, load the buffer of messages, and then clear the buffers onCoreSet::Flush/Last
. Do this for both sending and receiving.Such an integration would be very flexible, since it would play with Bevy's systems quite well and the user's own custom systems, e.g.
The key here is we would need something like
.add_network_message<T>()
, which would add the listeners and senders:The proposal hinges mostly on a shared trait,
Message
, which can de-serialize into a shared packet type likeMatchboxPacket
, as such:And to prevent against potential de-serialization collisions (an f32 can be interpreted as a u32, for example),
Message
needs anid() -> u16
, but that can be easily derived with a hashing macro, based on the name of the Payload:The text was updated successfully, but these errors were encountered: