Background

Background

Minecraft proxies has in a long time not supported modern Forge. I became interested in finding a solution to this issue back in 2020. My first attempt was a modified waterfall proxy that made it possible to connect to a modded Forge server. It was just a basic prototype to research the possibility of it.

Jumping forward 1 year and I discover other that people that has also tried to make this work, including a Velocity dev. We gather with plan to make a standard that could unite every proxy to a single solution on how to reset the client. After a while I get approached with, what the Velocity dev calls, a crazy idea on how it could work with Velocity by only using it's built in API. The idea involved passing the entire Forge handshake through the serverlist ping packet's mod info data and simply sending it to the player when connecting and thus, the first version of Ambassador came to be. I choose to call it Ambassador because I suppose it makes Velocity understand Forge in the favor of the server admins.

For this to work, a server side mod was also created, Ambassador-Forge (now known as Proxy-Compatible-Forge). The server side mod would allow connections without having the FML marker and pass the entire forge handshake in it's serverlist ping.

While this solution worked, it had it's limitations. It couldn't do resets because Velocity doesn't support state changes like what client reset packet mod used. It worked by syncing the player to a forge server no matter what initial server the player got connected meaning that the server admin had to predict what server the player should switch to depending on what mc version the client used. This lead to the config being very confusing for admins and resulted in me trying to explain on how they should config Ambassador.

Feeling restricted by Velocity's API I figured that the only way to move ambassador forward in it's development is to inject into the proxy instead of using it's API, hence the branch name 'non-api'.