Consider extracting network plugins in mineflayer-* kind of modules

[rom1504]

For example there would be a mineflayer-windows and a mineflayer-physics. These things would get packets and do actions on a prismarine-world.

Benefit of extracting them out may be to make it easier to use them in a https://github.com/PrismarineJS/prismarine-proxy

However this is a bit dangerous and risk creating friction, so it should be done very carefully, and making sure not to introduce high coupling between independent packages

This issue is meant to keep the idea around, but we are not ready to implement this right now.

https://github.com/PrismarineJS/mineflayer/pull/1145 may help on this

The end state of this would make mineflayer just a set of mineflayer- all acting on prismarine-, it would contain almost no line of code and anyone could make his own version based on node-minecraft-protocol easily

The main thing mineflayer repo would provide is the brand and the organization / examples / central point for documentation.

(in a similar way there would be flying-squid-*)

As said this idea is to be thought about properly before trying it, for example one thing we don't want would be to create one package for each of the current mineflayer plugin. It wouldn't work because :

• they are coupled (one plugin depend on another)
• they have state

So among the things to do to make this kind of refactoring possible we need to :

• move the state to prismarine-world
• split the plugins in coherent and independant subsets

It is not obvious that the second step is possible.

[rom1504]

It could also make sense to instead of having flying-squid- and mineflayer- , to instead have pnetwork-* (or another better name) that would handle both client and server side of interaction. It could make sense as for example pnetwork-physics would use prismarine-physics both for client and server interaction

[rom1504]

related idea https://github.com/PrismarineJS/node-minecraft-protocol/issues/231 https://github.com/PrismarineJS/node-minecraft-protocol/issues/510

[rom1504]

One benefit of this is that such a pnetwork-physics module (or prismarine-windows) could be 99% feature complete and stable much more easily. Whereas mineflayer will most likely never be feature complete because minecraft is pretty big

[rom1504]

idea of thing to try here: extract all the windows handling in a prismarine-network-windows . Will have features to handle windows in a minecraft context for both a client and a server. Will talk with a pworld for the state (or a proxy over pworld exposing only windows)

[TheDudeFromCI]

In Prismarine-Design there was a discussion above implementing a higher-level API on top of Minecraft-Protocol. It might be useful to build Prismarine-Network-Windows directly on top of that. It would nicely allow for a clean API for window implementation without relying on anything from Mineflayer or other modules.

It would make it pretty easy to plugin into MC-Protocol alone if you need to do something like connecting to a server that uses an inventory hub without needing all of Mineflayer if the bot doesn't need to do anything.

[rom1504]

I agree in theory In practice we might find that the protocol interaction are highly mcpc specific. I think the best way to go forward for this kind of thing is trying out these ideas in a smaller part of the whole thing. For example trying to respect the design end to end for windows, see what happens. We would probably learn a lot about what makes sense and what needs to be adapted. Quicker to iterate than trying to do the whole thing at once

[TheDudeFromCI]

That sounds like a good approach to me. Starting with windows and inventory management and then expending from there based on what we learn. I like it.