I'm unable to receive messages through bevy_spicy_networking that contain strings- I've sent and received empty messages and messages with u8 values, and so far this issue only occurs with string messages (video).

See this issue that I submitted to erased-serde for error messages etc. I'm not sure if I've done something wrong, if this is an issue with bevy_spicy_networking or erased-serde.

If it's a bug it seems like a bad one. You can clone and build warfare-rs (at this commit) if you need to reproduce. The messages are defined in networking/messages.rs, and the actual send/receive code is in systems/network.rs.

(there are some dependencies to build warfare, check the readme)

Since NetworkData does not implement Clone, it is impossible to acquire ownership of inner as one has only access through EventReader::iter() which hides e behind a reference. Thus, into_inner cannot be called.

fn handle(mut incoming: EventReader<NetworkData<MyData>>){
    for e in incoming.iter(){ // e:&NetworkData<MyData>
        // I want to retrieve e (and use it elsewhere)
        let data: MyData = e.into_inner(); // errors: cannot move
        let data: MyData = e.inner; // errors: inner is private
    }
}

I would propose making inner public.

edit: What I want is to clone inner :)

This PR provides a small QoL improvement by allowing the user to chain registering ServerMessages (or ClientMessages). This is helpful when using listen_for_XXX_message::<T>() in for example Plugins or just having a lot of different Messagetypes to initialize. It furthermore resembles the API of the Appbuilder, which is IMHO desirable.

I'm working on a game in which players can play with each other on a LAN, with anyone acting as the server. Practically, what this means is that the server is also acting as a client, and should react to messages broadcast by itself exactly as a client would.

I've experimented a little with different arrangements, but there's a lot of code duplication because the server can't receive it's own messages. If NetworkData had a public new method, for example, I could insert the events myself when they are sent, and then the same systems that the client is using to receive messages would be used for reacting to local messages.

I can't find any easy way to do this that doesn't look like a maintenance nightmare down the road. Does anyone have any pointers?

Prior to this a new heap allocation is made every time you encode a packet to be sent on the socket. This change allocates a buffer the max size specified by the network settings and it is used to dump the encoded bytes into before being written by the socket.

I also cleaned up the receive buffer a little; while it wasn't much, it seems to save a few extra asm instructions :)

I tested this with the server/client examples and it seemed to work.

This introduces a crate compile feature flag to set the packet size headers down to u16 instead of relying on the u32 default. I added this as the client I wish to interfact with expects these to be u16; however, for a lot of games you probably won't need u32 as those are some big packets :smile:

Screenshot of examples after changes:

Fixed/Updated

• Updated the project to Bevy 0.9,
• Updated the other dependent crates
• Updated the Rust version to 2021
• Fixed miscellaneous documentation misspellings.
• Bumped the version number to 0.5.2.

The examples work for the local multiplayer however I am unable to test the external networking so that would be appreciated if anyone else can

I'm proposing a new model for bevy spicy networking that will allow users to bring they're own transport layer, this will enable users to use udp or tcp based protocols (or really anything they can get to work), without adding too much overhead, and still keeping all the convenience of spicy. This is gonna need some more changes and docs to be a little bit nicer, but it does work! Here's an example using a udp (via QUIC) based provider that's nearly working (I don't completely understand the protocol, but it does compile and allow us to send messages, it:

https://github.com/jamescarterbell/bevy_spicy_networking_tokio_quinn

Currently Spicy Networking is very cool, but is bound to only using TCPStream, I don't think it will be to turn this crate into a driver for different providers of streams and such, mainly because the Server and Client are essentially holding JoinHandles for tasks that could be swapped out for tasks using different channel types. I'm going to play around with this and see where it goes.

The new_connections channel seemed to be sending a Result instead of just the new connections, I'm not seeing a real reason why we can't move that logic into the listen loop so I did that. Feel free to deny, that's the only difference between this one and the other version bump pr.