Redesigning Packet Type and Registry System

[Ingrim4]

After updating ProtocolLib to "work" on 1.20.5, I felt that the entire system revolving around packet types and registry is in need of redesign, as several parts of the code fail to represent the current state of the game adequately. So here are some things I would like some feedback on before implementing any of it.

1. Redefining Packet IDs:
   First and foremost, packet IDs should be considered irrelevant, as they have been unreliable for over a decade. Hence, I propose their complete removal from the public API. Presently, the only apparent usage seems to be in the WirePacket implementation. Therefore, I suggest eliminating the hard-coded packet IDs. Instead, they could be dynamically set when the packet type is identified by the registry. This approach would include removing most of the outdated methods that solely rely on IDs, such as the ProtocolSenderLookup.

2. Packet Bundle Processing Issue:
   Although not entirely related to packet types, there might be an issue with processing packets asynchronously when they are part of a packet bundle. Currently, it appears that the bundle packet is split into multiple packets inside the PacketBundleUnpacker, called before ProtocolLib. This may cause the packet to be sent outside the bundle delimiter, leading to incorrect processing by the client. Nevermind I got it the wrong way around ProtocolLib is processing packets before the PacketBundleUnpacker which means a listener has to listen for bundle packets in order to process packets inside a bundle which also isn't ideal for multiple reasons.

3. Removal of Deprecated Methods:
   I have a general question concerning the deprecated methods related to the packet type and registry system: While it's common practice to deprecate no longer maintained methods, I propose going a step further and completely removing them. The rationale behind this suggestion lies in the fundamental difference between a normal deprecated method and some of ProtocolLib's methods. While deprecated methods may still function, certain methods in ProtocolLib, such as PacketFilterManager::getPacketType, often fail to produce correct results in many cases.

I guess my main point is: How much backward compatibility is too much? Balancing legacy support with modernization for something ever changing is hard so why not make it easier, older version can still use older releases.

[derklaro]

Big thumbs up from me on this topic. I had experimented with rewriting packet types in the past, but never found a solution I was happy with. Biggest problem are mainly class names which are changed as often as the packet ids themselves (or spigot mappings vs mojang mappings which is what we have as a “problem” at the moment). But to be honest ProtocolLib is based on legacy hacks in many places, the whole system around StrucutreModifier is based on something like that to be able to write to records, but that's a topic for another time :)

I think the biggest advantage of ProtocolLib for many people right now is that everything that ran 5 years ago still runs now (& even partially on new versions), with a drop-in replacement of the ProtocolLib version. But I would also prefer that you break with old APIs (where necessary) and modernize. But at the moment, for every method that is deprecated, there is probably a user somewhere who is still using it today (albeit perhaps unknowingly).

[Ingrim4]

I understand that it's convenient to just drop in the new version of ProtocolLib and everything works but it's more sensible to have breaking changes whenever mojang changes the fundamental functionality of things like the packet ids or unique classes per packet. Perhaps introducing deprecation cycles, where outdated methods are phased out after a certain period, could be a step in the right direction. Some components of ProtocolLib have remained unchanged for over a decade, constraining the potential for innovation within existing systems due to the perpetual need for backward compatibility.

[PukPukov]

Maybe you firstly want to release working version for 1.20.6 before trying to break everything? When mojang, for example, does shit that no one asked and that breakes everything they at least do that after finishing work on great features.