Bungee can not connect to Forge in 1.7

[mindforger]

I had a hybrid server on 1.6 with a bungeeproxy connecting a vanilla and a forge server.

Now in 1.7 this is not possible anymore, after asking in the Bungee Project: https://github.com/SpigotMC/BungeeCord/issues/899 i got told:

"forge support was removed for 1.7 because of protocol changes. if anyone is aware what forge changed in 1.7 protocol, maybe this can be added again"

i don't know how "closed" you are on your stuff regarding this issue, but can't we all be friends and exchange some informations between tose two awesome projects to get it working again and furthermore keep it up for 1.8 and beyond? Currently most of my users suffer from this issue and play on vanilla or on my standalone forge server, but can not coommunicate with their other friends or visit them in just a blink.

Thank you,

mindforger

[LexManos]

The networking system of ALL of Minecraft was completely re-done in 1.7. There have been some custom servers out there that try to bridge 1.7 and 1.6 client, We WILL NOT help you do this as it's just a pain in the ass.

The only thing we actually CHANGE is: https://github.com/MinecraftForge/FML/blob/master/patches/minecraft/net/minecraft/network/play/server/S3FPacketCustomPayload.java.patch To expand the size of the possible payload.

However, we do have the client report itself to the server if it is told that it is a modded server. So the bungee people could look into: https://github.com/MinecraftForge/FML/blob/master/src/main/java/cpw/mods/fml/common/network/handshake/FMLHandshakeCodec.java

I need to sit down and disect all of it myself now that cpw is gone, but it should be a simple for those on the bungeecord team who know netty.

[mindforger]

i am very very thankfull and will leave a notice on their board in the issue i made over there so they can probably work with it :+1:

[mindforger]

as i read again over the issue i noticed "There have been some custom servers out there that try to bridge 1.7 and 1.6 client" i do not want to bridge 1.6 to 1.7 i just want to have gungee 1.7 able to connect a 1.7 forge and all they need is to know how to identify or what informations to pass through between client and server!

Therefore an advanced question of my own in this special case, is a "late" handshake between client and server technically possible ? let's say connecting from vanilla lobby to forge server to request the forge stuff informations from the client after already connected to a vanilla server ?? Or do we have probably have to implement the handshake in bungee and maintain the client informations and resend them bungee side as requested when connecting the streambridge to the forge server? And as i know that some mods replace vanilla items with their modded counterpart, is it possible to give the client a "switchback" signal? Or probably an idea how to acomplish that somehow?

[jeffreykog]

Adding support for BungeeCord would require us to add a way to tell the clients to refresh mod information/refresh the block registry/refresh fluid name to id mappings. Otherwise BungeeCord has to identify itself to clients as an FML server and sending all mods to the client that potentially can be on any of the sub-servers. Also block name to id mappings should be the same across all servers otherwise it won't work. I will look into making some changes to FML to support this

[LexManos]

Last I looked into this during the original report of this, FML/Forge didn't need to change. Our specs for how to handle connecting to us were fairly clear and BungeeCord just needed to support it. Theres no much we can do to trick bungeecord into thinking we're vanilla servers because the server needs to do quite a bit more then vanilla does during login. So ya, if md5 has issue he can come speak to me and we can work out the details, but it's on BungeeCords end to support us, which really shouldn't be that hard, due to the nature of us flat out not being able to mascerade as vanilla.

[jeffreykog]

If FML doesn't need to change, how would BungeeCord tell the client about new blockid mappings when the client switches servers. Currently, the only stage this is possible is in the handshake

[LexManos]

Resend the handshake. Its what they did in 1.6 IIRC.

[cpw]

@jk-5 resending the handshake is the best way. You'd need to reinitialize the client connection. I'm willing to countenance small changes to accomodate this, but to be honest, it's probably simpler to synchronize the bungee corded servers.

[mindforger]

@cpw thank you for noticing this issue after that long time, i am really not that deep into the internal details, but many servers have users that are able to use modded clients and that who not. Therefor its always a hassle to get them together or switch between the servers as you have to disconnect, launch the modded client, and then connect to the other server. A more or less seamless switch between modded server and unmodded server is what we'd like to achieve :) DualSpiral, JK-5 and some other worked on that already on the bungee side but noticed the client was not able to be reinitialized to handshake mode when "virtually switching dimension", while bungee establishes the new serverconnection.

Maybe there could be added some "Reset Option" Package to the switch dimension package somehow. Something like 'play modded' -> 'simulate dimension switch' -> 'vanilla reset' ... (and optional after the reset another handshake to switch to another modpack (would be nice to switch between gameservers with different pvp mods that would break each other when used together on one server))

I know this is pretty much what I want :( I feel really sorry

[dualspiral]

@cpw

Thanks for that - hopefully we'll be able to get somewhere with this. I've been working on getting the Bungee system working with this, and my problem is that solely resending the handshake won't work, as once the handshake has been completed once, a second handshake will get swallowed. I'm not sure what the best way to "reinitialize the client connection" is, I see no way to get the server to return to the LOGIN state, or for it to reset the connection such that it'll accept a new handshake, short of disconnecting the client from the server. If I'm being totally stupid, and have missed something, please let me know!

Otherwise, would it be possible to add a check into the DONE state of the client handshake state, such that if a HELLO packet is sent to the client, it'll respond and restart the handshake process? That might be one way around it. That said, would that be a good idea? It might open up the possibility for the server to abuse this feature.

If we did resend the handshake, would changing the ID list mid session work, or would it likely fail/crash the server? Would there have to be a safeguard that only checks and adjusts the block IDs on the server only upon log in or dimension switch?

Apologies for the questions here - they are more of a brain dump that I might get around to investigating sooner or later - but I don't necessarily want to ask for a change to FML without considering the wider implications, particually as I'm not that familiar with FML.