Accommodate Bedrock Edition

[astei]

Details TBD, but the basics are:

• Add support for more than one listener (Velocity 1.x.x currently only supports one listener)
• Speak the Bedrock protocol natively (also requires entity rewrite infrastructure)

The initial stage of this will most likely focus on API changes that target Velocity 2.0.0 which open the option, followed by developing the actual module. There is buy-in from the Geyser team on this.

[Camotoy]

Can confirm that I am interested in the development of this, as well as others on the team. Here's our protocol library that we use over at Geyser, and what the new Waterdog rewrite is using as well: https://github.com/CloudburstMC/Protocol. It would be awesome if we can get this over to Velocity as well.

Another point to consider is the use of the transfer packet. I am unfamiliar with how this has been used in the past with proxies, but I do know there have been settings that use the packet for transferring between servers. If Velocity wanted to use different resource packs on different servers, this is a must, because resource packs have to be loaded in at the beginning of a Bedrock session.

[lukeeey]

I believe there is also work being done to implement the Java protocol into the Cloudburst Protocol library as well, so it’s worth noting that if you decide to use it for Bedrock support you may be able to use it for Java protocol handling in the future.

[astei]

Another point to consider is the use of the transfer packet. I am unfamiliar with how this has been used in the past with proxies, but I do know there have been settings that use the packet for transferring between servers. If Velocity wanted to use different resource packs on different servers, this is a must, because resource packs have to be loaded in at the beginning of a Bedrock session.

We will have to do something somewhat similar to enable Forge support for 1.13 and above anyway, so this isn't too hard.

I believe there is also work being done to implement the Java protocol into the Cloudburst Protocol library as well, so it’s worth noting that if you decide to use it for Bedrock support you may be able to use it for Java protocol handling in the future.

I think it's better if Velocity continues to implement the Java protocol separately. We don't need to handle the full suite of packets (and we almost certainly don't want to!)

[Camotoy]

Should the transfer packet become the primary method for switching between servers, I do not believe we would not need to rewrite entity IDs as technically every server switch is its own game. (A downside to the transfer packet is that server switching would be slow)

Should the transfer packet not be implemented (or there be an option not to use it), item IDs would also need to be rewritten. 1.16.100 made all blocks use a set internal palette, but items can still define whatever numbers they want as runtime IDs.

[lukeeey]

If the transfer packet is the primary way of switching servers that basically voids the need for a proxy

[Camotoy]

The proxy would be the tool that manages switching between servers - such an option would likely just "transfer" over to the same proxy server, with the proxy remembering the player and forwarding their information to the desired backend server.

[astei]

Removing the milestone from this as initial support for this is very unlikely to make it into Velocity 2.0.0 - more details TBD.