PrismarineJS / node-minecraft-protocol

Parse and serialize minecraft packets, plus authentication and encryption.
https://prismarinejs.github.io/node-minecraft-protocol/
BSD 3-Clause "New" or "Revised" License
1.22k stars 240 forks source link

High level abstractions above nmp #231

Open rom1504 opened 9 years ago

rom1504 commented 9 years ago

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 commented 9 years ago

Some ideas :

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 commented 8 years ago

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

deathcap commented 8 years ago

Another possible use case:

rom1504 commented 6 years ago

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

rom1504 commented 2 years ago

https://github.com/PrismarineJS/bedrock-protocol/issues/116 kind of related