High level abstractions above nmp

[rom1504]

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.

[rom1504]

Some ideas :

• transform field type like block id, entity id, position to their corresponding classes (prismarine-block, prisimarine-entity, vec3)
• group some packets like the spawn entity packet
• compare mcpc and mcpe protocols to have ideas about how to build a common representation

I think that representation should be made available to users but the low level representation should still be available even if we would encourage users to use only the high level representation if possible.

[rom1504]

https://github.com/DragonetMC/DragonProxy/tree/master/src/main/java/org/dragonet/proxy/network/translator

[deathcap]

Another possible use case:

• Chunk data: widely differs between protocol releases, would be nice to abstract the map_chunk packets away: mineflayer 1.8, 1.7, earlier, 1.8 flying-squid, 1.9 minecraft-data (has map_chunk but no map_chunk_bulk)

[rom1504]

indeed the chunk layer is now completely abstracted in prismarine-chunk

[rom1504]

PrismarineJS/bedrock-protocol#116 kind of related