UXELDUXEL

It may have never been "supported" but it did work just fine. Anyhow dont want to argue with you about what the word "supported" means, at least my mentality is: "if it works it works". Concerning Open-Source and Pull-Requests and forge while I do have the skill to add something like this to forge, I personally think that it would be hard to convince anyone to actually put it in. Ive had my fair share of bad experience wasting a lot of time with such things (Not Minecraft related) so I wont do such things anymore. Anyhow thanks into putting in the time to clarify this for me. Ill be off then.

Well, it used to... (Would be nice if it could be reintroduced ) Okay thanks for this info guess Plan B it is.

This is kinda necesarry to move a player from one server to another. (Mainly to move a player from a vanilla server to a modded one) Im developing a Proxy/Load balancer and im currently updateing it to 1.16.3/4 What I considered doing is to just ask the "client" for a modlist by sending an empty mod list to the client. And then based on the clients response send the "actual" modlist to the client but I havent tested yet if the client accepts the server sending the mod list twice. (I have doubts that it will but I cant think of any way to ask the clients for its modlist without actually providing it the servers mods which I kinda need) And then "fake" the full negotiation based on prerecorded messages so the forge client always thinks it plays on a modded server. Upon negotiation with the actual server id also just use prerecoded messages. But this is only plan B as it would require me to store pre recorded messages for godknows how many messages each of the mods send and also somewhat parse the forge messages (at least the modlist packet possibly also the registry packets that come after) which I personally would like to avoid as it is would just be another pain in the ass to do. Additionally I would also have to manually filter out all custom messages from all mods that a vanilla server has no way of handling... Ive looked into what the folks over at bungeecord did and they also did not seem to have solved this issue for anything beyond 1.12 just like I have or I just didnt find it in their code but everything forge releated they have currently on their master branch seems to be <=1.12 stuff.

No this CSV file is the only thing I have ever used. Altho I have not looked for further mappings. I am not developing mods myself, I fix mods that other people made mainly so they can be actually used in a server. So i don't really have a need to see the full source code of a mod. I only need to find the portion that buggy (or has you know, remote code execution exploits...) and then fix it using whatever means necesarry.

Hello there, depending on the version of forge/minecraft there is a csv file provided in forge which contains mappings (i.e. obfuscated method name A = not obfuscated method name). You could then use a framework like javassist to remap the method calls/field accesses using this info (or do it manually using something like notepad++ with the replace in files function). Either way this is a lot of work not gonna lie your probably better off just rewriting your mod you should still be able to copy half of your stuff over so it should be a reasonably quick process. There used to be a way to do this using mcp but the last time I attempted any such things is probably 6 years ago for < Minecraft 1.4 not sure if these tools still exist and to what extend they can still be made to do this.

Hello there, a more network heavy question here but I hope you guys can help me. I need to find a way to get the Forge client to renegotiate all its Handshake data during play state. (Don't worry about the server here, all i care about is the client) This was possible starting with Forge for Minecraft 1.4.7 and possibly even earlier. I presume that the version where this was changed was with Forge for Minecraft 1.13 when Mojang added 2 Packets during the login state for custom data exchange. In Minecraft 1.12 and 1.10 one could send packet 0x18 during play to the client on the channel "FML|HS" with the following payload new byte[]{-2} In Minecraft 1.7 this was almost identical but was new byte[]{-2, 0} In Minecraft 1.6.4 and 1.4.7 this was (on the Channel FML with Packet 250 Custom Payload) new byte[]{0, 0, 0, 0, 0, 2} Afterwards it was more or less straight forward anything sent by the client on the channel "FML|HS" or "REGISTER" was part of the forge handshake. So how would one go about doing this in 1.16.4? I presume it is impossible to get the client from the play state back into the login state, so I kinda need a way to trigger this via a Packet 0x17 (just as seen above) and then subsequently send/receive this exact data by using Packet 0x17 (server->client) and Packet 0x0B (client->server) during play state. I have looked through the Minecraft Forge Source code for 1.16 but was unable to find the info. So I am wondering, is this still possible or was this feature just straight up cut from the Network Protocol? Any Information regarding this would be much appreciated.