Glowstone support

[gdude2002]

Hi there, I'm the PR guy/sysadmin for the Glowstone project. If you haven't heard of it, we're a custom server written in Java and implementing the Bukkit API - clean-room and so without the heavy reliance on Mojang code.

Unfortunately, that does mean we don't have net.minecraft.server or org.bukkit.craftbukkit. Our users often request that we support ProtocolLib, and we're at about the point where we're ready to look into this.

Are you willing to work with us on this? We feel that first-class support in ProtocolLib would be better than any roundabout hacks we could add on our own, and that someone with intimate knowledge of the plugin internals would be better suited to doing that.

If you'd like to chat more directly, you can join us on Discord. Thanks!

[dmulloy2]

One of the big selling points for using ProtocolLib is that it uses reflection to bypass package versioning and field modifiers. It would appear based on your source that Glowstone doesn't version the networking package and in fact exposes the packet data, though the fields seem to be final.

I've been considering truly modularizing ProtocolLib for some time now and got a good chunk of it done last year, but I never really did anything with it. At the time, I was mainly considering Sponge, but to my knowledge it never really took off and I deemed it not worth the effort. That Glowstone uses the Bukkit API would actually make it a lot easier to port.

[mastercoms]

Hi, I'm the Glowstone project lead and I would like to thank you for looking into this. Please let us know if there is anything we can do to make porting easier if you decide to do it!

[gdude2002]

I think one of the major points for the adaption to Glowstone (for us) is that there are a lot of plugins out there already using ProtocolLib that it wouldn't really be fair of us to expect to add Glowstone support directly. ProtocolLib is large enough that not supporting it for us is akin to simply leaving out a chunk of the Bukkit API entirely.

I would imagine there would be a lot less work in supporting Glowstone than Sponge, yeah, especially since the Sponge API has been such a fast-moving target. I guess my question is how interested you are in adding support since this is a large project and there's probably a fair chunk of work involved.

As @mastercoms says, we'd be happy to help with whatever you might need for this. Don't forget, you can always chat about it on Discord, which we also have linked with #glowstone on EsperNet if IRC is more your thing (although the bot isn't very stable, sadly)

[dmulloy2]

Sponge would have been pretty much a ground-up rewrite, which was not something I was interested in. However with Glowstone, a large portion (if not all) of the API is still viable, the only difference being the implementation. I suppose a good starting point would be your basic network structure, i.e. how different from vanilla it is. If it's largely similar to or modeled after vanilla, porting would be a pretty straightforward, if slightly tedious (mapping packets) endeavor.

If it doesn't end up being a huge amount of work, I'm definitely interested in porting it. I might drop by on discord later if I have some more time.

[mastercoms]

I can't say if Glowstone is similar to vanilla because we're a clean room rewrite and thus I haven't looked at Mojang's code.

However, I can describe our network structure and then you could tell me if it is similar. Basically, packets are children of the Message class, and have a constructor as well as getters for all packet data. These messages are sent through a GlowSession, through GlowSession#send.

[demkom58]

I hope that you will add Glowstone support in the following ProtocolLib updates. I really need this.

[Foorack]

Any update on this? 😀

[dmulloy2]

I've been quite busy this summer since I took a job at Mineplex, along with preparation for college. I don't have much time or energy to dedicate to a port like this.

[gdude2002]

Ah, grats. That's kind of sad to hear, but I guess all projects get to a point where people are busy.

Our team is largely very busy as well - seems to be the way of things with Minecraft projects. I'll ask our contributors to weigh in, perhaps one of them will have some time.

[gdude2002]

[ryantheleach]

In regards to Sponge, the biggest barrier would be the fast moving API. It's taken off to a degree but it's still a pretty niche community of people who want to see a better API, those that are willing to put up with breakages / strange priorities (small parts of the API remain unimplemented, while others see giant rewrites).

They do have PacketGate however, but it's rather immature compared to the definitions found in ProtocolLib

https://github.com/CrushedPixel/PacketGate

[Foorack]

@dmulloy2 Why was this closed? :thinking:

[MiniDigger]

a victim of the general cleanup I would guess, but since nobody showed interest in doing any work on this for the last half year I don't think this will happen any time soon anyways :/

[gdude2002]

Our team has interest. However, just like many MC projects, everyone on the team has to work and doesn't really have that much free time to work on non-core stuff.

[dmulloy2]

yeah i closed all the issues that were a few months old, figured if people still wanted them fixed they'd open a new one or comment (kinda like this)

[dmulloy2]

to give an update, it looks like this branch (https://github.com/momothereal/ProtocolLib/tree/glowstone) has at least some work done on it, not sure if it actually works though @momothereal

[aramperes]

No, the branch isn't functional (the plugin won't load in its current state anyway). More work needs to be done in the server injection side, as well as abstracting a lot of stuff away from Vanilla. It's no easy task :^)

I don't personally have much time to work on this.