Split out protocol support into a separate crate? #167
Comments
|
On IRC someone was asking about this, so may be worth continuing #167 - although it is a lot of changes, would it be better to instead add a crate option to allow compiling out the GUI? Having a separate crate on the other hand would be nice for maintenance purposes and reuse (Alxly on IRC was interested in this project as an alternative to https://github.com/PrismarineJS/minecraft-data - which was considering a Rust wrapper: PrismarineJS/minecraft-data#35 - they have more protocol support, but abstracted away further than us). |
|
@iceiix, minecraft-data use protodef format for describe data. Code generators for elixir and nodeJs only. |
|
There is feather's feather-core, but it's limited to 1.13.2/404 currently and has *unimplemented client only bindings. I was looking at stevenarella to see if I could see how to correctly format EncryptionResponce, but I couldn't just connect it to locally running server without knowing how. Here is a trace from feather-server https://pastebin.com/4uMVsQin I don't know why this doesn't work.
|
|
It would be cool to work with feather-rs to have a shared protocol crate both projects (and any others) could use, if they are interested. With extensive tests and version support. Not sure how difficult this would be. |
|
(I'm the Feather maintainer.) We do plan to implement multi-protocol support in feather-core after some time. There's a few difficulties with splitting the protocol into a separate crate, though—notably, types like the chunk structure are parsed into Feather's chunk implementation, which then in turn depends on our A possible solution to this would be to have users provide a function which converts protocol data for a chunk (palette and data array) into their desired type. |
|
Storage for chunk data is something the feather-core crate might make flexible. I was thinking about this when filling in the client protocol bits, that a server and client have incompatible needs as far as storing chunk data. |
|
Checking in as someone else who would be interested in this. I could honestly accept the ability to just add Stevenarella as a lib as a temporary hack - or something similar to that, I just want to avoid having to copy-and-paste and mangle the code myself - but I also don't have any particularly complicated needs. I know wrappers for other languages (ex. prismarinejs) exist, but having multi-protocol in one lib + being able to use it from any language that supports loading natives is something I would be very interested in. |
Adds the protocol submodule, and required dependencies, in a new subdirectory protocol/ for a separate crate in #167. This merge preserves the commit history (without requiring --follow to view) using filter-branch as follows: git checkout master git checkout -b protocol_subtree git filter-branch -f --prune-empty --subdirectory-filter src/protocol @ git filter-branch -f --prune-empty --tree-filter 'mkdir -p protocol/src/protocol; mv * protocol/src/protocol 1>/dev/null 2>/dev/null; true' @ git checkout master git checkout -b protocol_deps_subtree git filter-branch --index-filter 'git rm --cached -qr --ignore-unmatch -- . && git reset -q $GIT_COMMIT -- src/format.rs src/item.rs src/macros.rs src/nbt src/types' --prune-empty -- git filter-branch -f --prune-empty --tree-filter 'mkdir -p protocol/src; mv * protocol 1>/dev/null 2>/dev/null; true' @ git checkout protocol_subtree git merge --allow-unrelated-histories protocol_deps_subtree git checkout master git checkout -b protocol_crate2 git merge --allow-unrelated-histories protocol_subtree
Completes the move of the protocol implementation into a new crate, named steven_protocol, in the protocol/ subdirectory. * Add Cargo.toml for steven_protocol * Add steven_protocol entrypoint in protocol/src/lib.rs * Use steven_protocol in main * Remove protocol in main, replaced by steven_protocol * Remove unused dependencies moved into steven_protocol
|
Finally got around to this, with #277 and #278, the new crate is steven_protocol. Not yet released on cargo (#280), @queer you could try depending on steven_protocol using a git dependency for now, let me know of any feedback. Note it doesn't have everything needed to develop a client, but at least includes packet decoding for various protocol versions. |
|
@iceiix Sweet, I’ll check it out soon! Thank you so much! |
#18 (and others) added a ton of protocols, supporting multiple at once, a fairly unique and strong feature of this project. Currently implemented in src/protocol, but it could be useful to separate it out on its own crate so it can be used independently.
Example use case: creating command-line clients, proxies, or otherwise testing or debugging the protocol, without the full-blown GUI or graphics. Inspiration: https://wiki.vg/Client_List lists https://github.com/Tnze/go-mc/ "Create Minecraft bots with golang" as one of the few active clients for 1.14.1. There are some on https://crates.io/search?q=minecraft but they are either old/obsolete, or only support one protocol version:
multi protocol:
single protocol:
inactive?
support (not full protocol):
clients/tools:
The text was updated successfully, but these errors were encountered: