Glowstone Implementation

Will work start on an implementation relatively soon?
Glowstone re-implements the Bukkit API, so you could theoretically start on it pretty soon.

It think this is holding them from starting with the implementation:

  • Glowstone is not finished. Nothing is guaranteed to work, though many
    things are likely to. If in doubt, ask in #glowstone.
  • Vanilla survival features are entirely absent (mobs, hunger, health,
    so on). Glowstone cannot yet replicate a vanilla survival
    environment. These will be added over time.

copied from here.

Glowstone is actually looking pretty good. They have a lot of work to do but when they get it to a point where mostly everything is implemented making a sponge implementation shouldn’t be entirely too hard (I don’t want to discount the hard work that will go into making it). Like I have said before, a glow stone implementation would be a great safety for sponge, essentially providing a backup in case something were to happen to the Forge or MCP team, it also solves many many legal gray areas.

What else is that they don’t break existing bukkit plugins. Very useful. Will Sponge make an automatic plugin converter of some sort, or will they cost devs time in rewriting their code?

Its called Pore

No, that is so Bukkit plugins can run on Sponge.
This is different.

Well we need the pore opposite. A plugin that can load up sponge plugins into bukkit. People do have to realize that with tools like this there will be compatibility breaks. It is not going to be easy converting to and from the bukkit inheritance system to the sponge component system. There are also going to be functions of both sponge and bukkit that the other does not support. Having an interface that results in perfect cross compatibility will be impossible.

If sponge makes an implementation for glowstone, great. Then the dev community actually gets a choice as to what plugin platform to use when developing. Same server base essentially, glowstone, but people can choose to either use the native bukkit API implementation or the sponge implementation.

What would definitely be interesting is if sponge managed to make the implementation with glowstone and still preserve all of their bukkit implementation code so both types of plugins could be loaded. That is pretty far fetched though and most likely impossible.

Hey, idk what path the Glowstone team will choose officially (some good discussion in Ability to send block changes from chunks not in view · Issue #498 · GlowstoneMC/Glowstone · GitHub about various approaches, including a bridging layer like Pore) but I’ve started experimenting with implementing SpongeAPI into Glowstone in this fashion.

All of the Bukkit implementation remains, with SpongeAPI added in parallel. Not sure if this is the best way to do it, but I scan the plugins/ directory first using the Sponge plugin loader, looking for @Plugin-annotated classes to load, then pass jars that didn’t load from Sponge onto the Bukkit plugin loader.

Not many events are supported yet, but where needed I send both Bukkit and Sponge, and check both of their results, example:

         // fire the block break event
         BlockBreakEvent breakEvent = EventFactory.callEvent(new BlockBreakEvent(block, player));
        org.spongepowered.api.event.block.BlockBreakEvent breakEvent2 = new ShinyBlockBreakEvent(block.getLocation());
        if (breakEvent.isCancelled() || breakEvent2.isCancelled()) {
             BlockPlacementHandler.revert(player, block);

Haven’t crossed this bridge yet, but I’m thinking either the same implementation classes would implement both Bukkit and SpongeAPI interfaces, or if there are irreconcilable conflicts there could be parallel classes for each set of interfaces.

If anyone is interested this prototype is available at (testing, bug reports, pull requests, etc. are all welcome)

1 Like