search

GlowstoneMC / Glowstone-Legacy

An open-source server for the Bukkit Minecraft modding interface
Other
363 stars 122 forks source link

ProtocolLib support?? #144

Open SpaceManiac opened 10 years ago

SpaceManiac commented 10 years ago

(Requested by basicer on IRC).

My past investigation tells me ProtocolLib appears to be heavily dependent on NMS packet structure representations, something which it is unreasonable to attempt to implement purely in Glowstone. Someone (me?) should get in touch with the author (aadnk) and see what they have to say about ProtocolLib/Glowstone compatibility, since it would ease transition for some plugins depending on ProtocolLib but not CB/NMS directly.

The fallback is, of course, asking people to compile against Glowstone and use Glowstone message classes (which really is simpler, if you're willing to risk version instability). Maybe also adding packet in/out events behind some sort of config setting, because performance.

Low-priority.

ZephireNZ commented 10 years ago

Paging @aadnk

dequis commented 9 years ago

Another ping for @aadnk maybe? :3

gdude2002 commented 9 years ago

Demmet @aadnk

turt2live commented 9 years ago

Another page for @aadnk (this is getting pretty annoying)

Personally I feel as though if ProtocolLib and similar plugins wish to support Glowstone, they can. If they don't for whatever reason, they don't have to.

SuperSpyTX commented 9 years ago

https://github.com/aadnk/ProtocolLib/blob/master/Readme.md

It appears @dmulloy2 is the current maintainer of ProtocolLib now.

jimmikaelkael commented 9 years ago

It is mentionned it requires Spigot API ? Is it new ? EDIT: My bad, it might be because Bukkit API stopped support.

gdude2002 commented 9 years ago

Well, if they managed to get it working with Spigot-specific stuff, then they should be able to get it working with Glowstone-specific stuff, right?

It's kind of an important plugin to have working - I hope @dmulloy2 will be happy to port it..

Johni0702 commented 9 years ago

Well, if they managed to get it working with Spigot-specific stuff, then they should be able to get it working with Glowstone-specific stuff, right?

@gdude2002 not entirely. A large part of the ProtocolLib API is heavily based on the field order/types in the PacketXY classes. As Spigot uses decompiled minecraft source code (just as CB did), there were only small changes in the packets themselves (and I'd imagine some changes to get the packet interceptor injected into the pipeline). But if ProtocolLib was updated to support Glowstone, it would cause the majority of plugins using ProtocolLib to be incompatible with either Glowstone or Spigot (or each plugin would have to support both implementations by itself), as the ordering and the types of the fields are different in Glowstone than they were in CB / are in Spigot. There are separate wrappers for each of the packets which would basically provide a way to access packets from the ProtocolLib API without depending on field order. However you'd have to update these wrappers to support both, Spigot and Glowstone, and these wrappers are unfortunately underused (maybe 1 out of 10 plugins use them). You'd also need to basically recode all the other wrappers ProtocolLib provides (see them here). Even thought that'd be possible, it'd be rather time consuming and you might face even more challenges.

So while it'd be theoretically possible for ProtocolLib to support Glowstone and Spigot at the same time. I don't think it'd be worth the time. I do not actively follow Sponge atm but I'd guess that it is easier and faster to just wait for the Sponge API to be done and hope that it provides something that makes it not necessary to have ProtocolLib updated to Glowstone. Sorry for being that pessimistic, I'd be happy if someone shows me that I'm wrong :)

gdude2002 commented 9 years ago

You're probably right, but well, with the way the Sponge project is going.. eh.. it would probably be faster to port this.

Still, not up to us! I would like a decent API that isn't bukkit-based, rather than hacky library porting, too.

turt2live commented 9 years ago

Networking infrastructure doesn't generally belong on a server-side API anyways. What if we swap out Netty for raw sockets? Suddenly our networking infrastructure is vastly different and we can't maintain our "old" API calls. The server-side API would heavily rely on the implementation details, making it badly designed.

A third party resource (such as ProtocolLib) or an otherwise external resource to the common server-side API is more ideal because the use of it is an implied understanding that if things change, your code is likely broken.