@hq2000

I though I already made a devlog, but well… I needed to read my past commits to write this, so basically, I added more packets, created a packet viewer (wip, doesn’t really work) , a wasm plugin crate and tried to get it to communicate with the client. As of now, the login nearly works, I only need to reply to the cleint using the correct player profile info and session id. But, after looking at the logic, I (again) realize thinking about the architecture should be the top priority especially if you want to write a highly concurrent (and hopefully fast) minecraft server. This means I’m going to remove the old code and make a readable, maintainable and fun to work with protocol implementation (= config, status and login stages of the protocol). below is the stderr output of the server (yes, that’s my uuid)

“making it work”: I added a tokio (async runtime) task that gets spawned for each incoming connection and more parsing infrastructure, though I know have the fun to either write a “few” trait impls or mess with pseudo-variadics. below is a screenshot of the server output after receiving a handshake from the client

can’t believe it’s 10h again, I needed to look through my past commits to recount what I did, which turns out to be a quite mixed bag. I added a few types for server -> client transmission. trying to write them to a buffer first (because packets can be compressed), I realized I need to make the Transmission trait (/interface) sync and then write the packet to the tcp stream asynchronously…a dumb mistake, but rewriting existing code was easy using the search+replace functionality. I tried to get it to work (which json is pretty useful for), but didn’t finish it. thanks serde_json! aside from that, I added a server wip implementation using tokio, I think the design will for now just be having an asynchronous task for each connection which parses the packets and sends them as messages to the (ecs) minecraft world and the simulation send some messages back to the same task (or a separate one?). my next priority will be to have my server be recognized by the client (and making more frequent devlogs maybe).
below a screenshot of some code (maybe next time something else?)

I’m still implementing the Data Types for server -> client transmission as well as the traits necessary (I changed them like 4 times, and some changes meant a reimplementation of existing impls). Now there is just a Transfer trait for types that are ready to transmit (≙ types that can easily write their transmission data to, e. g., a tcp stream or a buffer around one). The implementation now is supposed to be correct, but not necessarily the fastest / most memory efficient one, I will come back to do that later. I already implemented a majority of the data types, prominently lacking NBT (efficient binary data format), some JSON stuff (I guess) and a few small other things, I won’t do the debug data types until I need them. Below is a screenshot of the trait the code I wrote is centered around.

I’m currently trying to implement the Java Edition Server protocol, starting with the data types (like Boolean, VarInt, BitSet, Slot) and transfering them via tcp packets. I’m trying to make it type-safe via a Transferable trait (as seen below) that a few newtypes (respectively called VarInt, Boolean etc) which can be sent over will implement, so I can later just put some of these together for actually implementing the protocol without having to worry about the low-level details (= I can just do sth like send(stream, [VarInt(45), Byte])). I hope this accelerates the implementation.