Modern forge support #450
Comments
|
This is highly wanted 😄 Anything you need to get the support to happen or is it just a waiting game ? |
|
I did quite a bit more digging into this and it's actually might be a bit more simple than I think people are realizing. The error experienced in #449 is a Disconnect packet caused by the server lacking IP Forwarding support. A 1.14+ modded client can connect to a modded server in Vanilla mode just fine it's when you start involving mods you have trouble. If you make some changes to Bungee and add the new FML Server List Ping data outlined here here as well as bypass Netty attribute additions for the FML markers and protocol version here the server will start talking. Problem being right now I think due to the lack of all the Netty channel attributes uses throughout the new Forge networking such as this results in the client not responding. I tried adding some of these attributes here in Bungee but they didn't seem to be picked up by the client. It doesn't seem like Waterfall would have to implement any of the handshake really short of pulling Mod List data to support this newer Forge protocol due to it's reliance on Vanilla LoginPayloadRequest and Response. |
|
You don't add those attributes via the proxy, attributes aren't transmitted over the connection, from what I recall, it's basically just a K,V store on the connection, but, that's set here: https://github.com/MinecraftForge/MinecraftForge/blob/1933d05e36245ef7461b29853b4854fa769a807f/src/main/java/net/minecraftforge/fml/network/FMLHandshakeHandler.java#L186 We basically need to ensure that the proxy will handle the handshake process properly, including handling phases in the connection where it's not in play #449 being the kick message for a string too long makes sense, in forge based setups, you generally need to disable ip_forwarding support or use Sponge in order to support the network changes |
|
In the case of the new FML protocol you won't be worrying about phases or race conditions for the FML Handshake it's all being done over the Vanilla LoginPayloadRequest and Responses they are blocking operations and are forced to happen in order. Your really only needing to track the vanilla transition between LOGIN and PLAY as these payloads need to ALL complete during LOGIN. The new FML protocol is outlined here |
|
I've yet to get around to looking over the new protocol, still on the mend from my health issues, sloowly getting there, needless to say, stuff like this is on the back burner The issue is really reimplementing the login stuff, that all has to be handled by the proxy given the nature of how this all works, not really expecting any issues, it just boils down to getting the time/motivation/energy/brain-juice to do it |
|
I fully understand hence why I've be trying to do as much as the leg work as possible and will continue to do so to try and reduce some of the workload. This issue is a very significant blockade to our innovation and keeping our players a safe and happy with new content is of the utmost priority. Without this we can't provide them the experience they expect. With everyone moving on we just want to be able to keep up, wish you the best hope to see you find the time, motivation and energy to continue with this until then we will continue to work away at this. |
|
I've done quite a bit more digging today and found a few more things. Currently it seems that PayloadRequest and Response packets are coming in AFTER the Login Success packet has already been sent here unfortunately that means the client has already gone into a Play state. The server will attempt 20 times to send fml:loginwrapper through PayloadRequest packet to the client unfortunately these never make it out of the proxy to the client as the client has already been forced into a play state then gets stuck joining world. If the client never gets these packets the client will assume a vanilla connection. FML tokens are still present in the extra data of the handshake it's simply been changed from \0FML\0 to \0FML2\0 so the same detection method can be used. It also currently ignores all previous forge handshake handling when enabled so no real worries about it incompatible there. |
|
Unfortunately after much discussion modern Forge support currently is not possible with the current climate. There is no packet currently available to reset the client back into a LOGIN state and without that server switching will never be possible. While initial logins could be done by having Bungee wait for a Login Success or Join Game packet before sending a login success to the client and moving on to Play this will likely cause lots of confusion. |
|
sounds like it would just leave us in the exact same state of affairs, but, with some level of "we support 1.14+", unless I'm missing something with the older system, the client was never forced back into login |
|
No it wasn't since the FML handshake happened in Game mode since it was all Plugin Messages. |
|
I have the same problem too and it's really annoying |
|
same here. I wish sponge updated to 1.14.4. hope they fix this soon as its been 8 months since this has been opened |
|
I'll include this as a conversation that occurred in the MinecraftForge Discord, make sure to go there and find these messages for the rest of the conversation and context as there is more. Essentially a reset packet has to be added to Forge that follows this general idea for any support like this work. At this time they are not interested in spending the time to create this however it seems they are willing to entertain a PR. Hopefully someone like BloodMC who worked on the reset last time or Dualspiral who worked on Forge Bungee support can add this so support can be added proxy side. Otherwise the work proxy side is very simple. |
|
I believe that the best route, which I'm pretty sure we talked to lex about, would be to basically have a server switch packet, the only real caveat is making this work in common proxy environments, the /only/ way I could see this working would be to have some way to pass some data to the client to re-forward on join, that way we can send them to the correct server, which ofc, creates its own "we don't want the client to be able to throw arbitrary data at us and do whatever" issues |
|
I noticed here, try https://github.com/ArclightPowered/lightfall This is what I found when browsing Github recently, the project works in 1.15.x-1.16.x bungee-forge |
|
Lightfall is a good example attempt but is not a solution as it requires a client side mixin patch to work. The implementation of that patch is very basic and doesn't clean up any registries so it's bound to cause problems. In that state it can't be added into Forge. |
|
@PurpleIsEverything here is how my implementation looks like for now
It works. I’m not 100% happy with everything yet but I’m getting closer |
|
See, personally, am not too sure about the UUID, i guess it works, would just need to be exposed in the API, I was more thinking potentially something which can be signed so that the server doesn't need to deal with storing stuff, but, uuid is more portable 🤷 |
|
I’ve tried many things and among long convoluted hacks that try to reset the client state without closing the connection- No. Forge mods can’t be expected to be completely reset if you do that. The only way to be sure is to force a complete disconnect so the client must undergo a full new connection. It’s also the most maintainable way |
|
a full reconnect is what I was proposing to lex, given that it offers a cleaner state, just there would need to be some form of token passed |
|
or, well, what we where discussion, not too sure who entirely proposed it, that discussion was a little while ago |
|
Whatever implementation is used it's going to require modifications to Forge on the client to handle the reset. A proper PR into Forge likely involves a more complete reset hook and event to make sure mods are aware of the transition. |
|
it's a balance between, do we make mods responsible for it and hope they catch up, or, just have a more blanket system for it which generally works as expected across the entire board |
|
There is a huge pool of people that are interested in this working and many of us have written proof of concepts on how it could be accomplished properly along with making the attempts with both Paper staff and Forge staff to get this going. People have gone as far as to make client side mods and modified Paper/Velocity builds to make this work and that already proves we all know how and have the interest in it being completed but we can't make it mainstream alone. What is failing here is not the communities interest, or the skill it's simply the lack of interest in either team to cooperate with one another, that is where the lack of effort is. |
|
This is an open source project of which we are happy to work with people, however, this project is managed by 1 person and I do not have the energy nor the investment into this project as I once did, I know this is doable, me and lex spoke about the general idea years ago of how this would all work. There is one person on the team who routinely interacts with this project, however, and he was aware of/working on some things to solve this however idk what all has been said/done, I don't have the privy to info on what all they've done and such and aren't gonna try to badger them/chase them down to tell me If this is all gonna depend on the efforts of me, somebody of whom has limited energy and this project and this issue as a whole is far down on my list of concerns and "need to do's", then I'm sorry, but, this is probably DOA |
|
We were not asking for a commitment of time, or development effort we can write these solutions and we already have. The problem is not that at all, it's that all these attempts by people fall on deaf ears and frankly for many it's become extremely frustrating. We simply do not have the ability to start the conversations or the cooperation that is needed to get the needed changes on both side in. So you see it's not a matter of writing the software it's a social problem. |
|
I've already spoken to lex about this years ago, I'm not really sure what all else I can say to him, we all generally agreed on the general mechanisms I've already discussed to people over this about |
|
We mentioned it to him rather recently in hopes of getting something similar to the reset packet added for 1.13+ the response was not particularly friendly effectively pushing the entire effort required onto the proxy maker side while the proxy maker side does the same. It's that back and forth that is very damaging to anyone trying to put considerable effort into getting this issue solved, community solutions are devised but there is a holding pattern where fingers are pointed as to if any such changes should ever be accepted. Add also that most of the community solutions based off many of these basic discussions in this chat are often looked upon as hacks with very little information on how to make them into something that would be accepted if that finger pointing could be solved. |
|
Thing with a reset packet is that the entire connection state needs to be shot back down to more or less as close to a new connection as possible, hence why our general slim discussion was more just about a reconnect packet (akin to the transfer packet people have asked mojang for years), but, more being nuanced in that, ideally, you'd just send a packet to the client, the client would DC, connect to the new server and pass some token or other back in the connection so that the proxy can determine what to do There is very little afaik that we can do if we can't do that, only other solutions would involve metric tons of rewriting data from the proxy which is basically a non-starter, but, I have no idea how technically challenging a transfer packet would be to implement cleanly and responsibly, but, I don't see a way for us to deal with it in a maintainable, responsible, not gonna kill resources manner |
|
Guys, if I understand correctly, there is a problem with communication. And what to try and contact the creators of Mohist or Magma, they would certainly make some effort to make it work. Has it been tried yet? |
|
mohist/magma have nothing to do with this. |
|
Um, how come? As far as I know, they are developing hybrid servers that run the Forge + Spigot/Paper method |
|
Because the server is 100% irrelevant here |
|
Well, yes, but if I try to connect them and they have mods, it doesn't work, does it? |
|
it doesn't work because waterfall doesn't have support for it. waterfall doesn't have support for it because there's little interest in dealing with support for it when the fundamental reason for support for it is not achievable with the current tech. The server is 100% irrelevant here at this phase, they have 0 bearing on the issue at all, the foundations for this to work need to be added into forge or vanilla itself, especially if you wanted a much more reliable environment over the hacks in 1.12 in which stuff was purely hit and miss. |
|
The issue isn't the end server, it's the proxy (to my knowledge) which is why this debate is stemming from Waterfall and not them. That being said, Mohist and Magma are the last people we'd ever work with for various reasons. Regardless of the true issue being "communication" or whatever philosophy you wanna bring into here, I don't see any reason to argue in a GitHub issue tracker. We don't really need any finger-pointing here. The issue still stands, and we'll always accept contributors. |
|
Velocity PR: PaperMC/Velocity#690 Forge PR pending. |
|
is there any chance that above PR is getting included into waterfall aswell? |
|
the paper and forge teams seek a solution that works with all major proxies, which includes bungee, so waterfall would get it automatically if bungee chooses to go with the proposal. |
|
I'm really rooting for this to become a reality. |
|
I can agree with that, but neither side is willing to put in the effort due to non-interest. Someone's going to have to submit a PR on both sides with their own implementation for it to even have a chance at being looked at on both sides. |
|
The following requirements exist for this:
You should really target Velocity instead, bungeecord and by extension waterfall has a lot of problematic features that will only work correctly with vanilla (like the server switch mechanism or the entity meta rewriting system) |
|
To also note, we will only support a client/ + server side mod combination over an official modification to the mod loader as the absolute last resort. |
|
I've honestly just ended up using velocity and magma. They work pretty well. A take back is that I lose like 1ms of ping and an entire library of plugins that do not work for velocity. Only the big mainstream plugins worked for velocity. I have to discard ones like advanced ban and find an alternative ones or find a serverside ones that can share a mysql table :/ |
AdvancedBan can be replaced with better plugins such as LiteBans or LibertyBans, both of which work on Velocity/bungee and Spigot |
Yes, even Velocity says there are plugins that have their replacements, but there are only so many. And quite frankly, I have searched well enough and have only found a hand full. (The Snap plugin is useful for Bungee compatibility on Velocity) |
|
Wondering if I have been looking in the wrong places but is there anyway to just have a basic light proxy without server switching? |
|
I don't think such a thing exists, because of SRV records and multiple ports. Multiple ports vs 1 port is no difference in security or ddosability. Performance will be better with separate ports |
|
What Janmm14 said. Multiple ports open won't change a thing if someone decides to target you. Multiple services running on different ports will, but all of one kind? Nah. |
closest thing I can think of to that would be https://github.com/haveachin/infrared |
and others
Bungee, and by extension, Waterfall; does not support IP forwarding for forge clients, this needs to be investigated, especially as upstream has expressed 0 interest in maintaining forge support
The text was updated successfully, but these errors were encountered: