PrismarineJS / PrismarineJS/node-minecraft-protocol

High level abstractions above nmp

Open
#231 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

use case
Dominant language
JavaScript
Stars
1.4k
Forks
290
Avg merge
4d 8h
Merged PRs (30d)
7

Description

So this is not really a nmp issue : there is nothing to fix in nmp in this issue, but it's an issue that can concern several nmp users.

The starting point of this issue is to see that mineflayer provide an high-level api for clients, flying-squid is starting to provide an high-level api for servers, and some things are common in these two implementations.

So what is common ?

There are 4 main things that are done with nmp :

  1. reading client bound packets
  2. writing server bound packets
  3. reading server bound packets
  4. writing client bound packets

Mineflayer is doing 1 and 2 and flying-squid is doing 3 and 4.

Now there's a third kind of nmp users : proxies, like the one @Egoscio is building. And proxies actually do these 4 things : they need to understand the 2 direction and send packets to the 2.

Mineflayer and flying-squid can both use certain type of representation to store information, for example prisimarine-block, prisimarine-entity, prisimarine-world, node-vec3.

Now the handling of reading and writing packets is different with just the storing information part.

I think what would be interesting for all these users would be to provide methods that would make it easier to read and write the packets at a higher level. For example the block_place packet contain a direction number and a reference block position, it would be interesting to transform that into an event containing the position of the future block, and a direction vector instead of the direction number. This is just one example ( and I will add more) but this is the kind of things that would make writing mineflayer and flying-squid easier.

So basically the idea is to provide methods to facilitate writing packets and reading packets from a higher level perspective.

In a second stage it might be interesting to have 2 back ends for that representation : mcpc and mcpe. That way it would be easier to write bots, servers and proxies that would work for both mcpc and mcpe.

This is the basic idea and I'll add more examples later to make sure and prove that having a higher level representation of these network operations make sense.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Start by comparing the packet-reading and packet-writing responsibilities described for mineflayer, flying-squid, and proxies, then review the examples proposed in the issue. Done would require a decided, shared high-level representation and an implementation plan covering the listed users and packet directions.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
backend-api-design, networking
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
18/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.